Introduzione

Con questa serie di articoli entreremo nel vivo di una delle tematiche più calde dell’ultimo decennio: DevOps. La trattazione è più ostica di quanto si potrebbe immaginare perché, con il passare degli anni, dietro al termine DevOps si sono sviluppate tutta una serie di declinazioni di “comodo” che hanno contribuito a generare confusione e a distorcerne il senso stesso.

DevOps è un “viaggio”, un percorso ambizioso che ogni organizzazione deve affrontare dall’interno, investendo risorse e avendo pazienza per ottenere risultati strutturali nel medio e lungo termine. Il nostro compito sarà di accompagnarvi in una visione strutturata del significato “nobile” di DevOps, partendo dalle sue origini fino a valutare gli impatti e le opportunità che si sviluppano quando si decide di abbracciarne la filosofia.

Il vero significato di “DevOps”

Prima di continuare è necessario inquadrare DevOps per quello che è realmente, analizzandolo nel complesso dell’azione di valore aziendale. Questo perché negli anni la confusione in merito ha dato origine al cosiddetto DevOps Elephant: si tratta di una metafora che prende spunto da una storiella edificante diffusa, con alcune varianti, in svariate tradizioni orientali e che, molto sinteticamente racconta quanto segue.

Un re indiano chiama a raccolta un certo numero di persone cieche dalla nascita e dice loro che dovranno descrivergli l’elefante che si trova nel cortile. I non vedenti fanno affidamento sul senso del tatto e cominciano a toccare l’animale, per farsene un’idea. Ma ciascuno tocca una parte diversa dell’elefante, e quindi chi tocca la zampa dice “L’elefante è simile a un albero”, chi tocca la coda dice “Assomiglia a un serpente”, chi tocca una zanna afferma che gli ricorda “Un aratro” e così via. Ovviamente ognuno crede che l’elefante sia quella parte che lui ha sperimentato e da questa convinzione nascono discussioni e litigi.

La metafora della storiella è chiara: avere una serie di visioni parziali non aiuterà a comprendere il quadro generale di una situazione. Si badi bene a un aspetto: nessuna di queste visioni è sbagliata nello specifico; piuttosto, nel complesso, è riduttiva di cosa realmente sia DevOps.

Quindi cos’è realmente DevOps?

DevOps è un approccio culturale che consente di districarsi nell’ambito delle attività complesse caratterizzanti ormai la maggior delle soluzioni digital di una certa rilevanza. Fulcro di DevOps sono le persone coinvolte nel processo di delivery e, in particolare, la loro capacità di collaborare insieme per far fluire le attività nel modo più scorrevole possibile, rimuovendo velocemente gli impedimenti che si verificano lungo la filiera di lavoro.

Volendo trovare una definizione di sintesi, possiamo affermare che:

DevOps è un approccio culturale dove collaborazione, trasparenza e allineamento consentono di affrontare la responsabilità collettiva della creazione di valore per i clienti. In questo contesto, Development e Operation sono al centro dell’azione, sperimentando continuamente nuovi modi di lavorare insieme, puntando sull’eccellenza e sulla standardizzazione dei processi attraverso la pratica costante e la loro ripetizione.

DevOps non è quindi un titolo di lavoro, un tool (o un insieme di essi) o, ancor più pericoloso, una posizione nell’organigramma. Piuttosto, si tratta di un cambiamento culturale che pone al centro l’efficacia e l’efficienza di un’azione di sviluppo, focalizzandosi sul soddisfare gli stakeholder tramite azioni di delivery affidabili e centrate sulle loro necessità.

Proprio la ricerca del giusto equilibrio tra efficacia, nel rispondere ai cambiamenti e alle evidenze riscontrate, ed efficienza, senza la quale nessuna iniziativa è profittevolmente sostenibile, è uno degli aspetti cardini di DevOps.

Un decennio di maturazione

DevOps comincia a prendere forma tra il 2007 e 2008, quando Patrick Debois, in qualità di consulente governativo, si trova a confrontarsi con la difficoltà di abbattere i muri che isolano i team di sviluppo dai corrispondenti operativi (sistemistici), impedendo così di efficientare l’intero flusso di attività.

Debois, convinto agilista, è decisamente frustrato dal contesto specifico e cerca nuovi possibili esperimenti con cui innestare innovazione nei processi esistenti al fine di favorire anche il più piccolo miglioramento.

Un punto di svolta arriva nel 2008, quando all’Agile Conference di Toronto, Andrew Schafer propone un incontro ad hoc sull’argomento “Agile Infrastructure”, dal titolo “Birds of a Feather”, al quale proprio Patrick Debois sarà… l’unico a partecipare. Nonostante ciò, il confronto è particolarmente interessante e comincia a farsi strada il concetto di “Agile Systems Administration”, tanto che Debois e Schafer danno vita all’omonimo gruppo su Google, anche qui però con scarso successo.

Nasce l’idea di DevOps

Nel 2010, John Allspaw e Paul Hammond — di Flickr, all’epoca Senior Vice President of Technical Operations il primo, e Director of Engineering il secondo — presentano alla O’Reilly Velocity Conference l’ormai famoso intervento 10+ Deploys per Day: Dev and Ops Cooperation at Flickr” [1].

I due tecnici mettono su un siparietto per raccontare quanto siano controverse le interazioni tra i team di sviluppo e quelli di operation durante un tipico rilascio, e come le accuse reciproche si moltiplichino: “Non è il mio codice, sono le tue macchine!”

Proprio questo è oggi considerato il “momento 0” che ha dato vita a DevOps, evidenziando come l’unico modo sensato e razionale di sviluppare soluzioni software sia quello di avere trasparenza, continuità e integrazione tra Dev e Ops.

Debois segue l’evento in streaming e, ispirato proprio dall’appena citato “siparietto”, crea il primo DevOpsDay a Gand, in Belgio, formalizzando di fatto il termine DevOps che comincia così a farsi strada nella letteratura di riferimento. A questo punto l’interesse comincia a crescere e nel 2010 si tiene il primo DevOpsDay negli Stati Uniti, a Mountain View in California, dando il la a un filone di eventi che ad oggi conta più di 30 conferenze a tema a livello mondiale [2].

Il passo ulteriore

Nel 2013 arriva il libro The Phoenix Project, scritto da Gene Kim, Kevin Behr e George Spafford che pone le basi strutturali dell’approccio. Si tratta di una novella che racconta la storia di un IT manager catapultato nell’incombenza, apparentemente senza speranza, di salvare un progetto mission-critical.

In suo soccorso arriva, inaspettatamente, un membro dei “piani alti” che lo instrada sui principi della Lean Manufacturing, portando così il manager a sperimentare nuovi modelli di organizzazione grazie all’introduzione di quelli che verranno sottolineati come principi cardini di DevOps (The Three Ways, ne parleremo in seguito).

Focus sulla (Continuous) Delivery

Come più volte ribadito, DevOps è cultura, un cambiamento dell’organizzazione che guarda alla continua creazione di valore attraverso il rilascio affidabile di soluzioni innovative. Non stupisce quindi che a DevOps sia quasi sempre associato il principio del Continuous Delivery, anche se spesso se ne perde il valore nelle azioni tecniche, tanto da confonderlo con il Continuous Deployment, che è un aspetto tecnico abilitante.

In realtà, non si tratta di un errore in senso lato, ma di un utilizzo della stessa terminologia in un contesto differente, al fine di rappresentare esclusivamente l’approccio all’automazione, quindi più localizzato rispetto a quello complessivo oggetto della discussione in essere.

Dallo schema di figura 3, si ha la percezione che il Continuous Delivery rappresenti un processo di automazione del rilascio fino agli ambienti di pre-produzione, mentre il Continuous Deployment estende l’automazione fino al rilascio in produzione. Riflettendo bene, però, si intuisce come la differenza sia veramente minimale se si parla di un approccio olistico, non giustificando, se questa fosse la distinzione, l’esistenza di due terminologie che creano molta confusione.

Nel contesto DevOps la delivery ha sempre l’aspetto intrinseco di “guardare all’utente”, e la Continuous Delivery va considerata esattamente come descritta dal primo principio Agile [3]:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da subito e in maniera continua.

Non solo tool…

In tale ottica, risulta evidente come DevOps non sia semplicemente un insieme di strumenti e pratiche, ma come l’enfasi sia sulla capacità delle persone di instaurare una relazione sociale (cultura) e sfruttare strumenti e processi per generare valore continuo per l’utente finale, in funzione di quattro principi fondamentali, di seguito elencati.

• Il software è sempre rilasciabile: la priorità è mantenere il software distribuibile piuttosto che aggiungere nuove funzionalità. Per fare ciò, si prediligono modifiche atomiche (piccole), e meno rischiose, rilasciate continuamente piuttosto che tutte in una volta.
• Le attività di gestione dei requisiti (backlog), la loro formalizzazione e il loro aggiornamento sono parte integrante del ciclo di valore.
• Un (veloce) feedback loop delle fasi di compilazione, test e deployment consente a tutti gli attori coinvolti di stabilire se è possibile approvare un rilascio immediato in qualsiasi ambiente.
• L’automazione del processo di build, test e deployment è fondamentale per rendere il processo ripetibile e per supportare una maggiore frequenza del tutto.

Tutto ciò implica l’adozione di pratiche agili che aumentano la frequenza di build, test e deployment, grazie al supporto di strumenti che ne automatizzano le parti ripetitive.

Continuous Delivery, Continuous Integration, Continuous Deployment

La Continuous Delivery, quindi, impone letteralmente di mantenere il software sempre in uno stato rilasciabile: nulla può andare in produzione senza aver prima superato i test e le validazioni previste! Tale stato di “rilasciabilità” consente di spostare con confidenza la build in qualsiasi ambiente in qualsiasi momento.

Ed è proprio qui che entra in gioco il Continuous Deployment che si occupa di automatizzare tale “spostamento” della build su un qualsiasi ambiente, azione supportata da strumenti di configurazione automatica e test di varia natura.

Per efficientare il tutto, si ragiona in termini di Deployment Pipeline, andando ad automatizzare il più possibile il flusso che porta dalla Continuous Integration — in seguito al check-in del codice — fino al rilascio su diversi ambienti previsti, ognuno con specifici test.

Il Continuous Deployment è quindi un asset tecnico/tecnologico a supporto del Continuous Delivery, rendendo le attività di compilazione/deployment/test, affidabili, elastiche e capaci di adattarsi automaticamente alle modifiche al codice, agli aggiornamenti dei repository dati e alle configurazioni del server.

In pratica avremo:

• Continuous Build, supportato da script e tool per la Build Automation;
• Continuous Deployment, supportato da script e tool per l’Application Release Automation;
• Continuous Testing, supportato da script e tool per Testing Automation e Virtualization.

Per concludere, in figura 4 si è riportata una possibile rappresentazione che abbraccia quanto detto finora.

Conclusioni

Si chiude qui il nostro primo appuntamento con questa nuova serie dedicata a DevOps. Nel prossimo articolo parleremo delle Three Ways e del rapporto inscindibile di DevOps con Lean e con Agile. Nel frattempo, aspettiamo il vostro feedback.