Il paradigma DevOps si rivela una strategia vincente per il successo dell’impresa digitalizzata.
Le organizzazioni moderne, infatti, richiedono flessibilità, velocità e continuità di servizio senza precedenti. Le applicazioni a supporto del business devono quindi soddisfare i requisiti di alta qualità e delivery rapida. Lo scopo è garantire il regolare svolgimento delle attività aziendali, nonché il raggiungimento degli obiettivi competitivi.
Sviluppare, implementare, distribuire e manutenere gli applicativi secondo le regole DevOps permette di accelerare le tempistiche di rilascio in produzione, contribuendo alla riuscita delle iniziative strategiche.
Cosa si intende per DevOps?
Cos'è esattamente il framework DevOps e quali sono i principi fondanti?
Il termine designa un approccio che facilita la collaborazione tra team interfunzionali di Developers (Dev) e il personale addetto alle It Operations (Ops). L’obiettivo è standardizzare, velocizzare, automatizzare, ottimizzare le attività inerenti alla release applicativa, migliorando la qualità del codice e la sicurezza del software. Il modello promuove un forte cambiamento culturale sul fronte della collaborazione e dell’operatività. Si avvale inoltre di strumenti per l’automazione dei processi, nonché di precetti mutuati dalle logiche di Lean Management.
Sebbene l’approccio prescritto non sia univoco, esistono alcune regole e best practice condivise, ad esempio:
- l’organizzazione in piccoli gruppi multidisciplinari che collaborano ai progetti;
- l’automazione e la ripetibilità dei processi di test e distribuzione;
- la verifica costante della qualità del codice;
- la raccolta dei feedback da parte degli utenti per un migliore allineamento tra applicazione e desiderata.
I 4 pillar della pipeline DevOps
Da qui derivano i quattro pillar che caratterizzano la pratica DevOps:
- Continuous integration e testing
- Continuous delivery e deployment
- Continuous operations
- Continuous assessment
Le fasi sopracitate coinvolgono sia gli sviluppatori sia gli addetti alle Operation. Il fine è quello di coprire ogni fase di sviluppo. L’intero ciclo di vita del software è quindi costituito dai quattro pillar: costruzione della build, rilascio in produzione, mantenimento in esercizio, monitoraggio del funzionamento, valutazione di eventuali difettosità e migliorie.
Continuous integration e testing
La Continuous integration (CI) è un metodo che permette agli sviluppatori di integrare molto frequentemente le variazioni apportate al codice sorgente all’interno di un unico repository. Ma l’integrazione continua non è tutto. I cambiamenti vengono sottoposti a test automatici effettuati a ciclo continuo per identificare da subito eventuali errori di funzionamento. Prima di lavorare a qualunque nuova modifica, i developers attingono a una copia del codice corrente, conservato e convalidato all’interno del repository condiviso.
Continuous delivery e deployment
La Continuous delivery (CD) si pone l’obiettivo di accelerare il rilascio del software. Consente infatti di costruire artefatti eseguibili e production-ready (build) a partire dalla codebase comune, validata attraverso i processi di CI. Il Continuous deployment è l’estremizzazione e il passo finale del processo di distribuzione continua. Permette infatti di distribuire nell’ambiente di produzione ogni singola modifica al codice che abbia superato i test.
SCOPRI DI PIÙ:
Continuous operations
Il concetto di Continuous operations afferisce alla disponibilità delle applicazioni per l’utente finale e alla continuità di servizio. Qualsiasi modifica venga apportata al software (ad esempio, una patch funzionale o di sicurezza) o all’infrastruttura (in caso di manutenzione dei server) deve essere trasparente per l’utilizzatore. L'obiettivo è evitare un’interruzione dell’operatività.
Continuous assessment
Con Continuous assessment si intende la fase di monitoraggio delle applicazioni in produzione (disponibilità, prestazioni, difettosità, ecc), che avviene ad altissima frequenza e in tempo reale. Grazie ai feedback raccolti dagli utenti, gli sviluppatori ricevono indicazioni preziose su eventuali correzioni o migliorie da apportare. Possono così realizzare gli interventi secondo criteri di priorità, basati sull’urgenza e sugli investimenti necessari.
Tecniche, piattaforme e strumenti per il DevOps
Condurre progetti secondo l’approccio DevOps richiede non solo un cambio di passo a livello culturale. È necessario anche il supporto di una serie di tecniche, piattaforme e strumenti in grado di facilitare l’implementazione della metodologia.
Le architetture di sviluppo Cloud Native, ad esempio, possono semplificare l’adozione delle pratiche DevOps. La progettazione che fa uso di microservizi e container si presta particolarmente all'organizzazione del lavoro basata sulla collaborazione di team interfunzionali e orientata ad accelerare le tempistiche dei rilasci.
Le applicazioni infatti vengono concepite come un insieme strutturato di unità funzionali indipendenti (microservizi). Possono essere modificate da piccoli gruppi di tecnici specializzati, senza alterare il comportamento complessivo del software. La possibilità di intervenire sulla singola funzionalità applicativa e in modalità trasparente per gli utenti permette ai developers di operare contemporaneamente e a ciclo continuo. Ogni variazione al codice viene immediatamente recepita, testata, rilasciata e sottoposta alla valutazione degli utilizzatori, che possono restituire feedback preziosi agli sviluppatori.
Le tecniche di containerizzazione invece inseriscono i microservizi o le applicazioni all’interno di sistemi di runtime completi (i cosiddetti “container” appunto). Questi garantiscono il funzionamento del software indipendentemente dall’infrastruttura hardware sottostante. Soluzioni di orchestrazione come Kubernetes amministrano dinamicamente la gestione, la distribuzione e la portabilità dei container in ambienti differenti, assecondando i processi di automazione prescritti dal modello DevOps.
Passando in rassegna le tecnologie a supporto delle pratiche DevOps, troviamo una serie di tool, molti dei quali Open Source. Strumenti che consentono di gestire compiti specifici legati alle fasi della pipeline di progettazione e gestione del software.
Si parte dagli strumenti di planning & collaboration come Kanban Tool e Jira, per arrivare fino a quelli per la gestione della configurazione come Terraform e Packer. Senza dimenticare la fase di monitoring con tool come Grafana, Prometheus e Datadog. Strumenti come GitLab e GitHub, infine, forniscono un aiuto concreto e costante durante tutte le fasi di vita dell’applicazione.
POTREBBE INTERESSARTI:
DevOps strategy: step e consigli per crearla
Chiariti i principi e le tecnologie a supporto del modello DevOps, come è possibile implementare correttamente il framework all’interno di una strategia strutturata ed efficace?
Sviluppare una roadmap chiara e condivisa è un passo fondamentale per ottimizzare il flusso di lavoro e i processi di progettazione, rilascio e monitoraggio secondo le logiche DevOps. Innanzitutto, perché restituisce agli sviluppatori e ai tecnici delle Operations una vista granulare sui processi, garantendo allineamento e sinergia sulle attività in corso.
La disponibilità di un piano di lavoro dettagliato consente di identificare più rapidamente le priorità e i rapporti di interdipendenza tra i diversi processi e gruppi di lavoro. Si può quindi razionalizzare la sequenza degli interventi anche sul medio-lungo periodo, coordinando al meglio le attività di developers e addetti alle Operations.
I consigli per la definizione di una roadmap efficace seguono sostanzialmente le buone pratiche per la pianificazione e realizzazione di qualsiasi progetto complesso.
PER APPROFONDIRE: Come introdurre la cultura DevOps in azienda senza friction
1. Identificare gli obiettivi generali
Fondamentale è partire con le idee chiare, quindi precisando gli obiettivi finali.
Perché si intende implementare una strategia DevOps? Per coordinare e ottimizzare le attività dei team di sviluppo e Operations? Oppure per standardizzare e accelerare i processi di sviluppo e i cicli di rilascio? Per offrire ai developers una codebase condivisa e affidabile per la realizzazione dei progetti applicativi? Tutte le finalità vanno esplicitate.
2. Definire i goal di breve periodo
Definita la “stella polare” che guida la direzione della strategia, il passo successivo è suddividere la roadmap DevOps in obiettivi pratici, raggiungibili a breve termine. Si suggerisce di considerare un orizzonte temporale compreso tra due e sei mesi (90 giorni può essere una finestra plausibile). Questo tempo permette di definire i diversi goal per entrambi i team, senza il rischio di perdere il focus e rimanere troppo vaghi.
3. Utilizzare un approccio visuale
Spesso i progetti falliscono o non vengono approvati perché la roadmap viene descritta soltanto in forma testuale, senza uno strumento di pianificazione e comunicazione visiva. Per identificare priorità e dipendenze a colpo d’occhio, quindi avere ben chiari obiettivi e azioni, invece è necessario ricorrere a diagrammi, colori e vari elementi grafici. La rappresentazione visiva della roadmap serve non solo come supporto per l’organizzazione del lavoro, ma anche come strumento di promozione del progetto verso stakeholders e sponsor.
4. Condividere la roadmap tra Dev e Ops
Il successo di un progetto passa attraverso l’adesione dei soggetti coinvolti, che devono essere sempre informati sull’avanzamento del piano e sugli step successivi. Diventa quindi essenziale condividere la roadmap DevOps tra tutti i team interessati, perché sviluppatori e responsabili delle Operations abbiano ben chiari scadenze, interdipendenze, priorità, task da eseguire.
5. Mantenere la roadmap aggiornata
Inutile aggiungere che una roadmap di successo deve essere costantemente aggiornata per allinearsi agli obiettivi in divenire e allo stato corrente dell’azienda, degli sviluppatori e del team Operations. Una strategia che non rispecchia l’evoluzione del business e i bisogni effettivi dell’organizzazione infatti è inevitabilmente destinata a fallire.
In che modo Agile e DevOps sono correlati?
Talvolta Agile e DevOps vengono raccontati quasi come se fossero intercambiabili, o due lati della stessa medaglia. Tuttavia, i due termini fanno riferimento a pratiche, processi e responsabilità nettamente diverse tra di loro.
In sintesi, Agile affronta il problema della creazione di software, mentre DevOps si concentra sull’installazione in ambiente produttivo del codice sviluppato dai team di prodotto e sul miglioramento di questo processo. Ognuno affronta una parte diversa, ma ugualmente preziosa, dello sviluppo del software.
Certo, un legame tra DevOps e Agile esiste. Possiamo dire che Agile ha posto le basi per la cultura DevOps. Grazie alla metodologia Agile i team hanno a disposizione un modo per creare software più snello e quindi capace di favorire un continuo apporto di valore. DevOps, applicato in un contesto Agile, fornisce ai team un framework per rilasciare e distribuire più spesso nuove funzionalità o nuovi prodotti e aumentare la qualità.
Infine, possiamo considerare anche un altro elemento di correlazione, ovvero il modo in cui Agile e DevOps si completano a vicenda nella vita di tutti i giorni. Agile, infatti, copre la gestione dei progetti e richiede ruoli fortemente definiti come il Product Owner. DevOps, dal canto suo, si rivolge a un lavoro più tecnico. Richiede ai Software Engineer di accettare la responsabilità condivisa per la creazione e la distribuzione del software e al management di pensare al proprio software in un determinato modo.
Fatte queste considerazioni è immediato percepire il valore che un team e un’organizzazione possono ottenere nell’adozione e applicazione di entrambi.
LEGGI ANCHE:
Vantaggi e sfide di DevOps
Qual è il vantaggio che DevOps apporta al modo di lavorare di un'azienda?
Prima di intraprendere un percorso verso DevOps, occorre analizzare a fondo i benefici e le criticità derivanti da una scelta così radicale.
Sintetizzando i vantaggi d’adozione del modello, si possono citare:
- Time to market accelerato - La collaborazione tra i team e gli strumenti di automazione semplificano e velocizzano drasticamente le attività di integrazione, rilascio, implementazione e monitoraggio delle applicazioni.
- Qualità del codice superiore - L’automazione dei test permette di rilevare subito eventuali errori, evitando che entrino in produzione. Anche successivamente, la comunicazione tra Dev, Ops e utenti permette una rapida identificazione e soluzione dei bug.
- Allineamento con i desiderata - Il monitoraggio e la raccolta dei feedback permette di ottenere applicazioni rispondenti alle reali esigenze degli utilizzatori.
- Flessibilità e supporto migliorati - Tipicamente le applicazioni sviluppate in modalità DevOps sfruttano le moderne tecniche Cloud Native, quindi risultano in generale più facili da scalare e manutenere.
- Maggiore efficienza dei team - La condivisione di obiettivi e la visibilità sui processi aiutano i team Dev e Ops, che lavorano con maggiore commitment e coordinazione.
- Riduzione dei costi - L’efficienza dei team, l’accelerazione dei rilasci, la minimizzazione dei rischi garantisce infine una riduzione dei costi per le attività di gestione del software.
Se le opportunità del DevOps sono molteplici, bisogna comunque valutare una serie di sfide quando si decide di affrontare il cambio di passo verso il nuovo paradigma.
Brevemente, i punti a cui bisognerebbe prestare maggiore attenzione sono:
- Change management - Trasformare procedure e consuetudini di lavoro richiede non soltanto l’acquisizione di nuove competenze e tecnologie, ma soprattutto apertura al cambiamento culturale. Non sempre i dipendenti aziendali sono preparati. Normalmente i contesti che hanno già conosciuto la Metodologia Agile risultano avvantaggiati nel processo di cambio culturale.
- Mancanza di competenze e talenti - Il passaggio al DevOps implica una serie di conoscenze metodologiche (sulle pratiche e i principi del modello) e tecnologiche (ad esempio, sulle tecniche Cloud Native e sugli strumenti di gestione/automazione), che difficilmente sono reperibili in azienda. Quindi vanno costruite o acquisite dall’esterno.
- Scelta degli strumenti - Sul mercato esiste una gamma molto ampia di tecnologie a supporto della metodologia DevOps. Data la varietà e la vastità dell’offerta, diventa difficile districarsi e effettuare la scelta corretta.
- Investimenti relativamente elevati - Nonostante i ritorni e i benefici, la barriera di ingresso per il modello DevOps può spaventare. Si tratta infatti di agire su più fronti (organizzativo, culturale, tecnologico, operativo). Bisogna quindi essere disposti, almeno nella fase iniziale, a impegnarsi economicamente e in termini di risorse.
SCOPRI ALTRI FRAMEWORK:
Alla tua azienda conviene adottare DevOps?
Soppesando gli elementi a favore e contrari, bisogna infine capire se il modello DevOps risulta conveniente per la propria organizzazione, analizzando tutte le peculiarità del caso.
Per la maggioranza delle aziende, i fattori positivi vincono nettamente sulle potenziali criticità. Tuttavia occorre considerare che l’improvvisazione e il “fai-da-te” non sono approcci sostenibili in progetti così complessi.
Come evidenziato, la trasformazione DevOps impone una riflessione e una padronanza su molteplici domini. Gestione del cambiamento, competenze sulle architetture Cloud Native e sugli strumenti per il software management, conoscenze delle best practice sono solo alcune delle competenze necessarie.
Ecco quindi che per implementare una strategia DevOps di successo è importante il supporto di un partner esperto e collaudato. Un punto di riferimento che possa trasferire all’azienda il know-how tecnologico e metodologico necessario. Solo con una guida competente sarà possibile ottenere i massimi benefici dal DevOps, superando gli ostacoli.
Tecniche, piattaforme e strumenti per il DevOps
Condurre progetti secondo l’approccio DevOps richiede non solo un cambio di passo a livello culturale. È necessario anche il supporto di una serie di tecniche, piattaforme e strumenti in grado di facilitare l’implementazione della metodologia.
Le architetture di sviluppo Cloud Native, ad esempio, possono semplificare l’adozione delle pratiche DevOps. La progettazione che fa uso di microservizi e container si presta particolarmente all'organizzazione del lavoro basata sulla collaborazione di team interfunzionali e orientata ad accelerare le tempistiche dei rilasci.
Le applicazioni infatti vengono concepite come un insieme strutturato di unità funzionali indipendenti (microservizi). Possono essere modificate da piccoli gruppi di tecnici specializzati, senza alterare il comportamento complessivo del software. La possibilità di intervenire sulla singola funzionalità applicativa e in modalità trasparente per gli utenti permette ai developers di operare contemporaneamente e a ciclo continuo. Ogni variazione al codice viene immediatamente recepita, testata, rilasciata e sottoposta alla valutazione degli utilizzatori, che possono restituire feedback preziosi agli sviluppatori.
Le tecniche di containerizzazione invece inseriscono i microservizi o le applicazioni all’interno di sistemi di runtime completi (i cosiddetti “container” appunto). Questi garantiscono il funzionamento del software indipendentemente dall’infrastruttura hardware sottostante. Soluzioni di orchestrazione come Kubernetes amministrano dinamicamente la gestione, la distribuzione e la portabilità dei container in ambienti differenti, assecondando i processi di automazione prescritti dal modello DevOps.
Passando in rassegna le tecnologie a supporto delle pratiche DevOps, troviamo una serie di tool, molti dei quali Open Source. Strumenti che consentono di gestire compiti specifici legati alle fasi della pipeline di progettazione e gestione del software.
Si parte dagli strumenti di planning & collaboration come Kanban Tool e Jira, per arrivare fino a quelli per la gestione della configurazione come Terraform e Packer. Senza dimenticare la fase di monitoring con tool come Grafana, Prometheus e Datadog. Strumenti come GitLab e GitHub, infine, forniscono un aiuto concreto e costante durante tutte le fasi di vita dell’applicazione.
POTREBBE INTERESSARTI: