Decidi un rilascio sulla base delle prove

Formula la decisione con precisione

Una pipeline verde fornisce prove da un insieme di verifiche. Non descrive completamente la decisione di rilascio. Il responsabile deve sapere cosa cambierà, dove cambierà e quali conseguenze restano.

Per un’esportazione fittizia dei clienti, identifica il commit accettato e l’artefatto prodotto da esso. Indica l’ambiente di destinazione. Collega test pertinenti, revisione ed eventuali eccezioni approvate. Includi le modifiche ai dati o all’infrastruttura che accompagnano l’applicazione.

L’SSDF del NIST offre pratiche di sviluppo sicuro, mentre la provenance SLSA aiuta a descrivere come è stato prodotto un artefatto. Nessuno dei due elimina la necessità di decidere se questo rilascio sia adeguato a questo servizio. NIST SSDF, SLSA provenance.

Separa tre eventi

Il merge inserisce una modifica al sorgente in un branch. Il deployment inserisce un artefatto in un ambiente. Rendere disponibile una funzionalità espone il comportamento agli utenti. Gli eventi possono coincidere, ma non sono necessariamente lo stesso evento.

Un servizio può distribuire una funzionalità inattiva e renderla disponibile in seguito. Una migrazione del database può influire sulla produzione prima che compaia una funzionalità visibile. Definisci la sequenza effettiva invece di presumere che il merge di una PR descriva ogni conseguenza.

Per l’esportazione, un feature flag può limitare la disponibilità iniziale. Non protegge automaticamente un nuovo endpoint né annulla una migrazione dello schema. Verifica il controllo nel punto in cui si produce la conseguenza.

Esamina un riepilogo compatto delle prove

Usa una registrazione esaminabile da un’altra persona responsabile:

• Scopo e utenti interessati.
• Identità del commit e dell’artefatto.
• Verifiche pertinenti di comportamento, sicurezza e compatibilità.
• Ambiente di destinazione e identità di esecuzione.
• Eccezioni residue con responsabili e condizioni di scadenza.
• Monitoraggio, metodo di recupero e responsabile della risposta.

Mantieni specifiche le affermazioni. «Test superati» è meno informativo di un collegamento ai risultati del commit di rilascio con una descrizione chiara della copertura. «Rollback disponibile» è meno informativo di una procedura provata con limiti dichiarati.

Decidi come fermarti

Definisci le condizioni di rilascio prima dell’esecuzione. Per l’esportazione fittizia, fermati se l’accesso tra organizzazioni riesce, se l’artefatto differisce dal digest accettato o se il recupero non è disponibile. Sono condizioni illustrative, non una checklist universale.

Dopo il deployment, esamina i segnali importanti per gli utenti. Confronta errori e tempi di risposta con gli obiettivi accettati del servizio. Un processo sano non dimostra che il flusso dell’utente funzioni.

Se una condizione non è soddisfatta, usa la risposta concordata. Può significare disabilitare la funzionalità per gli utenti, fare il rollback del codice compatibile o recuperare i dati. Scegli l’azione che risolve il guasto senza crearne uno maggiore.

Conserva la decisione dopo il rilascio

Registra l’artefatto effettivamente distribuito e il risultato. Se l’esecuzione differisce dal piano, rendi visibile la differenza. Usa incidenti e lavoro imprevisto per progettare il rilascio successivo.

Un sistema di consegna automatico deve rendere queste informazioni più facili da esaminare. Non deve costringere il revisore a ricostruire il rilascio da chat, log e schermate scollegati. Prove chiare consentono ai team di automatizzare il lavoro ordinario mantenendo decisioni con responsabilità definite.