Processo di release management per chi rilascia spesso

Un processo di release management è l’insieme dei passi che porta una modifica da “integrata” a “in esecuzione in produzione e spiegata alle persone che riguarda”. Per un team che rilascia spesso si riduce a sette passi: pianificare l’ambito, isolare la modifica, compilare e testare, approvare, rilasciare e verificare, comunicare, e fare la revisione. Ogni passo ha bisogno di un responsabile con nome e di un criterio di uscita, altrimenti smette di accadere senza che nessuno se ne accorga.

Questa guida presuppone un team da 5 a 50 ingegneri che rilascia ogni settimana o ogni giorno e vuole che il processo non intralci.

Cos’è il processo di release management?

È il percorso ripetibile che una modifica segue per raggiungere gli utenti: ambito, build, test, approvazione, deploy, verifica, annuncio e bilancio finale. Il senso di metterlo per iscritto è che ogni rilascio segue lo stesso percorso, così una persona in ferie, un nuovo assunto o un ingegnere di turno alle 2 di notte può eseguirlo senza chiedere a nessuno come funziona.

Quali sono i diversi tipi di release management?

Ci sono tre tipi pratici: deploy continuo, rilasci programmati e gestione del cambiamento regolamentata. Si differenziano per quanto accade prima di un rilascio e quanto è automatizzato. Il deploy continuo rilascia ogni modifica integrata, i rilasci programmati raggruppano le modifiche in un treno, e la gestione del cambiamento regolamentata aggiunge approvazione formale e una traccia di audit.

La maggior parte dei team è un misto. Un prodotto SaaS può fare deploy continuo mentre la sua app mobile esce con un treno settimanale, e l’unico servizio di pagamenti che interessa ai revisori segue un record di cambiamento formale. Scegli il tipo per servizio, non per azienda. Dove le modifiche vengono esposte gradualmente, rilascio e annuncio diventano eventi separati, come nel caso trattato in release notes con feature flag.

Quali sono le responsabilità di un release manager?

Un release manager possiede il percorso che una modifica compie fino alla produzione. Tiene il calendario dei rilasci, decide se una modifica è pronta, esegue o supervisiona il deploy, prende la decisione sul rollback, si assicura che gli utenti siano avvisati e conduce la revisione successiva.

Prima del rilascio, conferma l’ambito e controlla che ogni modifica rischiosa abbia un percorso di rollback. Durante, esegue la checklist di deploy, osserva i primi minuti di metriche di produzione e decide presto un rollback. Dopo, conferma che le note siano uscite e registra cosa correggere nel processo.

In un team piccolo, ruota il ruolo ogni settimana e scrivi la checklist in modo che nessuno abbia bisogno di conoscenze tramandate a voce. Un monorepo con molti pacchetti rilasciati in modo indipendente di solito richiede un responsabile del rilascio per pacchetto, altrimenti il ruolo diventa un collo di bottiglia.

Quali sono i KPI chiave per il release management?

Segui le metriche di delivery del software DORA, e aggiungine una tua: quanto tempo passa prima che gli utenti vengano avvisati. La ricerca DORA individua cinque metriche, divise in throughput (tempo di consegna delle modifiche, frequenza di deploy, tempo di ripristino da deploy fallito) e instabilità (tasso di fallimento delle modifiche, tasso di rilavorazione dei deploy).

La guida DORA le definisce in termini semplici (dora.dev, software delivery metrics):

Il materiale più vecchio elenca quattro metriche chiave e chiama il ripristino “time to restore”. La guida attuale usa le cinque qui sopra.

La stessa guida avverte di non trattarle come obiettivi. Fissare un traguardo come “tutto viene rilasciato più volte al giorno entro fine anno” invita i team a truccare i numeri, e le metriche vanno lette per applicazione o servizio, non mescolate su tutta l’azienda. Il suo consiglio pratico per migliorarle tutte è ridurre la dimensione di ogni modifica, perché le modifiche più piccole sono più facili da rivedere, da far passare nella pipeline e da cui riprendersi.

Come si inserisce la comunicazione dei rilasci nel processo di release management?

È il passo sei, e ha un responsabile e un criterio di uscita come ogni altro passo: note pubblicate dove gli utenti le leggono, e team interni avvisati. È il passo che i team saltano più spesso, perché gli strumenti di deploy segnalano il successo nel momento in cui il codice è online.

Il modo più economico per tenere questo passo in orario è scrivere la voce quando la modifica viene integrata, non quando il rilascio esce. La pull request contiene già il titolo, l’autore, l’issue collegato e il contesto. Una bozza costruita da lì viene rivista, non scritta a memoria una settimana dopo. È l’idea dell’automazione del changelog: ricavare una bozza all’integrazione, tenerla in attesa di approvazione umana, poi pubblicarla ovunque da un’unica fonte. Changeloop funziona così, preparando le voci dalle pull request integrate con l’AI e tenendole in attesa di approvazione prima che venga pubblicato qualcosa.

Vale la pena pianificare in anticipo due varianti. Supporto e vendite hanno bisogno di una nota diversa da quella per i clienti, ed è a questo che servono le release note interne. Un rilascio guidato da un incidente non ha tempo per il normale ciclo di redazione, quindi tieni pronto un breve template, come descritto nelle release notes di emergenza. Il template di release notes ti dà una forma di partenza per la versione rivolta ai clienti.

Come si mantiene leggero il processo?

Automatizza ogni criterio di uscita che una macchina può controllare, e lascia agli umani i giudizi. Una pipeline verde, un marcatore di deploy sulle dashboard e una bozza di voce di changelog per ogni pull request integrata sono verificabili. Stabilire se un piano di rollback è credibile, o se le note hanno senso per un cliente, richiede una persona.

Per mettere alla prova il processo, scegli un rilascio del mese scorso e chiediti se qualcuno fuori dal team potrebbe capire, dalla sola documentazione scritta, cosa è stato rilasciato, chi l’ha approvato, come è stato verificato e quando gli utenti sono stati avvisati. Ogni lacuna è il tuo prossimo miglioramento.

FAQ

Qual è la differenza tra release management e change management? Il release management porta un insieme di modifiche a essere compilate, testate, rilasciate e annunciate. Il change management, in senso ITIL, è il processo di approvazione e di rischio attorno a ogni modifica. I team che rilasciano spesso fondono l’approvazione nella code review e nei controlli automatici.

Con che frequenza dovremmo rilasciare? Con la frequenza che i vostri test e il percorso di rollback permettono, che per molti team web è ogni giorno o più. L’indicazione di DORA è ridurre la dimensione di ogni modifica, perché le modifiche piccole sono più facili da rivedere e da cui riprendersi.

I team piccoli hanno bisogno di un release manager? Hanno bisogno delle responsabilità, ma non necessariamente del titolo. Fai ruotare il ruolo tra gli ingegneri, dai alla persona di turno una checklist scritta e assicurati che qualcuno sia responsabile di ciascuno dei sette passi.

Cosa dovrebbe includere una checklist di rilascio? Ambito confermato, pipeline verde sul commit da rilasciare, percorso di rollback nominato, approvazione registrata, smoke check dopo il deploy, metriche confrontate con la baseline, release notes pubblicate, supporto avvisato e una revisione in calendario. Tienila a una pagina.

Le affermazioni tecniche di questo articolo non sono state verificate in modo indipendente. Se qualcosa non è corretto, faccelo sapere e lo correggeremo.

Correlati su changeloop: Documentazione per sviluppatori, Modello di release notes