Skip to main content

​
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 > Advanced.
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.
L’attivazione delle build differenziali non forza una build completa. Se esiste già una build precedente riuscita o parziale per la stessa piattaforma e la stessa machine configuration, la build successiva può usarla come padre ed ereditarne lo stato. La build successiva viene eseguita come build completa solo nelle situazioni elencate in Quando viene eseguita una build completa. Per partire da una base pulita, seleziona Build completa dal menu a discesa Build snapshot.

​
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) con una immagine snapshot per la stessa piattaforma e la stessa machine configuration 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 e i secret, 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:
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 invece eseguita una build completa

Anche con le build differenziali abilitate, una build viene eseguita come build completa nei seguenti casi:
  • Richiedi una build completa — selezioni Build completa dal menu a discesa Build snapshot
  • La build completa più recente è troppo datata — una build automatica, ad esempio quella attivata dal salvataggio di un blueprint, viene eseguita come build completa quando non esiste alcuna build completa per la sua piattaforma oppure la più recente supera l’intervallo Aggiornamento build completa in Settings > Environment > Advanced (ogni 7 giorni per impostazione predefinita)
  • Non esiste una build padre riutilizzabile — non esiste alcuna build success o partial con una immagine snapshot per la stessa piattaforma e machine configuration
  • La build padre è incompatibile — la piattaforma, la machine configuration, l’immagine di base o l’impostazione Clone repositories on all platforms sono cambiate dopo la build padre, oppure la build padre non dispone di una base di segreti con cui effettuare il confronto
  • La configurazione dell’organizzazione o dell’enterprise è cambiata — un blueprint di organizzazione o enterprise, un file blueprint o un segreto sono cambiati dopo la build padre
Le modifiche circoscritte alle singole repository mantengono la build differenziale. Le nuove repository, le modifiche a blueprint o segreti di una repository e le repository non riuscite nella build padre vengono ricostruite all’interno della build differenziale. Riordinare le repository non attiva una build completa. Quando una build richiesta come differenziale viene invece eseguita come build completa, il tooltip Build kind nella pagina di dettaglio della build ne indica il motivo.

​
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

​
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.