Quando si tratta di consegna della mischia, le persone di solito si aspettano un’esecuzione del rilascio dopo la fine di uno sprint. Ciò significa subito dopo una presentazione demo di successo al cliente.
Ma mi sono sempre chiesto come potesse essere un’aspettativa così automatica. Soprattutto se si considerano le seguenti possibili attività che devono svolgersi prima o accanto.
- Sviluppa e completa tutte le storie all’interno dello sprint. Alcuni potrebbero essere completati prima, ma la maggior parte delle volte le storie vengono completate appena prima della fine dello sprint. Forse anche dopo la presentazione della demo, per essere aperti qui.
- Esegui tutti i test pianificati sul contenuto dello sprint per assicurarti che il codice da rilasciare sia pronto per la produzione.
- Resta al passo con i bug scoperti e correggili in tempo prima che avvenga il rilascio.
- Assicurati che la pipeline di distribuzione sia aggiornata con il contenuto più recente e che la pipeline stessa sia affidabile da eseguire.
- Esegui la pipeline su tutti gli ambienti pertinenti per portarli allo stato più recente dal punto di vista del codice e dei dati.
- Prepara le note di rilascio e comunica con il cliente l’impatto del rilascio e cosa cambierà esattamente in seguito.
- Se pertinente, eseguire la sincronizzazione con altri team di scrum paralleli per garantire che il contenuto dipendente venga rilasciato contemporaneamente. Non dovrebbe mancare nulla per garantire che il contenuto della tua versione funzioni come previsto.
- Oltre a tutto questo, partecipa a tutte le cerimonie di mischia. Non solo relative allo sprint corrente, ma anche a quelle previste per il prossimo sprint (ad esempio, sessioni di raffinamento delle storie).
Ora immagina che lo sprint abbia due settimane.
Le attività di rilascio da sole richiedono tempo e persone per essere completate. Ma non può volerci troppo. Subito dopo l’ultimo giorno dello sprint arriva direttamente il primo giorno dello sprint successivo e il cerchio ricomincerà.
L’aspettativa di rilascio dopo ogni sprint sembra ancora così automatica?
Sommario:
Rilascia l’elaborazione dei contenuti
Se tutti i processi all’interno dello sprint sono automatizzati, c’è la possibilità di “premere il grilletto” e installare l’ultima versione del codice in produzione alla fine di ogni sprint. Il problema è che non ho mai sperimentato uno stato così perfetto del team di mischia.
Se è effettivamente così in alcune piccole imprese private, le invidio davvero. Ma la realtà nel mondo aziendale è che un team di mischia non raggiungerà quel livello di maturità. Al contrario, i processi di rilascio sono solitamente collegati ad attività che richiedono tempo e raggiungono la maggior parte dello sprint successivo, influenzando tale sprint dal punto di vista del contenuto e di tutte le metriche. Il rilascio è solo un atto stressante che nessuno nel team è felice di affrontare.
Quindi stavo dopo aver scoperto il prossimo miglior scenario per gestire i rilasci.
La conclusione è stata quella di rendere ogni secondo sprint il Release Sprint. Ecco cosa significa.
Versione in codice separato per la prossima versione
Si tratta di gestire rami separati nel repository GIT. Esistono molti modi per affrontare lo stesso problema e tutti possono avere successo. Ma ai fini di questo articolo, manterrò le cose semplici per dimostrare l’approccio e il suo impatto.
Per ridurre il più possibile l’impatto sulle attività di sviluppo in corso, è importante separare il contenuto per la prossima versione in un ramo separato. Chiamiamolo Release Branch. Con ciò si risolvono:
- Il team di sviluppo può continuare le attività e fondersi nelle nuove storie del ramo principale senza interruzioni.
- Non vi è alcun rischio che il contenuto della versione venga influenzato da modifiche impreviste del codice da parte dello scrum team.
- Le attività di test possono essere eseguite in uno spazio isolato. Qui verranno introdotte solo le modifiche necessarie per risolvere il test.
- Poiché la pipeline di rilascio distribuirà in produzione solo il contenuto del ramo di rilascio, abbiamo un processo chiaro e il pieno controllo sul contenuto da rilasciare. Non può succedere che un commit imprevisto nel ramo Git rompa il codice già testato.
Quindi tieni da parte il contenuto della prossima versione e lascia che si concluda in uno stato stabile, pronto per il rilascio.
Cronometra le versioni in modo che funzionino ripetutamente
Ho rinunciato all’ambizione di fare il rilascio dopo che ogni singolo sprint fosse stato completato. Era super chiaro che non avrebbe avuto alcuna possibilità di funzionare. Almeno non con effetti collaterali come:
- che incidono sul prossimo contenuto di sviluppo dello sprint,
- non essere in grado di stabilizzare il contenuto della versione,
- mettersi al passo con tutte le attività di test richieste, ecc.
Quindi l’obiettivo era eseguire il rilascio entro la fine di ogni secondo sprint. Ciò implicherebbe quanto segue:
- Una pubblicazione conterrà sempre le storie degli ultimi due sprint già terminati. Poiché il rilascio viene eseguito all’interno dell’attuale (sprint attivo), questo contenuto dello sprint non è ancora incluso nel rilascio.
- C’è un intero tempo di uno sprint per il completamento delle attività di test necessarie e delle correzioni di bug.
- Il proprietario del rilascio ha tempo sufficiente per raccogliere informazioni rilevanti per il rilascio (casi di test, note di rilascio, ecc.) con lo sprint di non rilascio. In questo modo, possono operare sostanzialmente in modo autonomo e lasciare che il resto del team di sviluppo lavori su nuove storie.
- In caso di rilevamento di bug, il proprietario della versione può connettersi rapidamente con lo sviluppatore concreto per risolvere il problema e tornare al contenuto dello sprint corrente. Quindi dovrebbe sempre esserci una percentuale di tempo allocata dalla capacità del team di supportare la correzione di questo bug. Quanto esattamente può essere scoperto nel tempo.
È chiaro che gli utenti non riceveranno l’ultimo contenuto di sprint all’interno dell’ultima versione. Ma nel tempo, questo diventerà irrilevante. Riceveranno comunque due sprint di contenuti con ogni versione successiva, dopo ogni secondo sprint.
Questo sembra un buon compromesso tra la soddisfazione della consegna rapida e il tenere il passo con le attività di mischia senza disturbi significativi.
Eseguire la distribuzione della versione
Quando le attività di test, correzione dei bug e prontezza della pipeline vengono completate con successo, è un processo abbastanza semplice eseguire la pipeline di produzione e completare il rilascio alla produzione.
Poiché viene distribuito da un ramo autonomo, questa può essere fondamentalmente un’attività inosservata e invisibile. Nessuno ha bisogno di sapere. Se questo è il caso, è la migliore implementazione possibile della distribuzione del rilascio.
Un prerequisito per questo è aver creato una solida pipeline DevOps automatizzata. Utilizzato non solo per la distribuzione nell’ambiente di produzione, ma anche in tutti gli altri ambienti di livello inferiore. Ciò potrebbe includere sviluppo, sandbox, test, garanzia della qualità, ambiente delle prestazioni, ecc. Questo deve essere un clic per distribuire tutte le soluzioni per ogni singolo ambiente.
Il rilascio non dovrebbe essere un punto dolente o uno stress. O un incubo che tutti temono e continuano a prepararsi per quel giorno per una settimana. No – invece, se nessuno se ne accorge mai, questo è il miglior segno di un rilascio di successo.
Unisci nuovamente il ramo di rilascio nel ramo di sviluppo
Il ramo di rilascio ora contiene alcuni contenuti speciali che non esistono nel normale ramo di sviluppo in corso. È correlato a tutte le correzioni implementate durante il periodo di test. Questo contenuto deve essere riunito nuovamente nel ramo di sviluppo per garantire che le correzioni rimangano lì anche dopo la prossima versione.
A quel punto, l’ultimo ramo di rilascio funge da codice di produzione pronto per la ridistribuzione di emergenza. Se un problema urgente ad alta priorità deve essere risolto poco dopo la distribuzione della produzione, può utilizzare questo ramo. È semplice prendere questo codice e implementare la correzione all’interno. Questa è ancora la copia esatta dell’attuale codice di produzione senza alcun nuovo contenuto inedito.
Infine, una volta iniziato il nuovo periodo di test, il ramo di rilascio precedente può essere eliminato e sostituito da uno nuovo. Il nuovo viene nuovamente creato come copia dal ramo di sviluppo corrente.
Stabilire rilasci regolari
E ora ce l’abbiamo 😀—un solido processo per avvicinarsi al rilascio. L’unica cosa che manca è impegnarsi a mantenerlo regolare. In questo caso, dopo ogni secondo sprint.
Mantenendolo regolare, in realtà prepariamo il terreno per renderlo più facile da realizzare, principalmente perché:
- Se il rilascio avviene dopo un tempo non troppo lungo, non ci sono molti nuovi contenuti da installare in produzione. L’incremento è piccolo e considerato stabile.
- Ora così tanti nuovi contenuti significano non molte attività di test e creazione di casi di test in modo schiacciante. Meno comunicazioni, richieste di accordo e collaborazione con le parti interessate su ciò che deve essere riconvalidato. Concorderanno anche sul fatto che non è passato molto tempo dall’ultima versione. Quindi viene data meno importanza a questa azione.
- La squadra si abituerà a questo ciclo; nel tempo, sarà una parte naturale della squadra.
- Come effetto collaterale, gli ambienti di sviluppo e test spesso aggiornano i dati. Ciò è comunque necessario per ogni nuovo ciclo di test. Quindi non sarà solo un’altra attività programmata da fare. Piuttosto, un’azione che fa già parte del processo stabilito. Questo cambio di prospettiva ha tanta influenza sull’atmosfera della squadra. Non ci si crederebbe.
Conclusione
Questo capitolo conclude i miei post precedenti sull’argomento del ciclo di vita di Scrum. Inoltre, riguarda ciò che ha dimostrato di funzionare nella vita reale.
Spesso i team iniziano in modo agile e fanno molte cose in modo sbagliato. Poi si evolvono, alla fine, e iniziano a fare le cose in modo diverso. Questa serie potrebbe aiutare alcuni di loro a fare questo cambiamento più velocemente.
Né questo approccio di rilascio è l’unico praticabile, né è privo di problemi. Quelli esisteranno ancora e le squadre dovranno affrontarli. Quindi migliora ciò che è possibile e dimentica ciò che non ha senso.
Ma da quello che so, questo approccio, sebbene semplice, ha dimostrato che il cambiamento è possibile. Da sprint caotici e imprevedibili a consegne più stabili con rilasci regolari su cui fare affidamento e con cui pianificare. E non richiede una metodologia speciale e molto complicata, solo semplici regole e la volontà di seguire il piano.