In ambito enterprise, dove più team possono afferire a più progetti, viene a crearsi una rete di Increment da integrare e validare prima di poter procedere alle attività di delivery.

In questo contesto risulta estremamente evidente come adottare un’opportuna strategia di Release Management sia fondamentale per poter gestire con successo i nuovi rilasci, garantendo la disponibilità del sistema e la possibilità di ripristino in caso di problemi bloccanti.

DA2 suggerisce un approccio basto su due differenti insieme di strategie: uno relativo allo scheduling e uno alle azioni di management annesse.

Per quanto riguarda lo scheduling, si incontrano le seguenti opzioni:

• Slow Cadence Release Windows, si tratta della strategia più datata in cui viene individuata una finestra temporale che consente ai diversi team di effettuare il deploy. Il problema odierno, richiedendo costantemente una disponibilità 24/7 dei servizi, è quello di individuare una finestra temporale opportuna, evitando che gli slot di attività disponibili si saturino prima di aver completato il tutto, fattore che rappresenta un vero e proprio collo di bottiglia per i progetti legati a team multipli. A ciò si aggiunge il fatto che la distanza tra una finestra e la successiva è importante (slow cadence) per cui bisogna attendere molto per poter mettere in produzione le novità. Questi motivi spingono caldamente a sconsigliare questa strategia, anche se possono esistere contesti dove resta necessario impiegarla;
• Release Train, questa strategia abbraccia la metafora del treno. Il treno rappresenta l’attività di sviluppo nel complesso, mentre le stazioni sono i momenti di rilascio programmato in cui ogni team può effettuare il dispiegamento di quanto realizzato. In sostanza, ogni volta che si raggiunge la stazione (data) di rilascio, tutti i team pronti possono farlo, mentre chi perde la fermata dovrà attendere la successiva. Questo approccio nella pratica risulta decisamente efficace, soprattutto per sincronizzare il rilascio contemporaneo di funzionalità o componenti dipendenti da loro. Uno dei punti più delicati è che, nel caso di rilasci cross-team aggregati per necessità, il team più lento diventa il collo di bottiglia che “sceglie” la stazione di rilascio. Resta, inoltre, il problema di non poter supportare adeguatamente politiche di continuous delivery;
• Quick Candence Release Windows, è un primo approccio alla riduzione degli intervalli di release in ottica di continuous delivery, mitigando i problemi della slow cadence e di release train;
• Continuous release availability, non esisto le finestre temporali: semplicemente il team rilascia quando è pronto. Per raggiungere questo obiettivo è fondamentale adottare un approccio DevOps, automatizzando gli aspetti di continuous integration e delivery.

Le azioni di management sono invece caratterizzabili dalle seguenti strategie:

• Integrated deployment planning, è fondamentale condividere il planning di rilascio tra tutti gli attori interessati, abbattendo i diversi silos, in particolare quelli tra Dev e Ops. In questo aspetto gli Ops sono più abituati a dover condividere le azioni con i Dev, mentre quest’ultimi tipicamente considerano il loro lavoro terminato una volta effettuata la build (se non prima!);
• Standard development and testing environments based on production, una efficace azione di delivery passa necessariamente attraverso la standardizzazione e la congruenza degli ambienti di test, pre-prod e produzione. Questo richiede un giusto mix di bilanciamento tra le necessità dei differenti team di Dev ed Ops, ma garantisce ottimi risultanti in funzione della robustezza dei processi di delivery;
• Release service streams, diversi team tipicamente hanno diverse necessità e competenze in relazione alle attività, sia di produzione che di rilascio. Questo implica che un opportuno approccio alla delivery deve tener conto di diverse esigenze, creando stream diversi (ma limitati) per poter supportare i diversi team: da quello che ha necessità di essere assistito dai release manager engineers a quello completamente automatizzato;
• Release blackout periods, in chiave opposta a quanto visto in precedenze, può essere necessario per alcune realtà identificare i diversi intervalli dove non è assolutamente possibile procedere a nuovi delivery. È il caso, ad esempio, di momenti particolarmente critici come la chiusura dell’anno fiscale;
• Shared release practices, si tratta di un caposaldo della comunicazione tra tutti coloro che sono coinvolti nel processo, atto a condividere i successi e gli insuccessi per migliorare l’azione complessiva.

È interessante evidenziare che per raggiungere un efficace azione di Continuous Delivery, il software deve avere un’architettura adeguata da poter consentire il deploy di singole funzionalità che inglobano tutti i differenti layer logici. Un esempio molto efficace sono i microservices.

In generale le aziende sono progressivamente passate dalla Slow Cadence alla Fast Cadence, supportate dall’adozione delle metodologie Agile che, a loro volta, con i framework di scaling (OpenUP e SAFe in primis) hanno reso popolari l’approccio release train fino alla nuova frontiera del continuous delivery e deployment.

Stary Tuned