Non devi scrivere tutto questo a mano. Il modo più semplice per configurare il tuo ambiente è avviare una sessione di Devin e chiedergli di configurare la repo. Devin analizzerà il progetto, installerà le dipendenze e proporrà una configurazione: farai clic su Approve nelle schede di suggerimento della tua timeline.Questa guida è utile se vuoi comprendere ciò che Devin ha generato, personalizzarlo o scrivere una configurazione da zero.
Devin viene eseguito sulla propria VM. Ogni sessione si avvia da una immagine della macchina — uno snapshot salvato con strumenti, repo e dipendenze già preinstallati. Controlli cosa viene incluso in quell’immagine modificando la configurazione dell’ambiente in Settings > Ambiente di Devin.
Usa initialize per tutto ciò che richiede molto tempo o che deve essere fatto una sola volta: installare gestori di pacchetti, strumenti CLI globali, compilare dipendenze native o aggiungere pacchetti di sistema.I risultati vengono salvati nell’immagine della macchina e non vengono eseguiti di nuovo all’avvio della sessione.
La stringa su più righe viene eseguita come un unico script bash con set -e, quindi qualsiasi riga che fallisce interrompe la build. Usa \ per continuare sulla riga successiva oppure passa alla forma estesa per passaggi denominati che compaiono singolarmente nei log di build.
Il file dei segreti viene rimosso prima che l’immagine della macchina venga salvata. Se un comando in initialize scrive un valore segreto in un file di configurazione (ad esempio un token di autenticazione in .npmrc), quel valore potrebbe persistere nell’immagine, con conseguente rischio per la sicurezza. Inserisci invece in maintenance i passaggi che scrivono credenziali, dove i secrets vengono ricaricati a ogni sessione.
Quando ti servono passaggi con nome, usa la forma elenco.I passaggi con nome rendono i log di build più facili da esaminare durante il debug: quando qualcosa non funziona, vedrai quale passaggio si è interrotto invece del solo numero di riga.
Per impostare le variabili d’ambiente per i passaggi successivi, scrivi righe nel formato KEY=VALUE nel file $ENVRC (come $GITHUB_ENV di GitHub Actions). Tutte le variabili scritte in $ENVRC vengono esportate automaticamente per i passaggi successivi e per la sessione di Devin.
Usa maintenance per mantenere aggiornate le dipendenze e scrivere i file di configurazione delle credenziali.Viene eseguito durante la build (dopo initialize) e all’inizio di ogni sessione, dopo aver scaricato il codice più recente. Poiché viene eseguito all’inizio di ogni sessione, i comandi dovrebbero essere rapidi e incrementali.
Usa npm install, non npm ci.npm ci elimina node_modules e reinstalla tutto da zero a ogni run. npm install esegue un aggiornamento incrementale, molto più rapido quando le dipendenze non sono cambiate.
Qualsiasi passaggio che scrive segreti nei file di configurazione (.npmrc, settings.xml, pip.conf) deve appartenere a maintenance, non a initialize. In questo modo, le credenziali restano aggiornate all’inizio di ogni sessione.
Usa knowledge per piccole informazioni di configurazione di cui Devin ha bisogno per usare effettivamente l’ambiente che hai appena creato — ad esempio il comando lint, il comando di test o come avviare il server di sviluppo.
Non è la stessa cosa della funzionalità principale Knowledge. Per la maggior parte delle cose che vuoi che Devin ricordi — architettura, convenzioni, aspetti da tenere presenti, flussi di lavoro del team — usa la funzionalità Knowledge separata. Offre trigger più avanzati, è più facile da modificare ed è il posto giusto per il contesto generale del progetto.Usa la sezione knowledge in environment.yaml solo per brevi note direttamente collegate alla configurazione dell’ambiente in questo file (ad es., “il comando lint è npm run lint”). Questa sezione è facoltativa e la maggior parte degli ambienti non ne ha bisogno.
Le voci sono note di riferimento — non vengono eseguite. Mantienile brevi:
knowledge: - name: lint contents: | Run `npm run lint` to check for errors. Run `npm run lint:fix` to auto-fix. - name: test contents: | Run `npm test` for the full suite. Run `npm test -- --watch` during development. - name: startup contents: | Run `npm run dev` to start the dev server on port 3000.
Devin supporta tre livelli di configurazione. I comandi di ciascun livello sono strettamente additivi: vengono eseguiti in sequenza durante le build e i livelli inferiori non possono sovrascrivere né modificare ciò che viene configurato dai livelli superiori.
Livello
Dove configurare
Cosa inserire qui
Esempi
A livello di account (Enterprise)
Enterprise Settings > Environment
Infrastruttura necessaria a tutte le org
certificati CA, proxy aziendale, VPN, DNS
A livello di org
Settings > Environment > Organization-wide setup
Strumenti e configurazione condivisi tra tutti i repo
runtime del linguaggio (pnpm, uv), autenticazione Docker, strumenti CLI condivisi
Specifico del repo
Settings > Environment > [repo]
Configurazione e Knowledge specifici del progetto
npm install, comandi di lint/test/build, note sull’architettura
Come decidere cosa va dove:
Se serve a ogni org della tua Enterprise → a livello di account
Se serve a ogni repo della tua org → a livello di org
Se serve solo a un repo → specifico del repo
Utenti Enterprise: Per indicazioni dettagliate sulla configurazione a livello Enterprise — autorizzazioni, build in cascata, gestione multi-org e migrazione Enterprise — consulta la pagina Enterprise Environment Setup.
La tua organizzazione dispone di un’immagine della macchina: uno snapshot di una VM con strumenti, repo e dipendenze già preinstallati. Tutte le repo configurate vengono clonate e configurate in quell’unica immagine. Ogni sessione si avvia da una nuova copia.
Una build crea una nuova immagine della macchina nel seguente ordine:
1. Enterprise config (runs in ~): a. initialize b. maintenance2. Org-wide config (runs in ~): a. initialize b. maintenance3. Clone all repositories (up to 10 concurrent)4. For each configured repo, in the order shown in Settings (runs in ~/repos/<repo-name>): a. initialize b. maintenance5. Health check, then image is saved
I livelli sono additivi: i comandi specifici per repo possono usare gli strumenti installati dalla configurazione dell’org o di Enterprise. I livelli inferiori non possono sovrascrivere ciò che è stato configurato a un livello superiore.Le build richiedono in genere 5–15 minuti. I singoli comandi vanno in timeout dopo 1 ora; l’intera build va in timeout dopo 2 ore.
Ogni sessione avvia una nuova copia dell’immagine della macchina. Quando la sessione termina, tutte le modifiche vengono scartate.All’avvio della sessione:
Vengono eseguiti i run maintenance di Enterprise e a livello di org (in ~).
Viene scaricato il codice più recente per le repo pertinenti.
Il maintenance di quella repo viene eseguito di nuovo per recepire eventuali modifiche alle dipendenze dall’ultima build.
Le voci knowledge di quella repo vengono caricate nel contesto di Devin.
Knowledge è per repo. Se hai configurato 5 repo, Devin vede solo le voci di Knowledge della repo su cui sta lavorando.
Tutti i passaggi sono stati completati. L’immagine della macchina è pronta.
Partial
Alcuni repo non sono andati a buon fine, ma la build principale è riuscita. Le sessioni funzioneranno, ma alcuni repo potrebbero non essere configurati completamente.
Failed
La build principale non è riuscita (ad esempio, per un errore di clone o perché la configurazione di Enterprise/org non è riuscita).
Cancelled
Sostituita da una build più recente.
Skipped
Non sono state rilevate modifiche alla configurazione.
La build non riesce? Consulta Troubleshooting & FAQ per una guida al debug passaggio per passaggio.
Nell’interfaccia Settings di Environment, i repository compaiono in tre stati:
Stato
Significato
Configurato
Ha una configurazione YAML con initialize/maintenance/Knowledge. È completamente configurato nella immagine della macchina.
Incluso
Clonato nella immagine della macchina, ma senza configurazione personalizzata. Devin può accedere al codice.
Disponibile
Accessibile all’org, ma non aggiunto all’Environment. Non clonato.
Incluso vs. configurato: un repo “incluso” viene clonato in modo che Devin possa accedere al codice, ma non ha comandi di configurazione personalizzati. Un repo “configurato” ha istruzioni esplicite di initialize/maintenance/Knowledge.
I segreti sono disponibili come variabili d’ambiente durante le build e le sessioni. Il file dei segreti viene rimosso prima che l’immagine della macchina venga salvata — ma se un comando ha espanso un valore segreto in un file di configurazione durante initialize, quel valore espanso potrebbe persistere nell’immagine. Scrivi invece sempre le credenziali in maintenance, dove vengono caricate di nuovo a ogni sessione.Per ulteriori informazioni sulla gestione dei segreti, vedi Secrets & Site Cookies.
Quando configuri più repo, ciascuna ha il proprio YAML in Settings. Durante una build, vengono tutte configurate nella stessa immagine — clonate in directory separate, con le dipendenze installate in modo indipendente. Durante una sessione, solo la manutenzione e la Knowledge della repo attiva sono pertinenti.Cosa succede se due repo entrano in conflitto? I comandi di ogni repo vengono eseguiti nella relativa directory, quindi i conflitti tra dipendenze sono rari. Se due repo installano versioni diverse di uno strumento globale o modificano file condivisi (come ~/.bashrc), prevale quella eseguita per ultima. Per evitarlo, inserisci l’installazione degli strumenti condivisi nella configurazione a livello di org.
Per un monorepo, scrivi un unico file YAML che copre tutti i sottoprogetti. Usa le subshell per eseguire comandi nelle sottodirectory senza modificare la directory di lavoro nei passaggi successivi:
Le parentesi (cd ... && ...) sono importanti — eseguono il comando in una subshell, così la directory di lavoro viene reimpostata per il passaggio successivo.Quando usare la configurazione multi-repo o monorepo: Se il codice si trova in un unico repository Git, usa un unico file YAML con subshell. Se è distribuito su più repository Git, configura ogni repo separatamente in Settings.
