Vai al contenuto principale

​
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

1

Vai alle impostazioni dell'ambiente

Vai a Settings > Environment > Snapshots.
2

Attiva l'opzione

Attiva l’opzione build differenziale. La descrizione è: “Build più rapide grazie al riutilizzo dei workspace invariati.”
3

Avvia una build

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:
AzioneCosa succedeQuando si usa
RicostruisciClona la repo ed esegue tutti i passaggi del blueprint (initialize + maintenance) da zeroIl blueprint è cambiato rispetto alla build padre
EreditaRecupera il codice più recente ed esegue solo i passaggi maintenanceIl blueprint non è cambiato — riutilizza la configurazione del padre
RimuoviElimina il workspace dallo snapshotIl 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

VantaggioDescrizione
Build più rapidiSolo i workspace modificati passano attraverso l’intero processo di configurazione. I workspace ereditati saltano completamente initialize.
Minore utilizzo della reteI workspace invariati non riscaricano strumenti, runtime o dipendenze di grandi dimensioni.
Iterazione più rapidaQuando 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.