Ultimo aggiornamento: 2 febbraio 2018
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.
"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.
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.
Per risolvere la situazione, il nuovo team di gestione versioni si è attenuto ai seguenti puntatori di correzione in corsa, elencati di seguito:
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:
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!
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.
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:
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).
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.
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.
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.
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.
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.
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.
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.
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.
Le seguenti metriche di gestione delle versioni sono state misurate in maniera continua per ottimizzare il processo di gestione delle versioni.
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.
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.
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
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).