ITIL, Italia

La definizione "ufficiale" di Release Management in ITIL e' la seguente: 

• considerare in modo 'olistico' i cambiamenti ai servizi IT (to take an holistic view of a change to an IT service) ed assicurarsi che tutti gli aspetti di una release, tecnici e non, vengano considerati

Il release Management andrebbe utilizzato per:

• Implementazioni hardware massiccie o critiche
• Implementazioni software significative
• Implementazione contestuale di set di cambiamenti correlati

Le responsabilita' del processo di Release Management includono le seguenti:

• Pianificazione e coordinamento delle implementazioni di software nuovi (o di upgrade) con hardware e documentazione associati
• Coordinamento con il Change Management per validare l'esatto contenuto della release
• Assicurarsi che tutti gli item oggetto (o target) di implementazione siano tracciabili via CMDB
• Gestione delle aspettative dei clienti ed utenti nelle implementazioni

I seguenti concetti canno considerati con il Release Management:

• La Definitive Software Library (DSL), che contiene tutti le copie master di tutti i software in produzione, utilizzata e/o aggiornata con ogni release.
• Il Definitive Hardware Store (DHS), e' un area dove vengono mantenute i ricambi per l'hardware. Le parti nel DHS devono essere tracciate nel CMDB e mantenute allo stesso livello dell hardware in produzione
• Build Management, Il software e/o hardware che fa parte della release deve essere assemblato in modo controllato in modo che sia ripetibile e documentato
• Testing e Back-out, un piano di testing ed un piano di back-out (anch'esso va testato) fanno parte del corredo necessario ad ogni release prima che venga autorizzata

I benefici dell'implementare il Release Management includono i seguenti:

• Migliore qualita' dei servizi rilasciati come risultato di un maggiore percentuale di release finalizzate con successo
• Migliore utilizzazione delle risorse
• Certezza che l'hardware ed il software rilasciato in produzione siu di qualita' nota, riducendo in tal modo le possibilita' che software illegale, errato o non autorizzato sia in uso.

Una delle poche raccomandazioni di ITIL in termini di priorita' di implementazione dei processi e' quello di implementare i processi di configuration, change e release management insieme, e possibilimente di avere una funzione centralizzata per gestirli.

Uno degli aspetti da documentare all'inizio dell'implementazione del processo e' la divisione dei compiti tra lo staff di sviluppo e quello  di supporto alle operazioni (operations). Il Release management coinvolge entrambe le parti:

• Lo staff di sviluppo e' normalmente responsabile per il design, sviluppo e costruzione (build) della soluzione, nonche' del testing. Il gruppo di sviluppo dovrebbe anche collaborare durante la messa in opera.
• Lo staff di operations e' normalmente responsabile per il processo, per la messa in opera e per il supporto.

Naturalmente le responsabilita' possono variare in base a necessita' specifiche, ma e' necessario che siano note e documentate.

Per poter implementare un processo di Release Management valido e' necessario avere la possibilita' di disporre di piu' ambienti (normalmente sviluppo, test e pre-produzione) in modo da poter fare il build e testing della soluzione in modo consistente a come verra' fatto in produzione. Non sempre questi ambienti sono disponibile, e questo puo' vanificare alcuni dei benefici del Release Management.

Un altro problema comune e' la manacanza di comprensione della Release. Quante volte vi e' capitato che il gruppo di sviluppo vi abbia dato il sistema, i sistemisti vi abbiano dato l'hardware: arrivederci e grazie. E adesso? Normalmente i vari gruppi dovrebbero essere tenuti sia a documentare tutta la release sia a fornire supporto durante la messa in opera. Se ricordate la definizione di Release Management c'era la parolina "holistic", che vuol dire che la release va vista nell'insieme e non solo nelle parti.

Un ulteriore comune ostacolo e' il seguente: il processo viene percepito come troppo burocratico e viene regolarmente bypassato. Com'era bello quando chiunque con una brillante idea era in grado di metterla in produzione senza fastidi (e la documentazione? e il supporto? e il testing ? sciocchezze, banalita' burocratiche...). A questo scopo e' fondamentale che tutti capiscono l'importanza ed i benefici del Release Management.

Un altro problema comune potrebbe essere lo scarso interesse del management all'implementazione del processo.  Questo puo' essere risolto facendo in modo che i manager vengano informati dei benefici nell'implementare il Release Management con "awareness campaigns" ed iniziative simili.