Skip to main content
Preferisci non configurare tutto manualmente? Incolla un collegamento a questa pagina in una sessione di Devin e chiedigli di configurare tutto per te.
Questa guida illustra come gestire le automazioni pianificate tramite le API v3, utili per flussi di lavoro di infrastructure-as-code. È anche possibile crearle e gestirle direttamente nella pagina Automations senza alcuna configurazione API.
1

Configura un utente di servizio per l'accesso alle API

Le automazioni create tramite l’API richiedono un service user con le autorizzazioni appropriate. Ne configurerai uno una volta sola, quindi userai la sua API key in tutte le chiamate riportate di seguito.
  1. Vai su app.devin.ai > Settings > Devin API, apri la scheda Service users e fai clic su Provision service user
  2. Assegna un ruolo che includa l’autorizzazione ManageOrgAutomations
  3. Salva l’API key mostrata dopo il provisioning — viene visualizzata una sola volta e la utilizzerai come token Bearer
Il tuo organization ID è mostrato in cima alla pagina Settings > Devin API. Anche gli Enterprise service user il cui ruolo include ViewOrganizations possono chiamare l’endpoint List Organizations con il proprio token:
Esporta entrambi i valori in modo che i comandi in questa guida funzionino senza modifiche:
Consulta la documentazione sull’autenticazione delle API per ulteriori informazioni sugli utenti di servizio e sulle autorizzazioni.
2

Crea un playbook per l'esecuzione del test

Prima di creare l’automazione, scrivi un playbook che indichi a Devin esattamente come eseguire la tua suite E2E e cosa fare con i risultati. Vai su Settings > Playbooks e crea un nuovo playbook — oppure chiedi a Devin di generarne uno per te a partire da una descrizione del tuo flusso di lavoro di test. Ecco un esempio per una suite Playwright:Prendi nota dell’ID del playbook dopo averlo salvato: lo indicherai nel prompt dell’automazione. Puoi trovarlo nell’URL quando visualizzi il playbook (app.devin.ai/.../playbooks/{playbook_id}).
Installa l’integrazione Linear in modo che Devin possa creare ticket come parte del playbook. Quando modifichi l’automazione nella pagina Automations, puoi anche aggiungere una notifica Post to Slack (ad es. #qa-results) in modo che il tuo team riceva notifiche automatiche. Fornisci a Devin accesso in sola lettura ai secret del tuo ambiente di staging (URL del database, API key) tramite i secret dell’organizzazione, se i tuoi test ne hanno bisogno.
3

Crea la pianificazione notturna tramite l’API

Ora utilizza l’endpoint POST /v3/organizations/{org_id}/automations per registrare un’automazione con un trigger schedule:recurring e un’action start_session. Fai riferimento al playbook nel prompt con un token @playbook:{id}. Le sessioni avviate da un’automazione dispongono solo degli strumenti che le concedi, quindi il blocco tools abilita gli strumenti di Linear e consente a Devin di pubblicare nel tuo canale #qa-results (sostituisci gli ID del workspace e del canale Slack con i tuoi). In questo esempio viene eseguito ogni notte alle 2:00 UTC:
La risposta include un automation_id che utilizzerai per gestire questa automation in seguito. Salvalo:
La condizione rrule accetta una RRULE iCalendar valutata in UTC. Alcune alternative utili:Perché le 2:00? Vuoi che i test vengano eseguiti dopo che l’ultimo deploy della giornata si è stabilizzato in staging, ma abbastanza presto perché eventuali errori siano visibili quando gli ingegneri iniziano a lavorare. Regola l’orario in base al fuso orario del tuo team e alla frequenza dei deploy.Consulta la documentazione dell’endpoint Create automation per tutti i campi disponibili.
4

Verifica la prima esecuzione e ottimizza il prompt

Dopo che l’automazione è scattata per la prima volta, controlla la sessione per assicurarti che Devin abbia eseguito i test correttamente e che l’output corrisponda alle tue aspettative.
  1. Apri l’automazione nella pagina Automations e segui il collegamento alla sessione nella scheda Activity
  2. La suite Playwright è stata eseguita? Sono stati creati ticket in Linear per i reali errori (non per i test instabili)?
  3. Controlla il canale Slack #qa-results per il messaggio di riepilogo
Problemi comuni alla prima esecuzione e come risolverli:
  • Devin non può accedere allo staging: aggiungi le variabili d’ambiente dell’ambiente di staging (come STAGING_API_KEY o DATABASE_URL) come segreti dell’organizzazione in modo che siano disponibili in ogni sessione avviata dall’automazione
  • Troppi ticket dovuti a test instabili (flaky): aggiungi un retry al tuo playbook: “Esegui nuovamente qualsiasi test non superato una volta prima di aprire un ticket. Apri ticket solo per i test che falliscono due volte.”
  • I test richiedono troppo tempo: limita l’ambito della suite — ad es., “Esegui solo i test in tests/critical/ e tests/smoke/” — oppure aumenta il timeout della sessione
5

Gestisci le automazioni come codice

Una volta che l’esecuzione notturna è stabile, vorrai gestirla insieme alle altre automazioni — mettendola in pausa durante i periodi di blocco dei deploy, aggiornando il prompt quando la tua suite di test cambia o avviando una seconda automazione per un ambiente diverso.Metti in pausa l’automazione durante un periodo di blocco dei deploy o una finestra di manutenzione:
Riattivala quando termina il freeze:
Elenca tutte le automazioni per controllare cosa è in esecuzione:
Per i team che gestiscono più automazioni, chiedete a Devin di creare una CLI che sincronizzi le definizioni delle automazioni da un file di configurazione YAML, così da poter versionare le automazioni insieme alla configurazione dei test: