Le 5 fasi dell'evoluzione DevOps per una strategia di Successo

Come si sta sviluppando il DevOps Journey su scala mondiale e come le varie organizzazioni chiamate in causa stanno evolvendosi quotidianamente in questo senso? 

In questo articolo abbiamo deciso di analizzare, con l’aiuto di quanto esposto nel report State of DevOps 2018 redatto da Puppet e Splunk, quali sono le fasi principali del DevOps Journey che consentono di impostare una strategia di successo.  

Di seguito qualche grafico che dà un’idea della distribuzione geografica e per settore dei partecipanti al sondaggio che ha reso possibile la redazione dello State of DevOps report e dell’analisi in oggetto: 

Prima di partire con la descrizione dei principali step identificati per il DevOps journey, è doveroso menzionare 2 premesse che lo State of DevOps report ha ricavato dall’analisi dei dati, e che noi in qualità di abilitatore tecnologico in ambito Digital Transformation non possiamo che confermare: 

• Ogni DevOps Journey è unico e può essere composto da fasi anche molto diverse per contenuto, importanza, e tempistiche di realizzazione; 

• una strategia DevOps di successo dovrebbe partire da un singolo team, possibilmente quello dove si stanno riscontrando maggiori problemi o difficoltà di gestione e, una volta sistemato questo, espandere le pratiche ai team multipli meno critici, poi ai dipartimenti e infine ai dipartimenti multipli. L’ideale sarebbe quello di iniziare proprio dalle fasi più prossime alla produzione, quelle appunto più delicate, per poi adattare il processo collaudato agli stadi precedenti che costituiscono l’intero ciclo di vita del software. 

Andiamo ora a vedere come, attraverso l’analisi delle pratiche DevOps utilizzate dalle aziende, possano essere identificate delle fasi ben definite di adozione di tale metodologia. L’adozione delle pratiche contribuisce al successo di specifiche fasi, impattando sul successo  delle stesse e quindi sull’evoluzione del DevOps in azienda. 

Nello specifico, possiamo identificare le pratiche fondamentali che costituiscono le 5 fasi principali dell’evoluzione DevOps. Per ogni fase, appunto, sono state definite: 

• Defining Practices: ovvero le due pratiche principali presenti in ogni fase; 
• Contributors to success: le pratiche che contribuiscono maggiormente al successo della propria fase; 
• Foundational Practices: quelle pratiche che impattano maggiormente lungo il percorso evolutivo della metodologia DevOps. 

 Una volta descritte le 5 fasi dell’evoluzione DevOps, andremo a definire le suddette pratiche nello specifico per ognuna delle fasi. 

Le 5 fasi dell'evoluzione DevOps

0. Creazione delle basi: 

comprensione da parte dei team Dev & Ops della cultura della condivisione e della collaborazione. Questo è un punto di partenza fondamentale per la salute di un'organizzazione DevOps di successo. 

1. Normalizzare lo stack tecnologico

In questa fase notiamo come i team di sviluppo stanno intraprendendo azioni coordinate al fine di rendere più agili i processi di sviluppo, oppure come altri team stanno lentamente iniziando ad adottare queste nuove metodologie in maniera organica per specifici prodotti e flussi di lavoro.  

I team di sviluppo adottano una versione di controllo, che rappresenta il primo passo verso la Continuous Integration e Continuous Delivery. Stanno quindi iniziando a normalizzare il loro parco tecnologico eliminando le ridondanze, magari industrializzando le loro applicazioni per poter lavorare su un pacchetto di sistemi operativi più piccolo. 

2. Standardizzare e ridurre le variabili 

In questa fase sia gli sviluppatori (DEV) che i sistemisti (OPS) sono concentrati nella riduzione di variabili, continuando l’operazione di standardizzazione dello stack tecnologico grazie alla riduzione del numero di sistemi operativi, che prevede la creazione di un unico OS (operating system) o una famiglia di OS, andando a definire in maniera sempre più chiara quello che sarà lo standard tecnologico. Normalmente si nota come questo consolidamento avvenga in maniera indipendente all’interno di ogni singolo team, senza quindi dover ricorrere a quella che viene definita “cross-team collaboration”, dando vita ad una nuova forma di collaborazione più veloce e sistemica. Ad esempio: se gli sviluppatori desiderano standardizzare un database, potranno agilmente consultare i loro colleghi sistemisti per un’opinione veloce e puntuale, riducendo quindi le complessità e permettendo ai vari team di poter scalare la loro esperienza e conoscenza in modo continuo. Così facendo si potranno sviluppare nuovi prodotti e servizi in maniera più veloce, riducendo al minimo il numero dei possibili errori. Ancora meglio, più questa condivisione di conoscenze aumenta, migliore sarà la qualità del servizio o del prodotto sviluppato. 

3. Estendere le pratiche DevOps 

Ora che gli elementi fondamentali sono impostati e il sistema è stato ben compreso, le organizzazioni possono dedicarsi alle altre fasi. Normalmente, il processo di sviluppo è quello più critico e quello dove si concentra maggiormente l’attenzione del management, soprattutto nel momento in cui i rilasci avvengono tardi, o errori gravi arrivano in produzioni, magari evidenziati dal cliente stesso. I cambiamenti implementati nelle precedenti due fasi hanno fatto sì che le modalità e la velocità di lavoro del team di sviluppo abbiano sorpassato quelle del team di deployment. Questa discrepanza deve essere risolta rapidamente, altrimenti il duro lavoro di semplificazione e standardizzazione avvenuto nelle precedenti fasi, risulterà essere un ostacolo anzichè un aiuto. Per evitare questo, i team utilizzano i modelli di deployment durante la fase di sviluppo, in modo che le modifiche apportate all’infrastruttura, al servizio o al prodotto vengano testate prima di andare in produzione. Tali pratiche forniscono alta affidabilità al processo e fiducia nei confronti di questo nuovo modello, introducendo un vero e proprio cambiamento culturale all’interno dell’organizzazione. Ad esempio, i singoli membri dei team non dovranno più lavorare dipendendo dalle approvazioni manuali dei membri di altri team, eliminando quindi tutta la burocrazia e i relativi rallentamenti. 

4. Automatizzare l’infrastruttura di rilascio 

Questa fase del DevOps Journey è definita dall’automazione dei sistemi di configurazione e approvvigionamento, considerate come massima priorità della metodologia DevOps dalla maggior parte dei partecipanti al questionario. Automatizzare l’infrastruttura di rilascio risolve la discrepanza evidenziata nel punto precedente, adattando i nuovi processi anche alla fase di deployment. La configurazione di un sistema automatizzato aiuta il team dei sistemisti (OPS) a rilasciare nuovi sistemi più velocemente e più in linea con le necessità dell’ambiente di produzione. Anche l’automazione dell’infrastruttura, quindi, risulta essere un’operazione sempre più cara ai sistemisti IT, stando ai risultati del questionario: si tratta di creare un flusso di lavoro automatico, suddiviso in sequenze, adattabile ed estendibile all’intera organizzazione, portando una dose notevole di soddisfazione interna che si ripercuote sulla qualità del prodotto o servizio rilasciato.  

5. Fornitura di competenze fai da te 

Con il tempo, dedizione e costanza, l’azienda arriverà a quest’ultima fase dove saranno più evidenti i benefici ottenuti dall’implementazione delle procedure altamente automatizzate descritte nelle precedenti fasi. A questo punto le risorse saranno in grado di lavorare autonomamente senza dipendere dai feedback e dalle approvazioni manuali degli altri collaboratori e anche le correzioni di eventuali errori saranno immediate e automatiche. I team IT non decidono di automatizzare i processi solo per il gusto di farlo, bensì con lo scopo di rendere l’intera organizzazione rapida e efficiente senza sprechi di tempo, energie e risorse. Se si arriva a questo risultato, a beneficiarne saranno tutti: i lavoratori, l’azienda e il cliente stesso. 

Le "Foundational Practices" individuate per ogni fase

Conclusioni

Quello che questo sondaggio ci ha insegnato, è che la trasformazione DevOps è una condizione fondamentale per il raggiungimento di risultati concreti e veloci. Le organizzazioni hanno due alternative per poter implementare questa metodologia al loro interno: adottando un approccio di miglioramento continuo e sistematico, oppure un approccio più generico e casuale. È possibile che entrambe funzionino, ma ciò che vediamo tutti i giorni è che le aziende che hanno ottenuto maggiori benefici, non li hanno ottenuti in maniera fortuita, bensì strutturandosi in modo puntuale e organizzato.  

Arrivare a questo non è certo facile, né immediato, ma con l’aiuto di un partner valido e di esperienza, i primi benefici non tarderanno ad arrivare e renderanno sempre più evidente la necessità di estendere la metodologia DevOps all’intera organizzazione aziendale. 

Se desideri conoscere il tuo livello di maturità DevOps, compila il nostro Self-Assessment GRATUITO:

Fonti: https://www.thinkahead.com/wp-content/uploads/2018/10/State-of-DevOps-Report.pdf