> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Build differenziali
> Accelera i build di snapshot ricostruendo solo i workspace i cui blueprint sono stati modificati. I workspace invariati vengono ereditati dal build precedente completato con successo.
## Panoramica
Per impostazione predefinita, ogni snapshot build è una **build completa**: parte da un'immagine di base pulita, clona tutte le repository ed esegue ogni blueprint da zero. Questo garantisce un ambiente completamente riproducibile, ma può risultare lento quando hai modificato un solo blueprint su molti.
Le **build differenziali** ottimizzano questo processo riutilizzando lo snapshot della build riuscita precedente come punto di partenza. Vengono ricostruiti solo i workspace i cui blueprint sono stati effettivamente modificati; i workspace invariati vengono ereditati così come sono dalla build padre. Questo può ridurre significativamente i tempi di build, soprattutto per le organizzazioni con molte repository.
## Abilitare le build differenziali
Vai a **Settings > Environment > Advanced**.
Attiva l'opzione **build differenziale**. La descrizione è: *"Build più rapide grazie al riutilizzo dei workspace invariati."*
Salva una modifica al blueprint oppure fai clic su **Build snapshot**. La build successiva proverà a essere eseguita come build differenziale se esiste una build padre valida.
La prima build dopo l'attivazione delle build differenziali sarà sempre una **build completa**: il sistema ha bisogno di uno snapshot di base riuscito con cui fare il confronto. Le build successive saranno differenziali finché esisterà un padre valido.
## Come funziona
Quando viene avviata una build con le build differenziali abilitate, il sistema segue questo processo:
### 1. Trovare una build padre
Il sistema cerca la build riuscita più recente (status `success` o `partial`) da usare come build padre. Se non esiste una build padre valida, il sistema passa automaticamente a una build completa.
### 2. Confronta i blueprint
La configurazione di ciascun workspace viene confrontata con la build padre. Il sistema calcola un digest degli input di ogni workspace, inclusi i contenuti del blueprint, i file allegati, i secret e l'ordine dei repository, e verifica quali elementi sono cambiati.
### 3. Assegna le azioni ai workspace
In base al confronto, a ogni workspace viene assegnata una di queste tre azioni:
| Azione | Cosa succede | Quando si usa |
| ---------------- | ----------------------------------------------------------------------------------------- | -------------------------------------------------------------------- |
| **Ricostruisci** | Clona la repo ed esegue tutti i passaggi del blueprint (initialize + maintenance) da zero | Il blueprint è cambiato rispetto alla build padre |
| **Eredita** | Recupera il codice più recente ed esegue solo i passaggi `maintenance` | Il blueprint non è cambiato — riutilizza la configurazione del padre |
| **Rimuovi** | Elimina il workspace dallo snapshot | Il workspace è stato rimosso dalla configurazione |
Per i workspace ereditati, `initialize` non viene eseguito di nuovo. Scrivi `maintenance`
in modo che sia autosufficiente e possa essere eseguito in autonomia dopo aver
recuperato il codice più recente. Può usare strumenti e runtime già installati nello snapshot padre,
ma non deve richiedere che `initialize` venga eseguito immediatamente prima né basarsi su
variabili d'ambiente che `initialize` ha precedentemente scritto in `$ENVRC`.
### 4. Esegui la build
La build parte dall'immagine snapshot della build padre, anziché da una base pulita. Questo significa:
* **I workspace ereditati** hanno già strumenti, runtime e dipendenze installati. Il sistema recupera il codice più recente (`git pull`) ed esegue i comandi `maintenance` per aggiornare le dipendenze.
* **I workspace ricostruiti** vengono configurati da zero: clonati di nuovo ed eseguiti con la sequenza completa `initialize` + `maintenance`.
* **I workspace rimossi** vengono ripuliti dalle rispettive directory.
I blueprint di organizzazione e Enterprise saltano `initialize` durante le build differenziali (poiché questi strumenti sono già presenti nell'immagine padre) ed eseguono solo `maintenance`.
`$ENVRC` viene reimpostato all'inizio di ogni build, incluse le build differenziali.
Le variabili d'ambiente e le voci di `PATH` scritte in `$ENVRC` da una build precedente
non vengono ereditate. Se `maintenance` ne ha bisogno, deve configurarle
autonomamente.
## Quando viene eseguita invece una build completa
Anche con le build differenziali abilitate, il sistema ricorre a una build completa in alcune situazioni:
* **Non esiste alcuna build padre** — prima build, oppure tutte le build precedenti non sono andate a buon fine
* **Il blueprint dell'organizzazione o Enterprise è cambiato** — le modifiche globali interessano tutti i workspace, quindi una ricostruzione pulita è più sicura
* **L'ordine dei repository è cambiato** — poiché le repo possono dipendere dalla configurazione reciproca, una riorganizzazione attiva una ricostruzione completa
* **La build padre è troppo vecchia o incompatibile** — il sistema verifica che la build padre sia adatta
Quando si verifica un fallback, la pagina dei dettagli della build mostra il motivo sotto il badge del tipo di build.
## Visualizzare il tipo di build
Una volta completata una build, puoi vedere se è stata eseguita come build differenziale o build completa:
1. Vai a **Settings > Environment > Snapshots**
2. Fai clic su una build nella cronologia
3. Il badge **Build kind** mostra **Differential** (blu) oppure **build completa** (predefinito)
Passa il cursore sul badge per visualizzare un tooltip che spiega il significato di ciascun tipo:
* **Differential**: *"Vengono ricostruiti solo i workspace modificati; quelli invariati vengono ereditati dall'ultima build riuscita con la stessa configurazione"*
* **build completa**: *"Tutti i workspace vengono compilati da zero"*
## Vantaggi
| Vantaggio | Descrizione |
| ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Build più rapidi** | Solo i workspace modificati passano attraverso l'intero processo di configurazione. I workspace ereditati saltano completamente `initialize`. |
| **Minore utilizzo della rete** | I workspace invariati non riscaricano strumenti, runtime o dipendenze di grandi dimensioni. |
| **Iterazione più rapida** | Quando iteri sul blueprint di una singola repo, le altre repo non rallentano la build. |
| **Stessa affidabilità** | Se qualcosa non sembra corretto, il sistema torna automaticamente a una build completa. Puoi anche attivare manualmente una build completa in qualsiasi momento. |
## Avviare manualmente una build completa
Anche con le build differenziali abilitate, puoi forzare una build completa dal pulsante **Build snapshot**. Usa il menu a discesa per selezionare **build completa** invece dell'opzione differenziale predefinita.
Consigliamo di eseguire periodicamente una build completa per eliminare lo stato ereditato e verificare che i tuoi blueprint riescano ancora a creare l'ambiente da zero. Eseguine una anche dopo aver rimosso o sostituito configurazioni iniziali che potrebbero aver lasciato file, strumenti o dipendenze obsoleti nello snapshot. Una build completa riesegue tutti i passaggi `initialize` e `maintenance`.
## Domande frequenti
No. Le sessioni si avviano sempre dallo snapshot finale, indipendentemente da come è stato generato. L'unica differenza è la velocità della build.
Blocca una build precedente nota come valida da **Settings > Environment > Snapshots**, quindi avvia una build completa per ottenere uno snapshot pulito. Puoi anche disattivare del tutto le build differenziali per tornare alle build complete.
Sì. Una build con stato `partial` (alcuni workspace completati correttamente, altri non riusciti) può fungere da parent. Il sistema eredita solo dai workspace completati correttamente nel parent.