Nel 2019 l'approccio DevOps compie dieci anni. Anche se la ricorrenza, come molti anniversari nel mondo delle tecnologie, è più che altro simbolica. Secondo gli annali dell'IT il termine DevOps è stato effettivamente usato per la prima volta nel 2009, ma va ricordato che esso indica un approccio allo sviluppo e all'implementazione delle applicazioni, non una specifica tecnologia, una lista di regole ferree o un singolo strumento. DevOps non nasce dal nulla e non vive da solo. Non esisterebbe senza l'affermazione delle logiche di sviluppo Agile e non avrebbe importanza se, parallelamente alla sua nascita, non fosse stata in atto una profonda rivisitazione dello sviluppo software.

Il termine DevOps è l'acronimo di development e operations, perché in estrema sintesi l'obiettivo della metodologia è fare in modo che i team di sviluppo e quelli che si occupano del buon funzionamento dei sistemi operino in maniera sinergica e coordinata quando si tratta di portare in produzione, negli ambienti IT aziendali, nuove applicazioni o servizi. Sembra una idea banale, in realtà IT e operations una decina di anni fa vivevano spesso come separati in casa: poche interazioni, quelle poche legate a qualche problema da risolvere.

La constatazione di fondo, da cui correttamente DevOps parte, è che sviluppatori e team di operations hanno esigenze ideali contrastanti: i primi devono innovare modificando frequentemente le applicazioni e i servizi che girano sull'infrastruttura IT aziendale, i secondi vogliono che questa sia stabile per garantirne la massima operatività. È sempre stato così, i contrasti e gli attriti si sono fatti più evidenti quando ai team di sviluppo è stato chiesto di lavorare in maniera sempre più veloce.

Tra Agile e DevOps

È qui che DevOps mostra il suo legame intrinseco con i concetti precedenti di sviluppo Agile. Questi hanno giustamente portato le aziende ad abbandonare lo sviluppo tradizionale e hanno favorito l'adozione di cicli di sviluppo brevi, l'apertura al cambiamento frequente, l'attenzione al miglioramento continuo, l'importanza del feedback degli utenti finali. Ma in questa evoluzione molte aziende hanno puntato dritte sui vantaggi - più funzioni e applicazioni, più spesso - senza considerare che qualsiasi attività di sviluppo non può essere del tutto priva di vincoli.

DevOps aiuta a mettere ordine in questo scompenso, prima ancora di andare a colmare il gap tra sviluppo ed operations, con alcune linee guida per la parte di sviluppo e test. Attenzione, però: DevOps non è un "nuovo Agile". I principi dello sviluppo Agile valgono comunque, con o senza DevOps, e riguardano soprattutto il lavoro dei team di sviluppo, il concetto della qualità del software, l'attenzione al software funzionale. DevOps ha una visione più concreta, operativa e quasi "strumentale", di tutto il flusso sviluppo-implementazione-operations.

Lato sviluppo in sé, infatti, uno degli elementi chiave di DevOps è il concetto di Continuous Integration, o integrazione continua. Come teoria è uno dei principi del modello Agile: non puntare su grandi aggiornamenti applicativi che richiedono settimane o mesi ma su innovazioni incrementali molto più contenute e frequenti. Queste possono essere testate velocemente e portate in produzione quasi subito, ricevendo un feedback immediato sulla loro funzionalità reale.


Il modello DevOps porta questa visione sul piano della concretezza, indicando in che modo muoversi (ma non ci sono tavole della legge, perché non esiste "la" formalizzazione di DevOps) e spingendo per l'utilizzo di strumenti che automatizzano e controllano le varie fasi dello sviluppo. Ad esempio git e GitHub per gestire cicli di sviluppo collaborativo, non lineare e distribuito: ogni sviluppatore interviene sulla sua parte di codice, introduce le sue modifiche e resta sempre aggiornato su quelle degli altri. L'obiettivo è ridurre al minimo il rischio di produrre codice errato per un disallineamento tra i singoli sviluppatori o i gruppi di sviluppo. O che un errore si scopra tardi e per questo si debba scartare tutto un corposo aggiornamento applicativo.

Il test del nuovo codice è un altro elemento importante di DevOps. Idealmente ogni modifica alle applicazioni o ai moduli di codice deve essere testata in ambienti simili a quelli reali ma sicuri, comunque non in produzione. L'obiettivo non è solo bloccare il codice evidentemente errato ma anche valutare il suo livello di rischio: un modulo software anche funzionante e formalmente corretto potrebbe comunque introdurre vulnerabilità, a seconda delle sue possibili interazioni con altri elementi dell'ambiente di produzione.

DevOps: arriviamo alle operations

L'approccio DevOps arriva a toccare direttamente la parte delle operations portando a una formalizzazione dei passi da seguire per implementare in produzione il nuovo codice. Si suppone che la parte di Continuous Integration e testing abbia portato a codice corretto, ma questo non basta.

Uno dei principali punti di contrasto tra sviluppatori e operations è tradizionalmente lo spuntare in produzione di servizi, applicazioni e relative risorse di cui lo staff IT non sa niente o quasi. Non è una questione di shadow IT ma di stabilità stessa dei sistemi: anche nei migliori ambienti IT risorse e applicazioni devono attivarsi - a maggior ragione oggi, negli ambienti di cloud computing - in maniera sicura. Questo ovviamente contrasta con la volontà di avere il massimo di quella "agility" di cui oggi parlano tutti, ma i controlli ci vogliono.

Nel modello DevOps questo contrasto viene superato con una collaborazione fattiva tra le parti - un elemento concettuale e culturale, ma dove si trova la vera carica innovativa di DevOps - e operativamente con strumenti di Continuous Delivery e anche di Continuous Deployment.


La Continuous Delivery è il complemento della Continuous Integration: "riceve" il nuovo codice impacchettato nella maniera più opportuna (ad esempio in un container); configura, attiva e/o rilancia le risorse che lo devono eseguire; effettua altri test di funzionamento oltre a quelli degli sviluppatori; in caso di problemi ripristina tutto allo stato precedente alla ricezione del nuovo codice. Se è previsto che le modifiche passino direttamente in produzione una volta verificato il loro buon funzionamento, la Continuous Delivery diventa anche Continuous Deployment.

L'approccio DevOps prevede poi che la collaborazione tra sviluppatori e operations continui anche dopo il deployment. Controllando la corretta (o meno) esecuzione delle nuove applicazioni e dei nuovi servizi, le operations possono dare agli sviluppatori informazioni importanti per le attività successive di creazione del codice.

DevOps: a chi interessa

Nonostante il mantra secondo cui ogni azienda è (o diventerà) una software house, il dibattito inaugurato da DevOps non ha interessato tutti subito. E nemmeno, nonostante l'onnipresenza del termine, interessa tutti adesso. Però tocca potenzialmente molti.

Ottimizzare al massimo il percorso che va dalla creazione di un nuovo servizio o applicazione alla sua esecuzione e chiuderlo in un ciclo ideale interessava, dieci anni fa, i cloud provider, le aziende di fascia enterprise e i fornitori di servizi online (di qualsiasi tipo: dalle applicazioni in SaaS agli ecommerce fino ai social network). Oggi le realtà interessate sono molte di più, perché la digitalizzazione in generale ha messo un numero molto elevato di imprese nelle condizioni - e anche nella necessità - di migliorare frequentemente i "tasselli" applicativi su cui si basano i propri processi.

Quindi, tanto per fare qualche esempio, DevOps interessa i retailer che vogliono sviluppare sempre nuovi servizi digitali ai clienti per aumentarne il coinvolgimento, le banche che cercano di restare al passo con le esigenze dei clienti, le software house propriamente dette, gli operatori di telecomunicazioni che stanno "cloudificando" le loro piattaforme... In estrema sintesi, tutte le imprese che hanno scelto la digitalizzazione come modo per poter cambiare in meglio i propri processi ogni volta che è necessario.


Un dato di fatto ormai poco confutabile è che le metodologie DevOps portano vantaggi a chi le adotta. Ci sono molte analisi che hanno cercato di quantificarli, tra i vari loro risultati è interessante notare una netta accelerazione della frequenza di delivery di nuovo codice, che arriva ad essere di più volte al giorno. Non tutte le aziende hanno bisogno di operare così frequentemente, ma anche in implementazioni più conservative DevOps riduce notevolmente il tasso di errori del nuovo codice in delivery e il tempo necessario a recuperare da situazioni di errore.

DevOps: i punti deboli

Di suo, DevOps ha un solo importante punto critico, per chi lo approccia: non è una lista formalizzata e univoca di cose da fare. Il concetto di fondo è chiaro - coinvolgere sia sviluppatori sia operations in tutto il ciclo di vita di una applicazione/servizio - ma concretizzarlo oggi vuol dire mettere insieme concetti di sviluppo, test, integration, deployment, automazione, orchestration, infrastructure-as-code e via dicendo.

DevOps è quindi una di quelle discipline per cui non è praticabile l'idea di trovare il (malcapitato) "esperto" aziendale a cui affidare il compito di creare il ponte tra sviluppo e operations. Ci vuole impegno da parte di tutte le figure coinvolte e anche del management. Impegno che certamente arriva una volta quantificati i vantaggi di DevOps, ma che prima non è scontato.


La genericità di DevOps riguarda anche gli strumenti da adottare. Non esiste una piattaforma DevOps formale ma un insieme di tool mirati alle varie componenti dell'approccio - alcuni dei quali sono diventati ormai standard di mercato - e tra cui scegliere quelli più opportuni. In generale la cosiddetta DevOps toolchain può essere molto articolata, con prodotti tanto open source quanto commerciali, e nuovi moduli software interessanti in logica DevOps nascono frequentemente.

Infine, un punto critico che si constata in molti flussi DevOps è una relativa poca attenzione alle fasi di test, nella parte di integration come in quella di deployment. Questo deriva sia da una poca predisposizione "storica" delle aziende ad eseguire test estesi del codice e delle applicazioni, sia dal fatto - peraltro collegato a questa poca predisposizione - che le soluzioni di test automatizzato non si sono granché evolute negli ultimi anni. O perlomeno non quanto il resto degli ambiti toccati da DevOps.

Questo rappresenta un problema e una mancata opportunità. Il problema è che per le specifiche implementazioni di DevOps aumenta la probabilità di avere codice errato oppure applicazioni malfunzionanti, vanificando parte dei benefici stessi di DevOps. L'opportunità mancata è che inserire una mole cospicua di test e controlli di sicurezza nei flussi DevOps, spaziando dai test funzionali all'analisi delle vulnerabilità, aiuterebbe a concretizzare i principi di security by design che gli esperti richiedono. Tanto che l'idea del DevSecOps si è già abbastanza diffusa.