ITIL, Italia

La definizione "ufficiale" di Release Management in ITIL v2 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.

Nel ricavare le metriche e' sempre opportuno chiarire gli obiettivi (Fattori critici di successo) della misura. Per il processo in oggetto si possono considerare i seguenti:

• Manutenzione di record accurati relativi a tutte le versione dei software presenti nella Definitive Software Library (DSL)
• Controllare le release messe in produzione al fine di minimizzare gli incidenti correlati
• Ottimizzare la gestione del processo di release

Alcuni esempi di metriche che possono essere utili per misurare le performance del processi di Release Management sono le seguenti (organizzate per Fattore Critico di Successo di cui offrono una misura):

Controllare le release messe in produzione al fine di minimizzare gli incidenti correlati

• Numero di incidenti generati dalla release, queste metrica misura direttamente i "danni collaterali" generati da una release. Questi dati possono essere calcolati a partire dalla lista degli incidenti.
• % di Release urgenti, questa metrica permette di misurare la percentuale di release urgenti (potenzialmente pericolose) rispetto alle altre. Se queste risultano eccessive vuol dire che il processo e' bypassato con la scusa dell'urgenza. Questi dati sono norlmalmente disponibili nei log delle release.
• Numero (oppure %) di release non testate, normalmente a causa di urgenze, misura molto simile a quella precedente, che si puo' usare qualora i dati fossero disponibili in alternativa a quelli necessari per la metrica precedente.

Manutenzione di record accurati relativi a tutte le versione dei software presenti nella Definitive Software Library (DSL)

• Numero pacchetti Software installati in produzione e non presenti nella DSL, misura della bonta' del processo di release in generale e della DSL in particolare. I dati sono normalmente disponibili a seguito di audit sui software installati in produzione.
• Numero di licenze non in uso, misura della bonta' del processo di gestione della DSL. Questa metrica si puo' tradurre in un beneficio immediato al byusiness nella possibilita' di risparimare soldi o utilizzare piu' efficientemente le risorse.

Ottimizzare la gestione del processo di release

• % di accuratezza delle stime dei tempi (e/o costi) di release, misura della bonta' della pianificazione e dell'efficienza del processo di release. Semplice da calcolare se si ha l'abitudine di effettuare (e tracciare i relativi dati) un minimo di pianificazione della release.
• % di Release effettuate nei tempi previsti, fornisce informazioni sostanzialmente simile a quelle della metrica preecedente.

Nel processo di Release applicativo esistono due prospettive opposte che e' opportuno valutare e misurare con metriche (alcuni esempi sono elencati di seguito) che sono leggermente diverse a secondo del punto di vista:

• la prospettiva del gruppo di operations (Application Support) con le metriche relativa:
  • Numero di difetti identificati
  • Numero di fix rimandati indietro a sviluppo
• la prospettiva del gruppo di sviluppo
  • Numero di difetti riscontrati durante lo sviluppo
  • Numero di difetti risolti
  • Numero di fix rifiutati da Application Support