Una release non deve essere un azzardo.

Provenienza del build, dipendenze e limiti di accesso

Una pipeline elabora pacchetti esterni, strumenti di build e spesso accessi di ampia portata. Analizziamo questa catena di fiducia e separiamo i controlli sulle modifiche non attendibili dai passaggi con autorizzazioni di produzione. Gli ambienti di esecuzione richiedono diritti limitati e uno stato iniziale tracciabile. Le credenziali vengono fornite in modo controllato e non devono finire né negli artefatti né nei log di build.

Per l'artefatto pubblicato devono essere tracciabili lo stato del codice sorgente, le dipendenze e i controlli superati. Un elenco dei componenti supporta la successiva valutazione delle vulnerabilità note, ma non ne conferma automaticamente la sfruttabilità. Firme e attestazioni di provenienza servono solo se l'ambiente ricevente le verifica davvero. Per questo definiamo insieme generazione, archiviazione e verifica, e concordiamo come gestire componenti bloccati o accessi compromessi.

Distribuire insieme schemi di database e versioni dell'applicazione

In un rollout graduale, versioni vecchie e nuove dell'applicazione possono essere attive contemporaneamente. Una colonna del database rimossa subito o un formato dei messaggi modificato può danneggiare la versione precedente. Pianifichiamo quindi stati intermedi compatibili: aggiungere nuove strutture, migrare i dati in modo controllato, adeguare i chiamanti e solo dopo rimuovere le parti non più necessarie. Anche i job in background e i consumer esterni rientrano in questa valutazione.

I feature flag possono separare la distribuzione di una funzione dalla sua attivazione. Richiedono però una responsabilità chiara, varianti di test e una data di scadenza pianificata, altrimenti aumentano in modo permanente il numero di stati possibili. Per ogni rilascio si stabilisce quali versioni funzionano insieme e se un rollback dell'applicazione è ancora consentito. Le modifiche irreversibili ai dati richiedono una strategia diversa dalla semplice sostituzione dell'artefatto eseguibile.

Segnali di rilascio e miglioramenti nel flusso di sviluppo

Una distribuzione tecnicamente riuscita non è ancora una release riuscita. Dopo l'avvio osserviamo processi centrali selezionati, tassi di errore e tempi di risposta. Un rollout scaglionato può limitare la cerchia di utenti coinvolti, ma presuppone un'architettura adeguata e punti di misurazione significativi. Le soglie di interruzione e le persone responsabili vengono definite prima della modifica, così da non dover discutere dei criteri proprio quando il tempo stringe.

Per migliorare il processo esaminiamo i tempi di attesa per le review, la durata della pipeline, le interruzioni frequenti e l'impegno necessario per il ripristino dopo modifiche fallite. Queste informazioni servono a migliorare il flusso complessivo, non a stilare una classifica dei singoli sviluppatori. Un build rapido serve a poco se poi l'approvazione resta in sospeso per diversi giorni. Per questo le misure vengono messe in ordine di priorità insieme a sviluppo, sicurezza e team operativo, e verificate sui colli di bottiglia effettivi.