Home » Best practice di gestione versioni ITIL

Ultimo aggiornamento: 2 febbraio 2018

La gestione e la distribuzione delle versioni semplificate
grazie a 11 best practice ITIL

Le best practice di gestione versioni ITIL qui spiegate si basano sul caso d'uso di un operatore telefonico di medie dimensioni. La società aveva diversi problemi che incidevano sui costi dei loro clienti per il 25% e che causavano una caduta di produttività. La ragione principale era la mancanza di un processo e di procedure efficienti per la gestione delle versioni. Scopri come la società ha ridotto gli errori di versioni e ha aumentato la velocità delle versioni in tre mesi.

Cos'è la gestione delle versioni?

"La gestione delle versioni è il processo di gestione, pianificazione, programmazione e controllo di una build software attraverso diverse fasi e ambienti" - Wikipedia

"La gestione delle versioni consiste in creazione, test e distribuzione mentre l'erogazione continua consiste in creazione, test e distribuzione utilizzando l'automazione." - Charles Betz, Research analyst Forrester

"Secondo me, un software di test è l'elemento di automazione imprescindibile." -Jayne Groll CEO DevOps Institute

Panoramica

Un operatore di telecomunicazioni di medie dimensioni ha perso il 25% circa dei propri clienti in un periodo di tre mesi a causa del ritardo di versioni multiple di software critico. Chiaramente, il processo di gestione delle versioni precedente non era efficace e la società ha dovuto risolvere il problema e giungere a un processo concreto per rimettere tutto a posto.

La società ha formato un nuovo team di gestione delle versioni per valutare e ottimizzare il flusso del processo di gestione versioni esistente. Nei tre mesi successivi, il nuovo team è stato in grado di rilasciare entrambe le versioni in sospeso e due versioni pianificate di applicazioni re-ingegnerizzate. Di seguito è spiegato in che modo il team ha ottimizzato il processo di gestione delle versioni ITIL. I passaggi intrapresi dal team erano improntati su best practice che si possono adottare in qualsiasi organizzazione IT.

1. Valutazione dei processi di gestione delle versioni esistenti

Il nuovo team voleva un quadro dettagliato del flusso del processo di gestione delle versioni corrente. Hanno iniziato con una serie di sessioni conoscitive con persone chiave coinvolte nel processo del software. In queste sessioni, il team ha appreso che un software CRM era stata in sospeso da due mesi dopo il completamento.

In base ai requisiti del cliente, il software CRM includeva la predisposizione dei reclami. Includeva anche crediti e penalizzazioni dei servizi per i clienti dell'operatore che lamentavano problemi di inattività, degrado del servizio e trasferimento di un nuovo piano di fatturazione. Il ritardo nel rollout del software CRM significava che diversi clienti non avevano ottenuto in tempo i crediti dei propri servizi o i rimborsi, e che non vi era alcun sistema di tracciamento per le richieste dello stato dell'aggiornamento. Il 25 percento circa dei clienti al dettaglio persero la pazienza e cambiarono operatore.

Nel processo esistente, i processi di contatto, convalida e verifica esistenti non erano ottimizzati a causa di approvvigionamento hardware, ambiente di test e assenza di un ciclo di versione concordato.

itil release management process flow

2. Consolidamento delle valutazioni della gestione versioni esistente

  • I cicli di rilascio erano casuali, piuttosto che dettati da una frequenza e una finestra di rilascio strutturate e concordate.
  • Gli ambienti di test erano datati e non disponibili su richiesta.
  • In molti casi, i testi di regressione impiegavano oltre tre mesi ed erano suddivisi in molte distribuzioni.
  • Erano assenti processi di controllo delle modifiche integrati, con una gestione delle configurazioni e delle versioni.
  • Il morale generale dei team era basso a causa del gran numero di versioni fallite o ritardate.

3.Ottimizzazione dei nuovi sistemi di gestione delle versioni

Per risolvere la situazione, il nuovo team di gestione versioni si è attenuto ai seguenti puntatori di correzione in corsa, elencati di seguito:

  • Determinare e stabilire cicli di rilascio approvati.
  • Semplificare il processo e i test anticipati.
  • Infrastruttura controllata tramite un sistema di gestione delle configurazioni (CMS, Controlled Management System).
  • Semplificare il processo di controllo delle modifiche e l'automazione.
  • Creazione del "triangolo magico" (processo integrato di configurazione, modifica, rilascio e distribuzione).
  • Tenere conto delle misurazioni e delle metriche dell'account.
  • Workshop di formazione e consapevolezza.

4. Determinazione del ciclo di vita della gestione delle versioni

Una volta che il team ebbe ottenuto il quadro generale del processo di gestione delle versioni, decise di concentrarsi sulla definizione e l'implementazione di un ciclo di rilasci concordato. Per conoscere la frequenza di rilascio in produzione, il team doveva comprendere la frequenza dei test non funzionali. Dopo una discussione con il gruppo degli ingegneri, il team ha concluso che il progetto richiedeva test di regressione, prestazioni e integrazione.

Il ciclo di rilasci fu sviluppato per conseguire i seguenti risultati:

  • Creare un'opportunità per discutere in maniera significativa tutti i test non funzionali che il software poteva richiedere.
  • Delineare una tabella di marcia per aggiornare la versione prevista di una funzione o caratteristica agli attori coinvolti.
  • Stabilire una routine a cui tutti i team potevano allinearsi (inclusi quelli del marketing e di ingegneria).
  • Garantire ai clienti che i loro ordini sarebbero stati di buona qualità ed erogati nei tempi concordati.

Il team di gestione delle versioni ha iniziato sperimentando un ciclo settimanale, la il piano si rivelò impraticabile. L'ambiente di database del cliente non poteva essere aggiornato in tempi brevi. Il team quindi provò con cicli di due settimane. Non vi furono obiezioni immediate dai partecipanti, ma il ciclo di due settimane fallì le prime due volte. Una volta superati alcuni colli di bottiglia a ciclo chiuso nell'ambiente e dopo aver automatizzato alcuni dei test, il team decise che il ciclo di due settimane era la scelta raggiungibile.

Infine il team stabilità un ciclo con il quale, ogni sue settimane, il codice pronto per la produzione dal team di ingegneri fosse direzionato ai test del sistema. Due settimane dopo hanno rilasciato quel codice alla produzione.

Il ciclo di rilascio non era definito in funzione di quando il cliente voleva la versione. Era stabilito in base a quanto il team poteva rilasciarlo sul mercato con il livello di qualità desiderato. Tuttavia, quando il team si confrontò con i clienti e con i responsabili delle decisioni, questi iniziarono a supportarlo!

5. Semplificazione per snellire i processi e velocizzare le versioni

Processi snelli non richiedono lunghe approvazioni burocratiche o interminabili riunioni per giungere a un accordo. Di solito richiedono solo un livello minimo accettabile di input e output. Quello che manca in termini di burocrazia rappresenta un netto guadagno in termini di risposta ai cambiamenti e di adozione popolare.

Alla base di questo approccio c'era tuttavia una spinosa questione di documentazione. Il team doveva registrare ciò che veniva fatto e come veniva fatto, altrimenti sarebbe stato impossibile riesaminare o migliorare la situazione.

6. Documentazione e strumenti nella gestione delle versioni

La società decise di andare nella direzione di una documentazione standard che avrebbe consentito alle persone (tecnici o altri) di leggere e agire sui documenti invece di lasciare che questi morissero negli scaffali.

Il team di ingegneri ha scelto Confluence, uno strumento commerciale per documentare collaborativamente il proprio lavoro. Hanno utilizzato il software per creare documentazione minima ma efficace di ciò che concordavano di implementare in ogni ciclo di lavoro. Registravano ciò che creavano, come lo creavano e cosa era necessario per farlo funzionare. Il nuovo team vedeva il valore di questo approccio e lo allargarono (approccio e strumento) a tutti gli attori coinvolti nel processo.

Fu quindi creata una sequenza di attività per il rilascio del software dai team di ingegneri. L'elenco di attività includeva:

  • Garantire la consegna, direttamente dal sistema di gestione controllo delle origini.
  • Specificare la nomenclatura e definire come ogni elemento (codice eseguibile, script di database e così via) dev'essere eseguito e su quali piattaforme.
  • Fu effettuato un test controllato utilizzando codice fittizio per ogni elemento. La sequenza è stata testata gestendo in parallelo la creazione dei documenti che illustravano cosa il team aveva fatto e come lo aveva fatto. In questo modo venne formata la base delle istruzioni di installazione.
  • Il passo successivo è stato quello di consentire alle persone che avrebbero distribuito la versione reale di realizzare un altro test controllato, utilizzando solo la documentazione creata dal team.
  • Le persone coinvolte estesero, corressero e migliorarono le istruzioni del team. Il processo divenne più inclusivo e tutti contribuirono alla documentazione. Proprio in base a come era stato definito, il processo venne adottato in modo più ampio e con una migliore qualità.
  • Dopo ogni rilascio, il team rivedeva il processo, esaminava la documentazione e identificava le modifiche apportate durante il rilascio. Si definita inoltre come la documentazione poteva essere migliorata e si riportavano nel processo i miglioramenti.

7. Implementare un'infrastruttura controllata utilizzando CMS (gestione di configurazioni, modifiche e versioni)

Scopo

Un'infrastruttura di gestione delle versioni assicura che tutto sia a posto per procedere con la distribuzione e l'uso del software. Il team di gestione delle versioni impiegava tempo a sviluppare un sistema di gestione delle configurazioni (CMS) e iniziò a creare la struttura ad albero e la gerarchia delle voci di configurazione (CI).

buildingconfiguration item (CI) hierarchy relationships

Valutazione del processo di gestione della configurazione

Assessment of the configuration management process

Workshop su individuazione e strumenti

Il team ha condotto workshop con i team di infrastruttura, sviluppo di applicazioni e gestione per decidere sui processi di configurazione, modifica e rilascio. Di seguito è illustrato il flusso concettuale concordato, dalla prospettiva dello strumento.

configuration, change and release processes flow

8. Creazione di un'infrastruttura di gestione delle versioni
(Semplificazione del processo di controllo delle modifiche e dell'automazione)

L'infrastruttura delle versioni copriva hardware, storage, connessioni di rete, larghezza di banda, licenze software, profili utente e autorizzazioni di accesso. I servizi e le competenze umane facevano parte dell'infrastruttura di gestione delle versioni. Se ad esempio un software specialistico doveva essere installato e configurato, non si potevano escludere la disponibilità o il costo di includere tali competenze nel piano dell'infrastruttura.

È essenziale individuare eventuali colli di bottiglia nascosti nell'approvvigionamento dell'hardware richiesto o delle competenze mancanti (ad esempio per la configurazione di reti sicure). Il team ha dovuto risolvere questi problemi prima della consegna.

Tuttavia, tale standard non è stato facile da mantenere. Il team si è sforzato di mettere in atto l'infrastruttura di gestione delle versioni al più presto dopo l'inizio del progetto. Anche dopo sei settimane dall'inizio stavano ancora aspettando memoria e dischi rigidi specializzati per i server di test.

Identificazione delle attività di automazione

Il team identificò le attività di compilazione e test come attività automatizzabili e definì i criteri e le definizioni per le modifiche normali, standard e di emergenza. L'automazione consentì loro di eseguire attività ripetitive senza dover occupare preziose risorse umane. Delinearono inoltre una serie di modifiche standard in funzione di rischio, ripetibilità e tempo coinvolti nell'esecuzione.

Le modifiche sono state raggruppate per allinearsi al ciclo di rilascio di due settimane. I team delle modifiche lavorarono con i team di rilascio e sviluppo per sincronizzarsi con il calendario dei rilasci, i tipi di rilascio e il supporto del ciclo di vita iniziale.

Pacchetti manuali e automatizzati

Prima di essere inclusi nel progetto, i team di ingegneri realizzavano manualmente i pacchetti distribuibili. Per questo motivo non vi era certezza che un nuovo pacchetto fosse come quello precedente. Di fatto potevano esserci anche dubbi sul fatto che si trattasse effettivamente del software che stavano realizzando e che funzionasse. Spesso erano necessari giorni allo staff tecnico per creare un pacchetto con le funzionalità, in una struttura che potesse essere distribuita.

Accettazione del servizio e verifica

Il team di gestione delle versioni redigeva immediatamente una struttura e i criteri di accettazione dei servizi per il pacchetto distribuibile che il team di ingegneri aveva inviato e li aiutava a standardizzare il pacchetto. Questo comportò l'implementazione di processi automatizzati per compilare il software in questa struttura coerente con tutti gli altri punti di rilascio.

Dato che il team aveva automatizzato il processo di verifica dei criteri di accettazione, l'esecuzione era garantita. Ad esempio, dev'essere eseguito uno unit test del software prima dell'invio e un test della distribuzione per garantire il risultato finale. Grazie a queste misure, il team di gestione delle versioni poteva creare il pacchetto, definire la versione, testare e distribuire il codice finale con un singolo comando, in pochissimo tempo.

La nuova norma dei cicli di rilascio

Il ciclo di rilasci appena stabilito prevedeva i test di regressione, prestazioni e integrazione in sole due settimane, affinché il team fosse in grado di rilasciarlo in produzione. Il team poteva effettuare diversi tipi di test (integrazione e prestazioni) avendo ambienti separati per ogni tipo. Tuttavia, la sfida di completare due mesi di test di regressione in una finestra di sue settimane sembrava impossibile da vincere. Ecco come fecero.

  • Per prima cosa, il team avviò un esercizio di prioritizzazione. Il cliente aveva identificato i test di regressione di massima priorità come soglia minima accettabile come prova dell'esistenza delle vecchie funzionalità.
  • Il team quindi iniziò l'automatizzazione di questi test. Anche i test di accettazione successivi furono automatizzati per garantire che team potesse effettuare il test di regressione per ogni versione in termini di ore e non di giorni.

9. Creazione del "triangolo magico"
(processi integrati di configurazione, modifica, rilascio e distribuzione)

Mentre la combinazione di gestione della configurazione, processo di controllo delle modifiche e processi di gestione di rilasci e distribuzione sono stati integrati senza soluzione di continuità, l'intero processo ha richiesto un vertice delle persone per poter essere realizzato.

ITILconfiguration, change, release management

Ruoli e responsabilità del team di gestione delle versioni

Il team di gestione delle versioni sosteneva l'importanza di questa fase stabilendo che il responsabile dei rilasci designato si sarebbe aspettato che il software fosse pronto nel momento in cui i team erano convenuti. Il team fece in modo che il responsabile del programma (in questo caso il cliente finale) potesse spiegare ai team i motivi dell'importanza delle versioni.

Il team chiese che i team di ingegneri garantissero che il software rilasciato fosse conforme a uno standard (in termini di versione, test, documenti e pacchetti). Il team stabilì anche che avrebbe richiesto questo pacchetto standard a ogni ciclo di rilascio. Ciò rese il processo automatizzato più semplice e coerente e consentì l'integrazione del feedback.

10. 9 metriche chiave della gestione delle versioni

Le seguenti metriche di gestione delle versioni sono state misurate in maniera continua per ottimizzare il processo di gestione delle versioni.

  • Numero di modifiche in sospeso per le versioni di sistema future (backlog).
  • Numero di modifiche riuscite in una versione.
  • Numero di modifiche non riuscite in una versione (percentuale di modifiche fallite).
  • Numero di interruzioni di attività causate da una versione.
  • Numero di incidenti causati dalla versione.
  • Percentuale di versioni erogate in tempo per i test di QA.
  • Percentuale di versioni inviate in tempo per la produzione.
  • Percentuale di versioni per priorità o tipo.
  • Tempo di inattività totale della versione, in ore.

Istantanea delle metriche catturate, agosto 2014 <ETH> Feb 2015

release management kpi

È nell'investire nelle persone che risiede il potere

Durante il corso dell'intera trasformazione, la risorsa più importante sono state le persone. Il team di gestione delle versioni prendeva le proprie prospettive, i problemi e le sfide in maniera onesta e trasparente, e informata i responsabili. Elencarono anche alcuni dei primi soggetti per l'adozione in qualità di agenti del cambiamento. Hanno investito molto in formazione, consapevolezza e comunicazione, istituendo un meccanismo di premiazione per riconoscere i comportamenti positivi e la condivisione delle conoscenze.

11. Workshop di formazione e consapevolezza per i team di gestione di modifiche, configurazioni e versioni

Sono stati condotti i seguenti workshop per i team di gestione di configurazioni, modifiche e versioni, senza eccezioni. Anche i responsabili di linea erano disponibili a convalidare l'efficacia dei workshop.

  • Workshop sugli elementi basilari della gestione delle versioni (un giorno).
  • Workshop sugli elementi fondanti di DevOps (due giorni).
  • Workshop su metriche e misurazione (un giorno).
  • Workshop sulle azioni di rilascio e distribuzione, inclusi ruoli, responsabilità, tempistiche e componenti consegnati (un giorno).

Il risultato del workshop di cinque giorni fu una maggiore chiarezza dei team coinvolti sui vari temi toccati, sui componenti consegnati e sull'impatto complessivo sull'azienda. Fu distribuito un breve documento per riepilogare i punti di conoscenza chiave della formazione.

 

Lezioni apprese

 

  • La gestione delle modifiche organizzative era fondamentale per far sì che tutti i team lavorassero su una visione e su obiettivi condivisi che avrebbero portato a un risultato definito per l'azienda.
  • La decisione della velocità dei rilasci doveva basarsi sul prodotto o sull'applicazione, in misura anche maggiore rispetto all'urgenza e alle esigenze del cliente finale.
  • Criteri realistici del ciclo di rilascio, in accordo con gli attori coinvolti.
  • L'integrazione di processo e strumenti (incluse le esigenze dell'utente finale) si allineava con i processi di gestione di configurazioni, modifiche, versioni e distribuzione.

Considerazioni finali

In base all'esperienza del team di gestione delle versioni maturata nel lavorare insieme ad altri attori sul progetto, fu realizzata una gestione delle versioni di buona qualità che richiese un duro lavoro, la risoluzione ottimale dei problemi e una comunicazione perfetta. Tuttavia, la più grande abilità è la capacità di esaminare, apprendere e adattare i miglioramenti con un'efficace collaborazione delle persone in congiunzione con il "triangolo magico" (processi di gestione di configurazioni, modifiche, rilasci e distribuzione).

Scelto dalle migliori organizzazioni al mondo

Offriamo assistenza più rapida, più velocemente e insieme