DA2, Release Management

da2 release managementL’azione di Deployment è l’azione che mette la soluzione realizzata “nelle mani” del cliente, rappresentando il momento in cui il proprio lavoro di Delivery è realmente completato.

Non stupisce che il processo di Release Management (RM) è estremamente delicato e che diverse metodologie Operational-oriented (si pensi ad ITIL) lo contemplino direttamente, mettendolo al centro delle proprie azioni.

DA2 non è da meno, prevedendo un esplicito processo di RM che però è border-line rispetto all’approccio Disciplined DevOps.

da2 rm

Questa scelta diventa estremamente chiara se ci si ricollega alle strategie di adozione di DevOps all’interno della propria organizzazione, rispondendo anche all’implicita domanda: “ma a cosa serve un’azione di RM se faccio DevOps?”.

Come abbiamo già ampiamente discusso, la Cultura DevOps va costruita progressivamente e contestualizzata, richiedendo, tipicamente, strumenti che consentano di gestire il cambiamento senza incidere sugli SLA offerti ai propri clienti.

In particolare, un’azione di RM, affidata ad uno specifico team di riferimento, consente di supportare il deployment attraverso una serie di strategie specifiche in riferimento al contesto operativo:

  • Complex Operational Infrastructure. Quando la propria catena di deployment è particolarmente complessa e laboriosa (si pensi alla presenza di diversi stack tecnologici o a configurazioni d’ambiente particolarmente fantasiose), il rischio che qualcosa non vada a buon fine è estremamente alto, rendendo indispensabile una corretta programmazione delle fasi di release;
  • Many Delivery Teams working in parallel. Quando la soluzione è composta da più progetti, ognuno affidato a team diversi, ogni specifica azione di team-deployment va correlata agli artefatti complessivi, valutando gli impatti contingenti. Chiaramente, maggiore è il numero di team coinvolti, maggiore è il rischio che qualcosa possa andare male;
  • IT delivery teams needs help. Questa condizione si verifica spesso quando il team di delivery è poco esperto, o di nuova formazione, e necessita di essere supportato nella comprensione e nell’attuazione della catena di deployment. In questo caso l’RM team si comporta da Coach trasferendo know-how e collaborando per rivedere il processo anche in funzione delle specialità delle nuove risorse.

Se si esclude l’ultimo punto, legato più ad un fattore di crescita di team che al contesto operativo, gli altri due punti sussistono anche se l’IT adotta un approccio full DevOps. La Complessità può essere ridotta investendo nel “pagamento” del relativo Debito Tecnico, mentre la gestione Multi-team è difficilmente abbattibile se la soluzione è estremamente articolata e complessa.

In generale la funzione di Release Management in un contesto DevOps viene progressivamente assorbita dal team stesso, ma è estremamente utile avere un supervisor di coordinamento per le situazioni multi-team in modo da evitare spiacevoli problemi e frequenti condizioni indesiderate.


Stay tuned!

Comments are closed.