Come mi preparo e testo per i miei rilasci
Le release e la gestione delle release sono una parte essenziale del nostro lavoro. Rilasciare il prodotto giusto ai clienti li renderà felici. Eseguire una release senza intoppi renderà felici noi, cioè coloro che sono coinvolti nella release.
Come possiamo ottenere una release senza intoppi?
Avendo partecipato a un gran numero di release, posso dire che ci sono alcuni punti chiave che possono aiutare a ottenere una gestione delle release di successo.
Lascia che ti dica quali sono.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Una release di successo inizia durante lo sviluppo.
Identificazione dei casi di test
Una buona gestione delle release inizia molto prima del giorno del rilascio, già dal momento in cui la funzionalità da rilasciare è nella fase di sviluppo. In questo periodo, la funzionalità deve essere approvata da QA. Questo significa che dobbiamo testare tutti gli scenari possibili che riusciamo a immaginare e che abbiano senso per la funzionalità in questione, per verificare che questa rispetti i requisiti. Alcuni di questi scenari verranno testati da test automatizzati, mentre per altri, è troppo difficile o non vale la pena creare automazioni.
Quando identifichiamo il tipo di test da eseguire per la funzionalità, dovremmo considerare quanto segue: la prima volta che questa funzionalità va in produzione, dobbiamo testarla completamente. Dobbiamo assicurarci che i clienti non troveranno problemi critici. Occorre validare i requisiti. E dobbiamo garantire le buone prestazioni della funzionalità.
Ritardi e problemi nei test possono avere un impatto significativo sulle tempistiche quando si prepara una release software. Integrare pratiche efficaci di gestione delle release aiuterà a garantire che test e deployment rimangano affidabili e prevedibili.
Ma una volta che la funzionalità è attiva, a meno che non siano richiesti aggiornamenti, non è necessario testarla in modo così approfondito a ogni futuro rilascio della stessa base di codice. Il comportamento della funzionalità può cambiare solo se è stato modificato il codice sottostante o se c'è stato un cambiamento esterno a una delle dipendenze utilizzate. Negli altri casi, sarà sufficiente un sanity test della funzionalità, dove il sanity ovviamente includerà i casi di test più importanti.
Detto ciò, quando la funzionalità è in sviluppo, assicurati di valutare: quanti casi di test devi testare; quanto tempo hai a disposizione per i test; quali dei casi di test sono critici; quali dei casi di test eseguirai a ogni rilascio.
In questo modo puoi identificare quali sono i casi di test da automatizzare. Concentrati sull'avere almeno le funzionalità critiche coperte dall'automazione. Per il resto dei test, dovresti creare casi di test scritti, sia nel tuo sistema di tracciamento progetti (ad esempio Jira), sia nello strumento di gestione dei test che utilizzi. Così non andranno persi o dimenticati, e potranno essere eseguiti ogni volta che una release lo richiede.
Esecuzione dei test nella CI
Una volta che hai i test automatici, dovresti iniziare a eseguirli tramite la CI, sugli ambienti di sviluppo, periodicamente. Mentre vengono sviluppate altre funzionalità prima della release, è buona prassi assicurarsi che la funzionalità che vuoi rilasciare funzioni ancora correttamente, soprattutto se è già stata approvata durante lo sprint. Eseguire quotidianamente i test della funzionalità che ti interessa, ad esempio, ti fornirà feedback rapido su eventuali correzioni da applicare per bug causati da altri cambiamenti al sistema.
Una rilevazione precoce dei potenziali bug della funzionalità da rilasciare darà tempo sufficiente per applicare le correzioni e per ritestare la funzionalità, senza lo stress di dover fare tutto nel tempo limitato della fase di rilascio. Più ampia è la copertura dei requisiti nei tuoi test automatizzati, meno bug sarà probabile trovare in fase di rilascio.
La pre-produzione è importante e dovrebbe prevedere un buffer.
Tempistiche
La fase di rilascio solitamente consiste in un periodo dedicato al test in un ambiente di integrazione pre-produzione, separato dal giorno o periodo previsto per il rilascio in produzione. In qualità di tester coinvolto nella release, mi assicuro sempre di chiedere adeguati slot temporali per il rilascio, in modo che la fase di pre-produzione mi permetta di testare correttamente le funzionalità da rilasciare.
Considero inoltre sempre un tempo di buffer, perché mi aspetto che si presentino problemi imprevisti all'interno del processo di gestione della release, che siano essi bug nelle funzionalità da rilasciare o fattori esterni. Solo per citarne uno, gli ambienti di pre-produzione sono ambienti di test, e spesso non sono affidabili come dovrebbero. Molte volte funzionano molto lentamente o diventano indisponibili proprio durante i test della release.
Avere un margine di tempo aggiuntivo è sempre una buona idea e, anche se non dovessi utilizzare questo tempo extra, va bene così. Puoi dare il via libera prima che il tempo assegnato per il testing sia concluso, dato che puoi dedicare il tempo rimanente ad altro. È molto peggio non avere un margine di tempo e poi averne bisogno, poiché in questo caso dovrai in qualche modo adattare tutti i test necessari in un tempo più ristretto. Questo potrebbe portare a non eseguire alcuni casi di test, che a loro volta potrebbero far sì che alcuni bug vengano scoperti direttamente in produzione.
Ambito
Un altro aspetto importante della fase pre-produzione, dal mio punto di vista, è la presenza di un coordinatore dedicato per la gestione del rilascio. Per me questo significa una persona che si occupi di alcuni aspetti specifici, il primo dei quali è: verificare l’ambito del rilascio. Prima di iniziare a testare qualsiasi rilascio, chi esegue il testing deve sapere cosa testare. Si riduce tutto all’ambito del rilascio.
Le persone di prodotto, ovvero i PO o i BA, si aspettano che certe funzionalità siano incluse nel rilascio, e questo viene concordato all’inizio dello sviluppo. Tuttavia, il codice che viene incluso nel rilascio potrebbe non coprire sempre esattamente l’ambito che il team di prodotto si aspetta. A volte, capita che qualcuno dimentichi di inviare il codice al branch da cui si genera la build di rilascio. O peggio, qualcuno potrebbe inviare codice su questo branch che non dovrebbe essere incluso. Questo potrebbe riguardare funzionalità non ancora completate e approvate dal QA, oppure funzionalità che non fanno parte dell’ambito attuale.
Per assicurarsi che l’ambito venga rispettato, il coordinatore del rilascio dovrebbe confrontare l’ambito previsto con quello effettivo. A questo scopo, l’ambito atteso dovrebbe provenire dalle persone di prodotto e dovrebbe essere chiaramente documentato (magari anche nel tuo piano di assicurazione qualità). Ad esempio, potresti avere una qualche tipologia di documentazione di pianificazione che mostra le milestone del progetto e cosa è incluso in ciascuna di esse.
Per quanto riguarda l’ambito reale, dovrebbe essere estratto un changelog dal VCS (Sistema di Controllo di Versione, ad esempio Git) utilizzato dal progetto. Il changelog rifletterà tutti i commit effettuati nella fase di sviluppo sul branch che genererà la build di rilascio. Se lavori in modo organizzato, ogni commit dovrebbe contenere una descrizione che fa riferimento a un elemento di Jira collegato al codice. In questo modo puoi vedere tutti gli elementi Jira che hanno del codice incluso nella build di rilascio, e quali di questi non dovrebbero essere presenti. Naturalmente, se questi commit sono relativi a bugfix necessari, va benissimo. Quello che invece non vuoi è che questi commit rappresentino lavori su funzionalità non completate o su feature che non dovrebbero entrare in produzione con il rilascio attuale.
Man mano che approfondisci le tecniche avanzate di gestione del rilascio, scoprirai che integrare i tuoi processi con soluzioni di test management pensate per Jira può offrire un flusso di lavoro più coeso ed efficiente.
Quando si rileva una discrepanza tra l’ambito previsto e quello effettivo, il coordinatore della gestione del rilascio dovrebbe confrontarsi con il team di prodotto e i manager del team di sviluppo, per identificare il miglior approccio. Se i commit identificati come extra rispetto all’ambito rappresentano feature incomplete, è meglio rimuoverli. Questo perché ci si trova già nella fase di rilascio pre-produzione e non si vuole rischiare che il codice rimanente venga scritto e testato di fretta solo per inserirlo nella release. È rischioso, perché questa fretta può portare a dimenticare ed escludere casi di test importanti oppure lasciar passare bug critici in produzione. In questo caso, è meglio rimandare il completamento di quelle funzionalità a un futuro rilascio, fatto come si deve.
Il testing
Una volta chiarito l’ambito, può iniziare la fase di testing. Durante il testing pre-produzione, devi ri-validare tutta la funzionalità che stai rilasciando. Dovresti considerare che sia la prima volta che la vedi e testare ogni scenario che hai già verificato nella fase di sviluppo. Esegui i test automatici già scritti, ma nell’ambiente di pre-produzione, e non dimenticare gli scenari non automatizzati. Esegui una regressione completa su questa funzionalità, semplicemente perché, arrivati a questa fase di gestione del rilascio e nell’ambiente di pre-produzione, probabilmente anche altri team dovranno rilasciare nello stesso intervallo di tempo. È sostanzialmente la prima volta che tutte le dipendenze vengono riunite, con codice pronto per andare in produzione, nello stesso ambiente. E questa, in teoria, è la configurazione che sarà in esecuzione in produzione a partire dal rilascio.
A meno che, ovviamente, durante il testing non vengano rilevati dei problemi che richiedano delle correzioni. Se ciò dovesse accadere, bisogna considerare cosa sia necessario ritestare. Indipendentemente dal fatto che la correzione sia nel tuo codice o in una dipendenza esterna, se le modifiche influiscono in qualche modo sulla tua funzionalità, devi considerare un altro round di testing. Assicurati di ritestare almeno la funzionalità critica della feature.
Questo può sembrare noioso, soprattutto se durante questa fase si verificano molte correzioni. Tuttavia, non puoi prevedere con precisione l’impatto che le modifiche possono avere sulle diverse parti della tua funzionalità.
Piccoli cambiamenti possono causare effetti collaterali enormi, quindi è meglio annoiarsi ma avere la certezza che la funzionalità critica funzioni ancora, piuttosto che pentirsi di non aver testato a sufficienza.
E naturalmente, se un bug trovato in questa fase di testing è di entità minore, non preoccuparti di correggerlo subito. Ancora una volta, non è il caso di affrettare nessuna implementazione o test su una funzionalità che già funziona correttamente, per evitare il rischio di romperla.
Durante il rilascio, comunicazione e test sono fondamentali.
Una volta che la funzionalità è stata approvata nell'ambiente di pre-produzione, è pronta per essere rilasciata in produzione.
Comunicazione
Quando si tratta del rilascio in produzione, il coordinatore della gestione del rilascio ha alcuni compiti da svolgere. Prima di tutto, la data e l'orario del rilascio devono essere pianificati con anticipo e comunicati a tutte le parti interessate. Ritengo che fissare la data e l'orario del rilascio come una riunione nei calendari dei partecipanti sia molto utile per la gestione del rilascio, in modo che i partecipanti possano organizzare la loro giornata, attività che può essere svolta dal coordinatore.
Il giorno del rilascio, il coordinatore dovrebbe ricordare a tutti i coinvolti le tempistiche della release. Idealmente, la comunicazione dovrebbe avvenire su un canale che tutti usano, per esempio, Slack. Avere un canale Slack dedicato dove comunicare tutti gli aspetti importanti assicura che tutte le persone coinvolte abbiano una comprensione uniforme di quale fase del rilascio sia stata completata, quale sia lo scopo, quali problemi si sono verificati e chi può aiutare a risolverli. Una comunicazione strutturata garantisce che chiunque abbia bisogno di conoscere alcuni aspetti del rilascio vedrà tali informazioni, al contrario della comunicazione verbale (in cui la persona potrebbe essere assente senza che chi comunica se ne renda conto).
Il coordinatore della gestione del rilascio dovrebbe monitorare e annunciare le tappe fondamentali del rilascio su questo canale, come l'inizio del rilascio e la sua approvazione finale. Inoltre, ogni parte coinvolta dovrebbe comunicare tramite questo canale che sta eseguendo le proprie fasi assegnate affinché gli altri siano sempre aggiornati sullo stato e l'avanzamento della release. Se una qualsiasi parte fondamentale per il rilascio non è disponibile in un dato momento, il coordinatore deve mettersi in contatto con le persone giuste, per garantire che tutto proceda senza intoppi.
Il testing
Durante il rilascio in produzione, è necessario testare nuovamente l'intera funzionalità introdotta. Questo perché, anche se la funzionalità è stata approvata in altri ambienti di test, questi ambienti non sono mai identici al 100% in termini di configurazione e risorse a quello di produzione.
Per prevenire comportamenti imprevisti e indesiderati della funzionalità rilasciata, è importante eseguire tutti i test automatici disponibili, insieme alle parti non automatiche per cui sono stati scritti casi di test. Non dare mai l'approvazione in produzione senza aver testato una funzionalità.
Dare per scontato che la funzionalità funzioni in produzione non significa che lo faccia davvero.
Assicurati che funzioni, testala.
Dopo il rilascio
Quindi, il rilascio è stato eseguito. Tuttavia, assicurarsi che la funzionalità funzioni correttamente richiede più lavoro rispetto al solo test nella fase di rilascio.
Una volta fatto ciò, accertati che i tuoi test automatici vengano eseguiti nella CI, per la produzione. Questo permetterà di individuare eventuali comportamenti indesiderati causati da cambiamenti esterni di cui potresti non essere consapevole.
Monitora costantemente le prestazioni della funzionalità, per assicurarti che il carico di produzione e l'utilizzo da parte dei clienti non causino un degrado delle performance. E assicurati di tenere d'occhio tutte le segnalazioni di problemi inviate dai tuoi clienti. Queste segnalazioni possono indicare aree che non funzionano correttamente così da poter pianificare rapidamente un aggiornamento futuro, se necessario.
E, nel caso in cui il rilascio non sia andato come previsto, assicurati di organizzare una riunione retrospettiva post-release. In questa sede è possibile affrontare tutti i problemi riscontrati nel processo di gestione del rilascio, e assegnare le azioni correttive alle persone competenti, in modo che ogni rilascio futuro proceda senza intoppi e con successo.
