Skip to main content

​
Per iniziare

Prerequisiti: Devin deve avere accesso ai tuoi repository prima che tu possa configurarne l’ambiente. Se non hai ancora configurato l’integrazione Git, consulta Prima di iniziare per i passaggi di configurazione. Gli utenti Enterprise devono anche concedere a ogni organizzazione l’accesso ai rispettivi repository in Enterprise Settings > Autorizzazioni repository.
Un blueprint è il formato che Devin utilizza per descrivere un ambiente: gli strumenti da installare, le dipendenze da mantenere e i comandi che deve conoscere. Devin può generare un blueprint dal tuo repository e puoi rivederlo o modificarlo ogni volta che desideri un maggiore controllo sulla configurazione.
Ideale per la maggior parte degli utenti. Devin esamina il tuo repository, determina quali strumenti, runtime e dipendenze sono necessari e genera il blueprint per te. Rivedi e approva la configurazione suggerita prima dell’avvio della build.
1

Avvia una sessione Devin

Apri una nuova sessione e chiedi a Devin di configurare il repository. Ad esempio: “Configura l’ambiente per questo repository.”
2

Rivedi e approva

Devin propone un blueprint in base a ciò che ha trovato. Vedrai delle schede di suggerimento nella tua timeline. Rivedi gli strumenti, le dipendenze e i comandi proposti, quindi fai clic su Approva.
3

Avvia la build e verifica

Dopo aver approvato i suggerimenti, viene eseguita una build che produce uno snapshot. Avvia una nuova sessione usando questo snapshot, quindi chiedi a Devin di eseguire i tuoi comandi di lint o di test per confermare che tutto funzioni.
Consulta il video e la panoramica della configurazione con un solo prompt nell’hub Environment.
Il resto di questa guida spiega come funziona il blueprint generato e come modificarlo quando desideri un maggiore controllo.

Vedilo applicato dall'inizio alla fine

Scenari: crescere con ACME Corp — un repository, poi più repository con dipendenze condivise, poi più organizzazioni. Blueprint completi per ogni fase e come decidere a quale livello appartiene ciascun elemento.

​
Come funziona

La configurazione dichiarativa si basa su tre concetti: I blueprint descrivono ciò che vuoi ottenere. Li scrivi e li modifichi nell’interfaccia Settings. Le build eseguono i blueprint per produrre snapshot. Le build vengono eseguite automaticamente quando salvi un blueprint e periodicamente (~ogni 24 ore) per mantenere aggiornate le dipendenze. Gli snapshot sono la base da cui si avviano le sessioni. Ogni organizzazione ha uno snapshot attivo. Ogni sessione avvia una nuova copia. Le modifiche apportate nella sessione non vengono salvate nello snapshot.

​
Sezioni del blueprint

Un blueprint ha tre sezioni principali, più un blocco post-build per i blueprint a livello di organizzazione/Enterprise e un blocco clone facoltativo per i blueprint a livello di repository: initialize è pensato per le operazioni che devono avvenire una sola volta: runtime dei linguaggi, pacchetti di sistema, strumenti CLI globali. maintenance è pensato per l’installazione delle dipendenze che devono rimanere aggiornate. Viene eseguito durante le build e mostrato all’agente all’inizio della sessione, così può eseguirlo di nuovo se le dipendenze sono cambiate (ad es. dopo aver recuperato la versione più recente del codice). I comandi non vengono eseguiti automaticamente all’inizio della sessione, ma devono comunque essere rapidi e incrementali (usa npm install, non npm ci). knowledge contiene informazioni di riferimento e non viene eseguito. È qui che indichi a Devin i comandi corretti per lint, testing e build. Mantieni le voci leggere e focalizzate sui comandi eseguibili. post-build (solo a livello di organizzazione ed enterprise) viene eseguito dopo che tutti i repository sono stati clonati e configurati, subito prima che lo snapshot venga salvato. Usalo per verificare l’ambiente assemblato — ad es. controlla che gli strumenti richiesti siano installati o che uno smoke test tra repository venga superato. Un codice di uscita diverso da zero causa il fallimento della build, quindi nessuno snapshot viene distribuito senza aver superato le tue verifiche. Vedi riferimento del blueprint → post-build. clone (solo a livello di repository) esegue l’override dei valori predefiniti che Devin usa quando clona il repository nello snapshot — ad esempio, facendo il checkout di un branch non predefinito (ref), cambiando la destinazione del clone (path) o saltando sottomoduli od oggetti LFS. Ogni campo è facoltativo. Per l’elenco completo dei campi, vedi riferimento del blueprint → clone.
Knowledge qui vs la funzionalità di prodotto Knowledge: La sezione knowledge del blueprint serve per brevi riferimenti ai comandi legati all’ambiente. Per documenti di architettura, convenzioni e flussi di lavoro del team, usa invece la funzionalità Knowledge standalone.
YAML multi-documento: L’editor del blueprint supporta YAML multi-documento usando il separatore ---. Questo ti consente di organizzare blueprint complessi in sezioni logiche all’interno di un singolo editor.
Per la specifica completa dei campi (tipi di passaggio, variabili d’ambiente, segreti e file allegati), vedi il riferimento del blueprint.

​
Ambito dei blueprint

Puoi definire i blueprint a due livelli: I blueprint sono additivi: i blueprint dei repository si aggiungono a quello dell’organizzazione. Il maintenance di un repository può usare gli strumenti installati nell’initialize dell’organizzazione. Se solo un repository ha bisogno di uno strumento, inseriscilo nel blueprint di quel repository. Se invece serve a tutti i repository, inseriscilo nel blueprint dell’organizzazione. Per i monorepo, un repository può avere un blueprint radice e blueprint workspace per ciascuna sottodirectory, ognuno con le proprie sezioni initialize, maintenance e knowledge e la propria directory di lavoro. Consulta Workspace e monorepo per istruzioni di configurazione ed esempi. Per esempi pratici su come scegliere un livello man mano che la codebase cresce, vedi Scenari: crescere con ACME Corp.
Utenti Enterprise: Esiste un terzo livello, il blueprint Enterprise, che si applica a tutte le organizzazioni. Per maggiori dettagli, consulta Panoramica dell’ambiente Enterprise.

​
Build e sessioni

​
Lo snapshot

La tua organizzazione ha uno snapshot attivo: un’immagine VM con i tuoi strumenti, repository e dipendenze già installati. Tutti i repository configurati vengono clonati e predisposti in quell’unica immagine. Ogni sessione si avvia da una copia pulita.

​
Come funzionano le build

Una build crea un nuovo snapshot eseguendo i blueprint in sequenza:
I layer sono additivi: i comandi specifici del repository possono utilizzare gli strumenti installati dal blueprint dell’organizzazione o dal blueprint Enterprise. I livelli inferiori non possono sovrascrivere quanto configurato da un livello superiore. Il tempo di build varia in base al numero di repository configurate e al lavoro svolto dai blueprint. I singoli passaggi vanno in timeout dopo 1 ora.

​
Come funzionano le sessioni

Ogni sessione avvia una copia pulita dello snapshot. Quando la sessione termina, tutte le modifiche vengono scartate. All’avvio della sessione:
  1. Viene scaricata la versione più recente del codice per i repository pertinenti.
  2. I comandi maintenance (Enterprise, organizzazione e repository) vengono resi disponibili all’agente come contesto — non vengono eseguiti automaticamente. L’agente può eseguirli di nuovo se rileva che le dipendenze sono cambiate dall’ultima build.
  3. Le voci di knowledge di quel repository vengono caricate nel contesto di Devin.
Knowledge è per repository. Se hai configurato 5 repository, Devin vede solo le voci di Knowledge del repository su cui sta lavorando.

​
Cosa attiva una build

Viene eseguita una sola build alla volta. Le nuove attivazioni annullano qualsiasi build in coda e ne avviano una nuova da zero.

​
Stati delle build

Una build parziale produce comunque uno snapshot funzionante. Tutti i repository sono stati clonati, quindi tutto il codice sorgente è disponibile nella sessione: non sono stati eseguiti solo i passaggi di configurazione dei blueprint che non sono riusciti. Se uno dei cinque repository ha un blueprint non funzionante, gli altri quattro sono completamente configurati e Devin può comunque leggere e lavorare sul quinto.
La build non riesce? Consulta Risoluzione dei problemi delle build per una guida al debugging passo passo.

​
Gestione del tuo ambiente

​
Stati dei repository

I repository possono trovarsi in tre stati nelle impostazioni di Environment: Incluso vs. configurato: un “repository” incluso viene clonato in modo che Devin possa accedere al codice, ma non ha comandi di configurazione personalizzati. Un “repository” configurato ha istruzioni esplicite di inizializzazione/manutenzione/Knowledge.

​
Secrets

Fai riferimento ai Secrets usando la sintassi $VARIABLE_NAME. Aggiungili nella scheda Secrets dell’editor del blueprint.
I segreti sono disponibili come variabili d’ambiente durante le build e le sessioni. Vengono rimossi prima che lo snapshot venga salvato, ma se un comando scrive un valore segreto in un file di configurazione durante initialize, quel valore rimane nello snapshot. Inserisci in maintenance i passaggi che scrivono le credenziali, così vengono aggiornati durante le build periodiche. Per maggiori dettagli sugli ambiti dei segreti e sul loro comportamento, consulta il riferimento del blueprint.

​
Repository multipli

Ogni repository ha il proprio blueprint. Durante una build, tutti i repository vengono configurati nello stesso snapshot, clonati in directory separate e con le dipendenze installate in modo indipendente. Se due repository installano versioni diverse di uno strumento globale o modificano file condivisi (come ~/.bashrc), ha la precedenza quello eseguito per ultimo. Per evitare conflitti, inserisci le installazioni degli strumenti condivisi nel blueprint a livello di organizzazione.

​
GitHub Actions

Invece di scrivere script shell per installare strumenti e runtime, puoi fare riferimento direttamente alle GitHub Actions nel tuo blueprint. Devin scarica ed esegue l’azione durante la build, proprio come i runner CI di GitHub eseguono i passaggi di un’azione.
Questo è particolarmente utile per le azioni di configurazione dei linguaggi come setup-python, setup-node e setup-go, che si occupano automaticamente della gestione delle versioni e della configurazione del PATH. Per dettagli sulla sintassi, esempi e limitazioni, consulta GitHub Actions nei blueprint.

​
Monorepo

Puoi eseguire comandi nelle sottodirectory tramite subshell oppure creare blueprint dedicati a livello di workspace per i singoli package. Devin supporta anche voci di Knowledge per package, in modo che ogni workspace abbia i propri comandi di lint, test e build. Consulta Workspace e monorepo per istruzioni di configurazione ed esempi.

​
Blocco e aggiornamenti automatici

Per impostazione predefinita, Devin usa lo snapshot della build riuscita più recente. Il blocco ti consente di fissare lo snapshot di una build specifica. È utile quando una nuova build introduce una regressione o quando vuoi congelare l’ambiente per un gruppo di sessioni. Per bloccare: vai a Settings > Environment > Snapshot, trova la build nella cronologia (deve essere success o partial e avere meno di 7 giorni) e fai clic su Blocca. Quando il blocco è attivo, gli aggiornamenti periodici vengono ignorati e l’interfaccia mostra Aggiornamenti automatici in pausa. Per sbloccare: fai clic su Riprendi aggiornamenti automatici. Devin passa alla build riuscita più recente.

​
Blueprint basati su Git

Puoi memorizzare i blueprint come file .devin/blueprint.yaml direttamente nel tuo repository. Dopo aver unito le modifiche, chiama l’API di sincronizzazione (o fai clic su Sync nella UI) per aggiornare il blueprint, quindi avvia una build. In questo modo ottieni lo stesso flusso di lavoro di revisione del codice che usi per il codice dell’applicazione, con la sincronizzazione automatizzata tramite un passaggio di CI. Consulta Git-backed blueprints per le istruzioni di configurazione e i dettagli.

​
Risoluzione dei problemi di build

​
Il passaggio Initialize non è riuscito

Cause comuni: errore di battitura in un comando shell, pacchetto non disponibile, timeout di rete, riferimento errato a GitHub Action. Soluzione: verifica i log di build per individuare l’errore esatto. Aggiorna initialize nel tuo blueprint e salva. Una nuova build viene attivata automaticamente.

​
Clonazione del repository non riuscita

Cause comuni: Devin non ha accesso al repository, il repository è stato rinominato/spostato/eliminato oppure si è verificato un problema di rete temporaneo. Soluzione: Verifica l’accesso al repository nelle impostazioni del provider Git. Rimuovi e aggiungi nuovamente il repository se è stato rinominato.

​
Passaggio di manutenzione non riuscito

Cause comuni: conflitto tra dipendenze, libreria di sistema mancante, spazio su disco esaurito, file di lock non aggiornato. Soluzione: Verifica i log del pacchetto o comando che ha causato l’errore. Aggiorna maintenance o initialize per installare le dipendenze mancanti, oppure correggi il file di lock nel tuo repository.

​
Timeout della build

Ogni passaggio del blueprint ha un timeout di 1 ora. I cloni dei repository hanno un timeout separato di 2 ore. Cause comuni: la compilazione dal sorgente di dipendenze native di grandi dimensioni (utilizza binari precompilati), il download di artefatti di grandi dimensioni, comandi che restano bloccati in attesa di input (tutti i comandi devono essere non interattivi).

​
Perfezionare le soluzioni

  1. Verifica i log di build per individuare l’errore
  2. Aggiorna il blueprint pertinente
  3. Salva (una nuova build si attiva automaticamente)
  4. Monitora i log della nuova build
  5. Ripeti finché la build non va a buon fine
Non è necessario attendere che una build fallita termini. Salvare una nuova configurazione annulla qualsiasi build in coda e ne avvia una nuova da zero.

​
Prossimi passaggi

Scenari: crescere con ACME Corp

Esempi pratici: un repository, poi più repository con dipendenze condivise, poi più organizzazioni.

Build differenziali

Accelera le build ricompilando solo i workspace i cui blueprint sono cambiati.

GitHub Actions nei blueprint

Usa GitHub Actions per installare linguaggi, strumenti e SDK senza dover scrivere script shell.

Workspace e monorepo

Subshell, ambiti del workspace e voci di Knowledge per repository multi-package.

Riferimento del blueprint

Riferimento completo dei campi: tipi di passaggio, variabili d’ambiente, segreti e file allegati.

Libreria di template

Blueprint da copiare e incollare per Python, Node.js, Go, Java, Ruby, Rust e pattern avanzati.

Blueprint basati su Git

Archivia i blueprint nel tuo repository come .devin/blueprint.yaml e sincronizzali tramite l’API o la UI.

Gestione degli ambienti Enterprise

Gestione degli ambienti a livello Enterprise: gerarchia a 3 livelli, segreti e configurazione tra organizzazioni.