Cultura DevOps

Prima ancora che un insieme di pratiche e infrastrutture, DevOps rappresenta un approccio con una forte componente “culturale” in cui le persone hanno un ruolo cruciale. Senza questo tipo di cultura condivisa, l’introduzione di pratiche e infrastrutture non trova l’ecosistema in cui svilupparsi. Vediamo alcuni elementi di questo aspetto.

Innanzi tutto DevOps è un movimento culturale in cui l’intero processo è in mano alle persone. Una organizzazione può adottare i processi più efficienti o avere i migliori tool automatici, ma tutto ciò serve a poco se non ci sono le persone adatte ad eseguire i processi e utilizzare gli strumenti. La cosa sicuramente vale in generale, ma costruire la giusta cultura DevOps diventa il core di DevOps stesso.

Identificazione degli obiettivi di business

La prima attività necessaria è quella di creare una cultura orientata al DevOps. Per far ciò bisogna che tutti gli attori di un processo di sviluppo abbiano lo stesso obiettivo e che seguano la stessa direzione, mettendo a fuoco i requisiti di business in modo da permettere a tutti di vedere il quadro intero nel suo insieme.

La cultura DevOps è caratterizzata da un alto grado di collaborazione attraverso tutti i ruoli presenti in un’organizzazione. È per questo motivo che Lean e Agile si sposano perfettamente con la cultura DevOps.

Cosa vuol dire collaborazione?

Collaborazione implica anzitutto il rispetto reciproco, cosa apparentemente banale, ma che nei rapporti interpersonali spesso viene a mancare. Altra cosa importante è avere obiettivi condivisi e impegno nel portarli a segno. Trasparenza e visibilità incentivano ancora di più la collaborazione stessa.

Se vengono rispettati questi principi tra i gruppi che fanno parte di una organizzazione, i “classici” conflitti tra la componente innovativa (Dev) e quella di stabilità ed esercibilità del servizio/prodotto (Ops) verranno molto attenuati fino a scomparire.

Come prerequisito per una buona collaborazione è necessario avere dei team interfunzionali. Ogni team deve essere specializzato nel campo in cui opera ma avere anche esperti interfunzionali in modo che questi possano portare la loro esperienza all’interno del team e gli altri componenti possano avere le nozioni per interagire in maniera costruttiva con i componenti degli altri team.

Componenti architetturali

Diamo per accettate le cosiderazioni precedenti sulla cultura DevOps e passiamo in rassegna alcune tecniche che vengono adottate in tale ambito. Per far sì che in una organizzazione venga pienamente messo a frutto DevOps, infatti, ci si deve basare su tecniche ben precise:

• Continuous Improvement
• Release Planning
• Continuous Integration (CI)
• Continuous Delivery
• Continuous Testing
• Continuos Monitoring and Feedback

Vediamole di seguito nei dettagli.

Continuous Improvement

L’adozione di un processo non è una azione singola ma deve essere ripetuta nel tempo. Un’organizzazione deve avere un processo che identifichi le aree per eventuali miglioramenti mentre l’organizzazione stessa matura dal processo adottato.

Questo è un processo continuo e incrementale e abbraccia prodotti, servizi e processi stessi. Un’implementazione del Continuous Improvement è quella kaizen, concetto giapponese che è formato dalle parole kai (“cambiamento”) e zen (“buono”, “migliore”) vale a dire “miglioramento”.

Release Planning

Il Release Planning permette alle aziende di soddisfare i bisogni del business in modo da offrire nuove versioni e quindi nuove funzionalità ai clienti finali. Per questo motivo, il business esige un preciso piano di rilascio con un processo che possa garantire delle roadmap di rilascio.

Molte aziende gestiscono questa attività usando fogli di calcolo e facendo riunioni su riunioni con tutti gli attori della catena di produzione. DevOps permette di disegnare dei processi ben definiti e alla loro automatizzazione in modo da eliminare il proliferare di fogli di calcolo insieme a inutili riunioni.

Continuous Integration (CI)

Grazie alla Continuous Integration si ha la possibiltà di avere la fase di build e di test completamente automatizzata. In questo modo, i team di sviluppo possono modificare, compilare e testare un progetto più volte al giorno.

A questo scopo, il codice sorgente è versionato in un singolo posto (Repository), da dove chiunque può ottenerne la copia corrente (o una precedente). Il processo di build viene automatizzato così da permettere a chiunque di ottenere un sistema funzionante a partire dal sorgente. Il processo di testing viene automatizzato in modo che sia possibile eseguire i test sul sistema in qualsiasi momento.

Grazie alla Continuous Integration è possibilie avere uno sviluppo incrementale del software agevolando le operazioni di integrazione tra i moduli software che man mano concorrono a costituire il prodotto finale.

La Continuous Integration porta un gran valore aggiunto permettendo a grandi gruppi di sviluppatori, su diverse tecnologie e logisticamente distanti, di incrementare lo sviluppo modularmente, riducendo anche i rischi e identificando le anomalie in anticipo.

Continuous Delivery

La Continuous Integration porta alla naturale adozione della Continuous Delivery: il processo di automatizzazione del rilascio del software su tutta la filiera degli ambienti. Con queste tecniche si possono gestire agevolmente rilasci frequenti e numerosi, limitando di molto il rischio di fallimento nel rilascio di una nuova versione.

L’adozione della Continuous Delivery è la parte più critica nell’implementazione di un sistema DevOps.

Continuous Testing

Continuous Testing vuol dire essere capaci di sottoporre il software a test continuamente in tutto il suo ciclo di vita. Questo porta ad avere continui feedback sulla qualità del software prodotto.

Continuos Monitoring and Feedback

I feedback da parte degli utenti possono venire in forme differenti: ticket aperti dai clienti, change request formali, lamentele informali e forme di rating. Il business ha bisogno di un processo chiaro che possa assorbire i feedback dalla miriade di sorgenti e inglobarle nel piano di delivery. Questi processi hanno bisogno di essere agili abbastanza da adattarsi ai cambi repentini di mercato.

Infrastructure as Code

Il concetto di tracciablità all’interno di DevOps è uno dei fattori più caratteristici. Tutto in DevOps deve essere tracciabile, riproducibile e manutenibile nel tempo.

Per quanto riguarda il codice, questi concetti sono stati affinati sempre più negli anni, partendo dai sistemi di versionamento, repository condivisi e via dicendo. Se l’architettura software e il processo di sviluppo del codice è stato progettato correttamente, con gli adeguati tool è possibile sempre tornare indietro nelle varie release del software e riprodurre il tutto “from scratch”.

Tracciabilità delle infrastrutture

Ottenere questo tipo di tracciabilità è stata cosa ben più articolata e difficile con le infrastrutture. Prima dell’avvento della virtualizzazione, i sistemisti si trovavano in difficoltà quando dovevano replicare nel tempo i sistemi sottostanti, vuoi per il passare degli anni e l’evoluzione del “ferro”, vuoi per la difficoltà di sostituire fisicamente dei pezzi fisici dell’architettura.

Con la nascita della virtualizzazione, è diventato più semplice replicare gli ambienti dell’infrastruttura, utilizzando i concetti di clonazione, backup delle macchine virtuali e di tutti gli strumenti a portata dei virtualizzatori. Infrastructure as Code introduce una ulteriore evoluzione nel campo di Operation.

Anche l’infrastruttura diventa codice

Grazie a Infrastructure as Code, è possibile scrivere del codice, sia con linguaggi di alto livello sia con linguaggi di scripting, per amministrare le configurazioni e automatizzare il provisioning di macchine facenti parte di un’infrastruttura. Questo non significa solo semplicemente scrivere degli script. Infrastructure as Code comprende anche pratiche di test e sviluppo che sono già in uso nello sviluppo di applicazioni. Per esempio, controllo di versionamento, test, uso di design pattern e così via. In parole povere, si scrive del codice per fare provisioning e amministrazione dei server.

L’infrastruttura viene generata tramite dei sorgenti, viene gestita con tool automatici, diventa riproducibile, testabile, versionabile. Un vantaggio trasversale ma di grande rilievo è la possibilità di distribuire facilmente in tutta la catena di ambienti macchine che possiedono le stesse configurazioni “production-like” e mantenerle allineate nel tempo. In questo modo si anticipa la scoperta di possibili problemi legati a configurazioni di produzione.

Questa pratica avvicina i dipartimenti di Dev e Ops in quanto, nello specifico, i sistemisti diventano veri e propri sviluppatori di codice che genererà l’infrastruttura.

Delivery Pipeline

Una Delivery Pipeline consiste negli stadi in cui un’applicazione passa dallo sviluppo alla produzione e comprende tutti gli step e la loro interdipendenza per il rilascio del software finale.

Questi stadi posso variare da azienda ad azienda, e possono differire anche da applicazione ad applicazione in base alle esigenze dell’azienda stessa. I livelli di automazione possono essere altrettanto vari. Nella figura 2 viene illustrata una tipica pipeline in ambito DevOps.

Questa catena operativa si compone solitamente di ben precisi stadi:

• ambiente di sviluppo con test di pre-commit;
• ambiente di Build;
• Package Repository;
• ambiente di Test;
• ambiente di Stage e Performance Test;

Vediamo di seguito in dettaglio i diversi stadi della Delivery Pipeline.

Ambiente di sviluppo con test di pre-commit

Tutte le attività di sviluppo prima di effettuare un commit avvengono nella macchina locale degli sviluppatori con il loro ambiente di sviluppo che gli permette di utilizzare il proprio ambiente IDE per scrivere il codice. Tipicamente lo sviluppatore ha anche a disposizione un ambiente di test che viene utilizzato prima di attualizzare il codice nel repository centrale di versioning tramite una commit.

Ambiente di Build

Questo ambiente è quello dove il codice viene compilato per creare i binari e testarli per poi successivamente distribuirli. È possibile usare dei server dedicati se le fasi di build sono particolarmente pesanti e complicate.

Durante i test di integrazione, bisogna avere un set consistente di dati che permettano una serie di test di interazione tra i vari sistemi coinvolti.

Package Repository

Questo ambiente è uno storage comune che raccogli tutti gli artefatti creati durante la fase di build. In questo ambiente possono essere depositati anche file di configurazione e script di deploy.

Ambiente di Test

L’ambiente di Test è quello della Quality Assurance, User Acceptance e dove i team di test fanno… i test veri e propri.

Ambiente di Stage e Performance Test

Questo ambiente è quanto più possibile simile all’ambiente di produzione. Qui vengono fatti girare gli UAT (User Acceptance Tests) e i test di performance. I dati di test devono essere un subset consistente dei dati di produzione in modo da garantire la consistenza e veridicità dei test.

L’ambiente di staging è quello che serve a predisporre tutto l’occorrente per la pubblicazione vera e propria dell’applicazione in ambiente di produzione.

Produzione

L’ambiente di produzione punta ai sistemi reali ed è dimensionato adeguatamente per sopportare i carichi effettivi del software distribuito.

Conclusioni

In questa seconda parte abbiamo dato uno sguardo agli aspetti, spesso sottovalutati, che concorrono alla creazione di una vera e propria cultura DevOps.

Si sono poi affrontate le basi tecniche e tecnologiche sulle quali si fonda DevOps. Si è visto come sia importante prevedere una corretta impostazione e organizzazione dei componenti all’interno di una organizzazione in modo che tutti possano portare un valore aggiunto al ciclo di sviluppo.

Nelle prossime puntate si affronteranno temi più tecnici affiancati a casi d’uso reali sull’adozione di DevOps.