):
a. initialize
b. maintenance
5. Health check, then snapshot is saved
```
I layer sono **additivi**: i comandi specifici per repo possono usare gli strumenti installati dall'org o dal blueprint 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 passaggi scadono 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 le repo pertinenti.
2. I comandi `maintenance` (Enterprise, org e repo) 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 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.
### Cosa attiva una build
| Attivazione | Descrizione |
| ------------------------------------- | ---------------------------------------------------------------- |
| Salvataggio di un blueprint | Creazione, aggiornamento o eliminazione di un blueprint |
| Aggiunta o rimozione di un repository | Qualsiasi modifica all'elenco dei repository |
| Aggiunta di un segreto del repository | Per rendere disponibili i nuovi segreti è necessaria una rebuild |
| Attivazione manuale | Facendo clic su **Build snapshot** nella UI |
| Aggiornamento periodico | Automatico, circa ogni 24 ore |
| Suggerimento di Devin | Devin propone una modifica al blueprint durante una session |
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
| Status | Meaning |
| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Success** | Tutti i passaggi sono stati completati. Lo snapshot è pronto. |
| **Partial** | Alcuni passaggi a livello di repo non sono andati a buon fine, ma lo snapshot è utilizzabile. Le repo completate con successo funzionano normalmente; per quelle non riuscite è necessario correggere i blueprint. |
| **Failed** | Errore critico (configurazione dell'org o di Enterprise non riuscita). Lo snapshot non è utilizzabile. |
| **Cancelled** | Sostituita da una build più recente o annullata manualmente. |
Una build **parziale** produce comunque uno snapshot funzionante. Se una repo su cinque ha un blueprint non valido, le altre quattro sono completamente funzionali.
**La build non va a buon fine?** Consulta [Risoluzione dei problemi delle build](#troubleshooting-builds) per una guida al debug passaggio per passaggio.
## Gestione del tuo ambiente
### Stati dei repository
I repository possono trovarsi in tre stati nelle impostazioni di Environment:
| Stato | Significato |
| --------------- | -------------------------------------------------------------------------------------------------------- |
| **Configurato** | Ha un blueprint con inizializzazione/manutenzione/Knowledge. È completamente configurato nello snapshot. |
| **Incluso** | Clonato nello snapshot, ma senza blueprint personalizzato. Devin può accedere al codice. |
| **Disponibile** | Connesso all'org, ma non aggiunto all'ambiente. 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 inizializzazione/manutenzione/Knowledge.
### Secrets
Fai riferimento ai Secrets usando la sintassi `$VARIABLE_NAME`. Aggiungili nella scheda **Secrets** dell'editor del blueprint.
```yaml theme={null}
maintenance:
- name: Configure private registry
run: npm config set //registry.npmjs.org/:_authToken $NPM_TOKEN
```
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](/it/onboard-devin/environment/blueprint-reference#environment-variables-and-secrets).
### Repository multipli
Ogni repo ha il proprio blueprint. Durante una build, tutte le repo vengono configurate nello stesso snapshot, clonate in directory separate e con le dipendenze installate in modo indipendente.
Se due repo installano versioni diverse di uno strumento globale o modificano file condivisi (come `~/.bashrc`), ha la precedenza quella eseguita per ultima. Per evitare conflitti, inserisci le installazioni degli strumenti condivisi nel blueprint org-wide.
### 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.
```yaml theme={null}
initialize:
- name: Install Python 3.12
uses: github.com/actions/setup-python@v5
with:
python-version: "3.12"
```
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](/it/onboard-devin/environment/github-actions).
### 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](/it/onboard-devin/environment/workspaces) 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](/it/onboard-devin/environment/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 alla repo, la repo è stata rinominata/spostata/eliminata, problema di rete temporaneo.
**Soluzione:** Verifica l'accesso alla repo nelle impostazioni del provider Git. Rimuovi e aggiungi nuovamente la repo se è stata rinominata.
### 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 ha un timeout di 1 ora. 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
Accelera le build ricompilando solo i workspace i cui blueprint sono cambiati.
Usa GitHub Actions per installare linguaggi, strumenti e SDK senza dover scrivere script shell.
Subshell, ambiti del workspace e voci di Knowledge per repo multi-package.
Riferimento completo dei campi: tipi di passaggio, variabili d'ambiente, segreti e file allegati.
Blueprint da copiare e incollare per Python, Node.js, Go, Java, Ruby, Rust e pattern avanzati.
Archivia i blueprint nel tuo repo come `.devin/blueprint.yaml` e sincronizzali tramite l'API o la UI.
Guida passo passo per passare dalla procedura guidata interattiva ai blueprint dichiarativi.
Gestione degli ambienti a livello Enterprise: gerarchia a 3 livelli, segreti e configurazione tra org.