DevOps: cos’è?

Il termine «DevOps» è stato coniato da Patrick Debois all’inizio del 2009 in Belgio.

DevOps è un insieme di processi, metodi e strumenti indirizzati alla (1) comunicazione ed alla collaborazione e punta ad aiutare un’organizzazione a (2) sviluppare in modo più rapido ed efficiente prodotti e servizi software. Quindi uno dei primari obiettivi del DevOps è quello di costituire un ecosistema di strumenti e processi operativi che permettano di abbattere quello che comunemente viene chiamato “Wall of Confusion” e che nei modelli “tradizionali” separa il mondo Development dal mondo delle Operations.

Dove intervenire

Per permettere l’adozione della metodologia DevOps serve intervenire su fattori organizzativi ed infrastrutturali quali:

1. Utilizzo della metodologia agile per lo sviluppo del software;
2. Incremento della frequenza dei rilasci in produzione;
3. Automazione dei processi di build, test e deploy;
4. Disponibilità di un’infrastruttura virtualizzata e/o in cloud;
5. Utilizzo di Datacenter automatizzati e dotati di strumenti di configurazione interattiva (IaC).

Impatti sull’organizzazione

DevOps non è solo un insieme di tool ma anche una rivoluzione nel modello organizzativo e quindi un vero e proprio cambio di “mentalità”.

In molte organizzazioni, lo sviluppo del software e la gestione dei sistemi sono collocati in divisioni differenti. I gruppi preposti allo sviluppo generalmente sono guidati dalle necessità del business operando quindi continue modifiche e continui rilasci evolutivi. I gruppi operativi invece sono concentrati sulla disponibilità e affidabilità dei servizi e sulla gestione dei costi. Questa suddivisione produce quindi un “gap” tra sviluppo e gestione dei servizi che rallenta il passaggio in produzione.

DevOps introduce un radicale cambiamento dell’organizzazione, nasce quindi una figura specifica denominata Leads DevOps Engineer per agevolare questa trasformazione. Queste figure sono responsabili del successo del progetto ma senza alcuna formale autorità sui diversi gruppi coinvolti. Devono possedere conoscenza tecnica e funzionale adeguata al fine di convincere i manager su benefici e necessità, fondamentale il sostegno da parte della dirigenza aziendale.

Impatti sull’organizzazione IT

Anche le strutture IT subiscono una radicale modifica nella loro organizzazione. I principali punti interessati sono:

1. Product Vision: Lo sviluppo si organizza per prodotto, Development evolve in Change (Gestione del cambiamento);
2. Architecture: Collabora strettamente con le aree di prodotto definendo congiuntamente l’evoluzione architetturale;
3. Struttura RUN: la struttura di RUN interagisce a due vie con la struttura di change management.

Come cambia il rapporto tra Architetture e Development

Anche il rapporto tra Architetture e Sviluppo delle Applicazioni tende a fondersi andando quindi ad abbattere la relazione di contrasto che spesso si rileva nelle strutture tradizionali. Architetture e Sviluppo interagiscono costantemente lungo tutte le fasi di realizzazione del prodotto evolvendo reciprocamente, prendendo spunto l’uno dalle esigenze dall’altro.

Change Management diventa il vero motore del modello DevOps

Per far si che tutte queste evoluzioni: organizzative, it, di strumenti e di modalità di interazione, la struttura del Change Management diventa centrale e fondamentale perché vi sia una costante conferma degli obiettivi. Finito il momento dell’entusiasmo iniziale sarà naturale la tendenza a tornare verso la “comfort zone” quindi verso i modello più conosciuti cioè verso i modelli tradizionali. La struttura di change management ha quindi l’obiettivo di ricordare obiettivi, modelli e benefici anche attraverso momenti motivazionali per “riaccendere” l’entusiasmo negli stakeholder diretti (maiali) ed indiretti (polli). Vi rimando a questo articolo “Agile – The Chicken and the Pig” per capire i ruoli di maiali e polli nella metodologia Agile.

Riduzione dei rischi

DevOps oltre a permettere quindi una più efficace interazione tra le strutture produttive indirettamente permette di ridurre il rischio questo grazie ai “micro” passaggi in produzione. Evolvere per “piccoli passi” invece che per pesanti release comporta minori modifiche, anche se più frequenti, con minore impatto e rischio.

La metodologia agile incrementa la frequenza degli eventi di rilascio, frequenza che si misura in giorni o settimane. Questo è in antitesi con pesanti e rari rilasci, misurati in mesi o trimestri, tipico delle tradizionali metodologie di sviluppo. Un’elevata frequenza si traduce in una numero minore di modifiche rilasciate in produzione e quindi in un rischio ridotto.