BlueMind ha integrato la metodologia DevOps nella sua procedura qualità. Grazie all’integrazione continua riusciamo a produrre più rapidamente e con una più elevata qualità.
Il termine DevOps è apparso solo recentemente nel panorama informatico mondiale ma si è già imposto come una delle pratiche più efficaci. Dopo il rapporto Gartner del 2015, il 25% dei 2000 maggiori gruppi mondiali si sono orientati ad adottare DevOps. Più che di un metodo di lavoro, si tratta soprattutto di un cambiamento culturale che mira, come dice il nome, ad avvicinare lo sviluppo all’operatività. L’obiettivo è duplice: ridurre il ritardo della messa in produzione degli aggiornamenti e garantire un elevato livello qualitativo.
Il segreto del processo consiste in cooperazione e condivisione; gli sviluppatori ed i responsabili del rilascio dei sistemi collaborano per rilasciare il software in continuo. I cicli di sviluppo sono più corti, la qualità è valutata durante tutto il progetto e i rilasci sono più frequenti.
“DevOps è un insieme di pratiche e di valori culturali può aiutare le organizzazioni di tutte le dimensioni a migliorare i loro cicli di rilascio del software, la loro qualità, la sicurezza e la capacità di ottenere rapidamente un feedback sullo sviluppo.” — Puppet Labs, rapporto «State of DevOps», 2017
BlueMind ha scelto di adottare DevOps su tutto il processo di integrazione continua, focalizzandosi sulle poste in gioco e sui benefici.
Un nuovo paradigma
Tradizionalmente, gli sviluppatori non condividevano il loro lavoro con il resto del gruppo e procedevano individualmente per lunghi periodi. L’integrazione delle loro modifiche al codice avveniva solo al termine del loro lavoro. Lo sviluppatore non aveva la visione del reale impatto di un aggiornamento sull’insieme dell’applicazione. Di conseguenza è possibile identificare i problemi solo alla fine del ciclo ed è più difficile localizzarli con precisione, ritardando quindi il rilascio degli aggiornamenti.
D’altro canto il settore operativo deve attendere talvolta parecchi mesi che i test ed il rilascio siano infine soddisfacenti prima di poter rispondere ad un’esigenza dell’utilizzatore … che probabilmente nel frattempo è cambiata. I due gruppi, sviluppo e operatività, non condividono gli stessi obiettivi e quindi non hanno le stesse priorità.
Sulla carte le esigenze del software sono chiare, definite e stabili. Gli sviluppatori si occupano del codice, i gruppi operativi dell’implementazione sui sistemi aziendali. Sulla carta…
Nel mondo reale l’informatica si evolve troppo rapidamente per permettere di mantenere fisse le specifiche durante l’intero progetto. Nella prospettiva di un fornitore di software il “progetto” non finisce mai! Le applicazioni devono poter essere rilasciate più rapidamente, ma devono anche poter evolvere continuamente. Nuove funzionalità devono poter essere aggiunte il più semplicemente possibile e gli errori rilevati devono poter essere corretti quanto prima. Le novità non devono compromettere l’esistente e devono tenere conto di tutte le configurazioni ed i casi possibili. Non c’è più il giorno “X” per rilasciare il prodotto come avveniva un tempo.
DevOps e le sue procedure (di qui l’innovazione continua) sono finalizzate a mettere fine a questa guerra tra Dev e Ops – per pervenire all’equilibrio tra innovazione e stabilità.
DevOps: un dialogo migliore tra i gruppi
L’adozione di DevOps consiste nell’attuare un processo globale che coinvolge tutti gli interessati indipendentemente dal loro ruolo iniziale. Dimenticati gli individui isolati e super-specializzati, i gruppi di sviluppo e di implementazione lavorano insieme su tutto il ciclo di vita dell’applicazione, dalla sua ideazione al test fino al suo rilascio ed alla gestione.
I gruppi condividono numerose responsabilità ed incrociano i loro workflow. Ciò permette loro di limitare le perdite di efficacia e di risparmiare tempo.
Dominique Eav – Direttore d’orchestra della qualità BlueMind
“In BlueMind nessuno va avanti da solo nel suo angolino. Coltiviamo la collaborazione e la condivisione per favorire l’efficacia operativa. Abbiamo un obiettivo comune e un piano – garantito dal responsabile del prodotto o della funzionalità – da raggiungere insieme. Tutto il gruppo può seguire i progetti, le idee e le difficoltà di ciascuno.”
Il tempo passato a condividere il saper-fare, le idee e le conoscenze deve garantire ampiamente la redditività del processo in termini di miglioramento dell’efficacia nella qualità dei rilasci, di anticipazione dei problemi/errori e di rapidità della risoluzione.
Integrazione continua
In parole semplici, l’integrazione consiste nell’assemblare pezzi di codice e farli lavorare insieme. Spesso è una vera a propria missione! In effetti, i progetti e gli ambienti sono molteplici, ciascun ambiente con una diversa organizzazione dei moduli coinvolti, dei passi di costruzione, di test, di validazione e di rilascio. L’integrazione continua permette di risolvere questi problemi facendo collaborare tutti gli attori del progetto dallo sviluppo alla gestione.
L’integrazione continua definisce l’insieme delle pratiche che permettono agli sviluppatori di integrare regolarmente le loro modifiche di codice in un repository centralizzato, di creare e gestire automaticamente delle sessioni di test automatici, quindi di rilasciare i risultati se tutti gli indicatori sono verdi. Questo processo permette di individuare e correggere più rapidamente i problemi, di migliorare la qualità e di ridurre i tempi di validazione e di rilascio dei nuovi aggiornamenti.
Storia dei risultati dei test.
Per un dato test si vede la situazione attuale e storica, un FAIL su un test che prima era OK è segno di una regressione.
Ciò permette di verificare, in seguito ad ogni modifica del codice sorgente, che il risultato non produca regressione o errori nelle parti non modificate dell’applicazione. Gli errori sono identificati e quindi corretti più rapidamente, i tempi di validazione e di pubblicazione sono ridotti e, di conseguenza, la qualità complessiva è migliorata.
“Noi utilizziamo largamente il principio di pull request. Si tratta di un meccanismo che permette di condividere e di validare il proprio lavoro senza che questo sia necessariamente concluso. Lo sviluppatore può proporre in qualsiasi momento una “pull request” per sollecitare una revisione delle persone implicate. E’ molto più di una semplice validazione – si tratta di una vera discussione sulla parti tecniche coinvolte con la funzionalità proposta. Inoltre ci assicuriamo, da una parte che tutto il gruppo possa seguire le evoluzioni tecniche e dall’altra dell’integrità delle scelte.” “
— Dominique Eav responsabile della qualità BlueMind.
Cruscotto sulla creazione di un ramo (master)
Questo diagramma presenta i risultati dei test, le differenti tappe della creazione e le versioni precedenti
L’automazione: chiave di volta dell’integrazione continua
Compilazione, test unitari e funzionali, validazione del prodotto, test prestazionali … sono attività essenziali ma dispendiose in termini di tempo, senza parlare dell’errore umano, sempre possibile. Il principio dell’integrazione continua si basa sulla loro automazione per risparmiare tempo e garantire sempre il miglior livello possibile di qualità.
Inoltre, man mano che lo sviluppatore produce del codice, il sistema verifica automaticamente che esso rispetti le regole comuni definite per tutto il gruppo. Questa procedura garantisce la qualità del codice prodotto e la sua stabilità nel tempo grazie al rispetto delle buone pratiche di sviluppo.
Questa funzione di analisi del codice permette di verificare la copertura del test sul codice. Bisogna tendere alla massima copertura possibile.
BlueMind utilizza Jenkins per guidare la catena di integrazione continua. Questo programma permette di testare e di riferire sui cambiamenti effettuati su un ampio spettro di codice in tempo reale per rilevare rapidamente i problemi.
Jenkins ci permette di costruire e testare i nostri rami di sviluppo (funzioni o correzioni), i cui cambiamenti integrano in continuo i nostri release (3.0, 3.5, 4.0), e ciò su tutte le distribuzioni linux supportate (8 per BlueMind 3.5.9). Il nucleo di BlueMind comprende oltre 500 moduli, e interagisce con numerosi AddOns disponibili nel Marketplace, anch’essi costruiti, testati e rilasciati dalla nostra catena di integrazione continua, con gli stessi vincoli di compatibilità e di qualità. Oltre 3000 controlli sono eseguiti su ogni versione. Questo grado di complessità sarebbe impossibile da gestire manualmente! Tutta l’intelligenza dell’integrazione continua risiede nel concatenamento automatico dei vari passi in una logica di industrializzazione dei processi.
“Noi abbiamo un approccio consensuale e pragmatico. Attuiamo e miglioriamo i nostri processi in modo da facilitare la vita dei membri del gruppo, non per rispondere a un elenco di obblighi che ci vengono imposti. L’automazione che ne risulta permette di procedere rapidamente e di far emergere gli eventuali problemi al più presto. Ogni mattone della nostra catena di integrazione continua è una cintura di sicurezza.“
— Dominique Eav responsabile della qualità BlueMind.
Questa funzione di analisi statica che esamina le varie classi, misura il debito tecnico, cioè il tempo necessario a correggere i problemi presenti in questa o quella parte del codice.
Oltre ad eliminare dei compiti fastidiosi, questa automazione permette di rendere affidabile il processo di rilascio al contempo aumentando la frequenza dei rilasci. I gruppi possono quindi dedicarsi e migliorare le funzioni esistenti o garantire una migliore qualità piuttosto che effettuare dei test manuali.
I benefici concreti
L’integrazione continua fa guadagnare enormemente tempo ai gruppi di sviluppo poiché ogni modifica del software è immediatamente testata. Un codice compilato regolarmente permette di identificare rapidamente le modifiche che creano problemi in caso di errore. Lo sviluppatore ha una percezione rapida delle regressioni che può aver causato. Le incompatibilità tra il codice e l’ecosistema nel quale si dovrà integrare vengono anch’esse rilevate molto presto.
Durante tutto il processo di sviluppo e di rilascio, tutto il gruppo collabora strettamente verso una meta comune: la riuscita del progetto nella sua globalità, e non unicamente di sue parti.
Quando tutto il gruppo del progetto è agile, lo sviluppo di una nuova funzione o la correzione di un errore possono essere rapidamente messe in produzione – o annullate se necessario. Une versione funzionante del software è sempre disponibile e non è necessario attendere che il software sia messo in produzione per accorgersi che non funziona. Nel caso di BlueMind, noi per primi mettiamo in produzione queste nuove funzionalità all’interno. Un modo di procedere che chiamiamo “eating your own dog food“, il che significa che siamo i primi utilizzatori della nostra soluzione.
Dal punto di vista dei nostri clienti, l’integrazione continua permette di rilasciare più rapidamente e più di frequente gli aggiornamenti nel contempo garantendo il più alto livello possibile di qualità.
Per concludere
Installare uno schedulatore come Jenkins non è sufficiente per fare dell’integrazione continua. Come specifica il Manifesto de l’Agilité logicielle, gli individui e le interazioni prevalgono sui processi e i sistemi. L’adozione di DevOps dipende dunque dalla responsabilità di tutti. La cultura DevOps implica di adottare un approccio trasparente basato sulla comunicazione e la collaborazione tra i gruppi informatico/operativi e di sviluppo. DevOps è un’eccellente approccio per le aziende che innovano senza posa!
BlueMind si è strutturata fin dall’inizio intorno a questi principi per assicurare il miglior livello di qualità in un contesto complesso. Grazie a questa agilità riusciamo a rilasciare prodotti stabili e performanti attraverso processi industrializzati tra gestione e sviluppo.
