Come vi ho raccontato qui, la frequenza di aggiornamento di questo blog seguirà probabilmente un andamento periodico, salvo sbalzi umorali dovuti a momenti di frustrazione per come viene trattato il tema DevOps nelle presentazioni o negli incontri che mi capita di fare in giro.
Visto che ieri ho sentito per l’ennesima volta la frase:
“Ma io pensavo che il DevOps fosse solo un nuovo paradigma di sviluppo, una sorta di Agile 2.0. C’entra anche l’esercizio?”
Adesso vi beccate la ramanzina (che se volete beccarvi in video, trovate qui).
Cominciamo con dire subito il nome dell’assassino, così non dovete arrivare alla fine dell’articolo per scoprirlo (anche se, in realtà, l’ho detto nel titolo):
Il DevOps NON è Agile
Anche se i venditori di tools dicono o provano a far credere il contrario, anche se in rete circolano immagini come quella (corretta da me) che vedete all’inizio dell’articolo, che probabilmente è stata “dedotta” da quella, più corretta, che trovate di seguito (se seguite il link andate alla presentazione completa da cui è estratta), non cadete nel tranello.
Se vogliamo legare le due cose, Agile Programming + Agile Operations può essere considerato DevOps, ma anche Waterfall Programming + Traditional Operations in cui i due gruppi sono sinergici e ognuno si pone per tempo i problemi dell’altro sono DevOps. Perché? Perché DevOps è, prima di ogni cosa:
CULTURA
e in secondo luogo:
La conoscenza End to End di quello che accade a un’applicazione
da quando viene ideata a quando viene esercita
Ovviamente implementare il DevOps in un ambiente Agile (con la maiuscola) è più agile (con la minuscola) che in un ambiente tradizionale, perché la tecnologia Continuous *qualcosa costringe, di default, gli sviluppatori (Dev) a “pensare velocemente” a quello che succederà a ogni iterazione di deploy e a chi esercisce (Ops) a tenere sotto controllo tutte le condizioni al contorno, nel modo più automatizzato possibile.
In pratica resta poco tempo per litigare!! (A meno di non farlo già alla prima iterazione stretta e quindi bruciare il progetto sul nascere).
Quindi, ripeto, non è corretto definire il DevOps come una “nuova iterazione” delle metodologie Agile, ma è sicuramente applicabile (e comodo) a esse per renderne ancora più efficace l’azione nella parte più spostata verso l’esercizio.
Per contro, il DevOps è estremamente consigliabile in ambienti tradizionali, dove la distanza tra i due gruppi è grande (o si sta facendo tale) ed è necessario “ricucirla” prima che l’entropia (la grande compagna dei sistemi complessi) diventi ingestibile.
In queste condizioni, per altro, l’applicazione efficace del DevOps può fare da volano verso l’innovazione, spingendo a uno svecchiamento delle metodologie usate, invogliando i gruppi a provare i benefici di lavorare in Continuous Improvement grazie ai nuovi cicli di Application Lifecycle Management Agile.
Quindi, se qualche spacciatore di tools, che magari “ha capito” il DevOps a modo suo e lo vede come Quelo, cerca di convincervi che se sviluppate in modalità Agile basta “un pizzico” di tools di Continuous Integration per “diventare” DevOps, non fatevi ingannare e ricordatevi sempre che il primo obiettivo da raggiungerle per “essere DevOps” è affrontare il problema di come avvicinare la distanza tra i due (quando sono solo due) gruppi coinvolti, diffondendo, al contempo, la Cultura della collaborazione.
Alla prossima, in cui sospetto si parlerà di “mestieri”.
Approfondimenti su DevOps e Agile: