Il paradigma DevOps è una dimensione della trasformazione digitale che si fonda sulla stretta, costante e complessa collaborazione bidirezionale, all’interno di un’impresa, tra i team di sviluppo e test applicativo e le IT operation. Un numero crescente di organizzazioni punta verso la metodologia Agile/DevOps per razionalizzare la fluidità di movimento del codice tra i team dei reparti sviluppo e le operation, e per liberarsi dai rigidi e gerarchici schemi di creazione del software come quelli ‘a cascata’ (waterfall), che rallentano la velocità di rilascio di nuove versioni delle applicazioni, nuove funzionalità. Al contempo, però, per assicurare che DevOps operi nel modo giusto e dia i suoi frutti, occorre anche instaurarlo integrando nel processo i corretti cicli di feedback tra i vari team di lavoro, quindi introducendo strumenti DevOps adatti ed elevati livelli di controllo.
Un compito difficile, perché il trend DevOps sta crescendo con tale rapidità che la sua adozione viene guidata dal basso, seguendo un approccio, cosiddetto, ‘bottom up’: con così tanti strumenti DevOps disponibili sul mercato, molto spesso in forma open source, non è un problema per lo sviluppatore di un team scaricarsi il tool che trova utile per sé e cominciare a usarlo. In questo caotico scenario di ‘shadow IT’, dove gli amministratori di sistema tendono a perdere il controllo degli strumenti usati dagli sviluppatori, e dove dominano insiemi diversi di tool DevOps, risulta arduo per un’impresa riuscire a introdurre una catena omogenea di strumenti. La ricetta magica per scegliere i tool DevOps di sviluppo più adatti a soddisfare alcune particolari esigenze aziendali non esiste, tanto più che tali strumenti DevOps, sia di tipo open source, sia proprietario e commerciale (closed source), proliferano nel settore.
Macrocategorie di strumenti DevOps
La classificazione degli strumenti DevOps in poche macrocategorie, strettamente correlate alle principali fasi del ciclo di sviluppo applicativo, può aiutare nel processo di selezione. Ecco quindi alcune aree funzionali chiave che si possono distinguere.
- Strumenti DevOps di controllo di versione. In una prima categoria sono ascrivibili gli strumenti di gestione e automazione del codice che, attraverso un database, tengono traccia, nel tempo, di tutte le modifiche a un file o a una serie di file, richiamando all’occorrenza specifiche versioni. Oltre ad aiutare i team software a gestire nel tempo questi cambiamenti mantenendo l’ordine, i tool DevOps di controllo versione consentono agli sviluppatori di collaborare e lavorare in parallelo, come membri di un sistema di progettazione concorrente del software.
Uno dei tool DevOps più popolari in quest’area è, ad esempio, Git, un sistema distribuito di controllo versione, liberamente disponibile in modalità open source e studiato per gestire con velocità ed efficienza progetti di piccole o grandi dimensioni. Oltre a Git esiste anche il servizio cloud GitHub, una piattaforma di sviluppo che funziona come repository e luogo di condivisione, revisione, gestione, documentazione del codice e dei progetti. Altri servizi basati su Git sono forniti dai principali cloud provider: ad esempio, Cloud Source Repositories, di Google; Visual Studio Team Services, disponibile su Microsoft Azure; CodeCommit (AWS); Bitbucket (Atlassian), e molti altri. Naturalmente non esiste solo Git: tra gli altri popolari sistemi di controllo versione si possono per esempio citare SVN (Subversion) di CollabNet o Mercurial.
- Strumenti per l’integrazione continua e la distribuzione continua (CI/CD – continuous integration/continuous delivery). Componenti essenziali della metodologia Agile/DevOps, gli strumenti DevOps CI/CD hanno il compito di fondere in automatico nella linea base del codice sorgente, ospitata e condivisa nel repository, tutti i cambiamenti apportati dai diversi sviluppatori del team al codice stesso. Tra i tool CI più diffusi si colloca Jenkins, un server di automazione open source utile per rendere automatiche tutte le operazioni legate alla costruzione, al test e all’implementazione del software. Rispetto a Jenkins le alternative non mancano, basti pensare a tool DevOps come Travis CI, Buildbot, Integrity, Go, CircleCI, Codeship e molti altri.
- Strumenti di gestione della configurazione. Si tratta di tool DevOps che si occupano di amministrare e automatizzare l’installazione, la configurazione e l’aggiornamento delle applicazioni nell’infrastruttura IT. Un buon esempio può essere il prodotto Chef. Ad esempio, Chef Automate permette a organizzazioni con infrastruttura e app basate su una complessa combinazione di risorse on-premise e cloud-based di automatizzare e velocizzare il deployment applicativo. Tra gli altri tool DevOps più popolari con funzionalità analoghe si possono citare Puppet, Ansible, Salt.
- Strumenti DevOps di automazione dell’infrastruttura. Questi tool vengono anche denominati tool IaC (infrastructure-as-code) perché permettono di automatizzare il deployment dell’infrastruttura, amministrandola via software, tramite modelli e file di configurazione che descrivono i componenti, gli stack di risorse (hardware fisico o macchine virtuali) richiesti per far funzionare una singola applicazione, o anche un intero data center. Esempi di questi strumenti DevOps sono Terraform e Packer (HashiCorp), CloudFormation (AWS), Habitat (Chef). Naturalmente, tutti questi tool DevOps operano a stretto contatto con i tool di gestione della configurazione.
Come agire: linee guida utili
Prima ancora che tecnico, il percorso da compiere per introdurre nell’impresa il modello DevOps è prettamente culturale, e non passa semplicemente attraverso una corretta selezione di strumenti software.
Se l’obiettivo della metodologia Agile/DevOps è instaurare un elevato livello di interazione e collaborazione tra reparto di sviluppo software e IT operation, lungo l’intero ciclo di vita (creazione, test, fornitura) del codice, gli scenari caotici a cui si accennava, dove i diversi team usano insiemi di tool differenti, sono esattamente ciò che si vuol evitare. Tali gruppi di lavoro devono infatti cooperare a tutti i livelli della catena e, per farlo, la prima cosa è stabilire, e rendere condivisa, quindi accettata e realmente messa in pratica da tutti gli addetti, una strategia di adozione di un insieme comune di strumenti DevOps, utilizzabili sia dai team di sviluppo, sia dagli amministratori IT.
In secondo luogo, una buona pratica, quando si arriva alla fase di selezione vera e propria dei tool DevOps, è partire da un’attenta analisi preliminare della situazione esistente in azienda: è infatti importante comprendere quali sono gli strumenti già utilizzati dagli sviluppatori nei vari progetti, se funzionano in armonia con gli stack infrastrutturali usati in produzione, e se possono essere in grado di supportare anche il lavoro di altri team. Questo soprattutto nell’ottica di sfruttare al massimo ciò che già di buono è in essere, e di evitare, senza una reale necessità, l’introduzione di tool DevOps alternativi che potrebbero rivelarsi di uso complesso e richiedere una lunga curva d’apprendimento.
Una terza, e non certo ultima, raccomandazione è poi dare importanza non solo agli strumenti CI/CD, ma anche a quelli di ‘continuous feedback’, e alla creazione di framework che permettano ai team di sviluppatori e ai gruppi di lavoro delle IT operation di monitorare la cosiddetta ‘user experience’, quindi come software e app vengono fruiti e giudicati dagli utenti finali. Solo così, infatti, i processi DevOps acquistano realmente senso, attraverso la possibilità di correggere con la massima rapidità i problemi e difetti riscontrati, per consegnare agli utilizzatori finali software di qualità sempre maggiore.
