DevOps Agile e Application Lifecycle Management

DevOps AML Pipeline

Dopo articoli più generali sulla cultura del DevOps e su quanto il DevOps stesso sia vicino (ma non equivalente) alla metodologia Agile, e prima di parlare dei “mestieri” del DevOps (stay tuned), penso sia venuto il momento di raccontarvi come l’unione di metodologia Agile, nuovi paradigmi di programmazione e nuovi strumenti di containerizzazione ed esercizio delle applicazioni possano rendere efficace e fluido un processo DevOps realmente End2End.

Come gli adepti della grande setta del Continuous* avranno già capito, stiamo parlando di:

Continuous Delivery

Ovviamente non è possibile parlare del “fluire continuo di un’applicazione dalla mente del programmatore fino alla messa a disposizione dell’utente” (è questo il significato reale della CD) senza descrivere un Application Lifecycle Management.

Non è possibile descrivere un Application Lifecycle Management DevOps senza introdurvi anche le relazioni (o, meglio, le reazioni) con l’utente finale.

Quello che descriverò è, in effetti, un modo di organizzarsi per avere un sistema End to End di Gestione del codice, build, test, messa in esercizio e feedback sul funzionamento di un’applicazione che un gruppo di lavoro può approntare “in casa” (o in cloud) sfruttando sistemi Open Source disponibili o che prevedono una spesa massima di 10 dollari.

Il tutto tenendo sempre presente alcune cose essenziali:

  • Stiamo parlando del DevOps “cutting edge”, cioè quello che prevede l’uso spinto di tutte le nuove metodologie e i supporti tecnologici “a la page” di ultima generazione.
  • L’ambiente descritto da per scontato che le applicazioni non siano più “pensate” in modo monolitico o a layers, ma siano insiemi di Microservizi dalla mission ben definita, distribuibili, testabili e scalabili in modo autonomo.
  • Pur se separate nelle due aree Dev e Ops, tutto il flusso prevede che un’area abbia una profonda conoscenza di quello che accade, accadrà o si è ipotizzato che accada, nell’altra.

Il diagramma che trovate all’inizio dell’articolo ci aiuterà (dovrebbe) nel ragionamento. Ai colori ho dato il seguente significato:

  • BOX VERDI – Aree dell’ALM dedicate alla gestione pura del codice di un’applicazione e delle librerie a essa funzionali
  • BOX CELESTI – Sistemi di building e orchestrazione dei test con “Quality Gates” associati
  • BOX AZZURRI – Containers e applicazioni containerizzate
  • BOX ARANCIO – Sistemi di test automatico
  • BOX VIOLA – Sistemi infrastrutturali di supporto

Per evitare di lasciare troppo “flottante” quanto descritto, per ogni box darò un mio parere su quale possa essere lo strumento Open (o giù di li) più adatto a implementare il box stesso; siccome io bene o male conosco meglio Java, mi baserò sugli strumenti disponibili per quel linguaggio, chiedo quindi venia agli amici Pythonari e C#pari, ma sono certo che i pezzi non direttamente applicabili al loro ambiente siano facilmente sostituibili con qualcosa di equivalente; anzi, se me le segnalate li aggiungo volentieri.

Chiaramente tutta la giostra ha il fine ultimo di far arrivare il codice presente nel primo box verde all’interazione (proficua) con l’utente, sotto forma di applicazione, rappresentata dall’ultimo box azzurro, nel più breve tempo e con la maggiore efficacia possibile.

Cominciamo.

Dando per scontato che l’area Dev sia tutto un fermento di idee, analisi, storie, stand-up meeting e iterazioni, a un certo punto qualcuno dovrà scrivere una riga di codice e metterla da qualche parte.

Version Control Source: Una cosa che quando ho cominciato praticamente non c’era ed è ora una facility data per scontata è lo strumento di controllo versione e condivisione del software. Non mi dilungherò su di esso (quello che uso io è GIT) se non per dire che qualsiasi strumento usiate è buona norma definire un perimetro base di framework certificati da usare, magari raggruppati in un catalogo di Selected Framework, per evitare di usare diversi framework per fare la stessa cosa o, peggio versioni di framework diverse da quelle già presenti sugli environment di produzione.

Container Images: Analogamente a quanto detto per i framework, se si usano (come consiglio) i container per la distribuzione della propria applicazione e mantenere così l’omogeneità operativa tra i vari ambienti, ritengo opportuno dotarsi di un catalogo di Container certificati da cui attingere per introdurvi le specifiche tipologie (anche tecnologiche) di microservizi che compongono l’applicazione. Penso che sia un dato acquisito che oramai dire Container e dire Docker è equivalente “de facto”.

Application Build System: Certo, potete assemblare codice, frameworks e container a mano o con un IDE, ma come per il sistema di controllo versione sarebbe ormai anacronistico. Meglio affidarsi a un sistema di build centralizzabile, diffuso e affidabile come MAVEN.

Code Quality Reviewer: Una cosa che è bene che chi si approccia alle “cose nuove del cloud” è bene che sappia è che la qualità delle applicazioni non è più “opinabile”, nel senso che se prima, con i precedenti stack tecnologici, ci si poteva permettere di accroccare qualcosa, mandarlo in esercizio e poi dargli martellate fino a farlo funzionare oramai questa cosa è pericolosissima, poichè l’uso dei Microservizi all’interno dei Container e le mutate condizioni di esercibilità e scalabilità degli stessi nel cloud, obbliga chi sviluppa a essere “pulito a monte”, perché questi nuovi strumenti, se pur potenti, fanno perdere velocemente il controllo di quello che succede al loro interno. Lo strumento multi-linguaggio standard (tanto da essere integrato anche in molte suite a pagamento) per coprire questo box è Sonarqube.

Build Test Deploy Orchestrator: Visto che stiamo parlando di Continuous Delivery, ci serve uno strumento che si faccia carico di “mandare avanti” il flusso dell’applicazione man mano che i Quality Gates vengono superati, spostando ogni versione della stessa dall’ambiente di build a quello di test di qualità e sicurezza, test funzionali e di integrazione, fino a farla atterrare (automaticamente o meno, dovete deciderlo voi) in esercizio. Mi sembra che su questo aspetto, il sistema più diffuso e modulare per gestire la pipeline applicativa (ora gestisce anche i Dockers) sia Jenkins.

A questo punto abbiamo la nostra applicazione “in circolo” sotto forma di Application Container, che nel nostro esempio vuol dire un Docker completo di logica applicativa che “naviga” tra i vari ambienti, sul canale della Continuous Delivery, sospinto dal “vento” del nostro Deploy Orchestrator mentre supera le “chiuse” delle altre fasi di test.

Http Test System: Se si parla di microservizi non si può non parlare di API Rest che gli stessi dovrebbero esporre per rendere disponibili le proprie funzionalità. Ciò rende comodo e conveniente sfruttare le API anche per approntare una serie di test atomici automatici sulle funzionalità stesse che rendano anche agevole il controllo della non regressione. Personalmente trovo molto comodo l’uso di SoapUI per coprire questo task.

Issue Tracking System: Come diciamo agli sviluppatori cosa fare? Come manteniamo traccia delle iterazioni su una storia o su un problema? Come tracciamo le risultanze negative di un test di qualche tipo e ne assegniamo la risoluzione? Come raccogliamo automaticamente le istanze degli utenti che lasciano il proprio feedback o segnalano un problema da una form on-line? Ho sempre pensato che l’informazione su un’applicazione e tutte le sue diramazioni debbano risiedere in un unico punto, quello che gli anglosassoni definiscono The Single Point of Truth. Senza dimenticare che la corretta condivisione e circolazione delle informazioni è parte essenziale della Cultura del DevOps. Io strumento che mi ha sempre dato grosse soddisfazioni e che, pur non essendo gratis, offre piene funzionalità per 10 utenti a 10 dollari (si può fare) è Jira.

Containers Orchestrator: Come ho già accennato, l’uso dei Container non è esattamente indolore, poiché l’obbliga sia chi sviluppa che chi esercisce a porsi problemi di distribuzione dell’applicazione più definiti rispetto a quanto necessario con le tecnologie di esercizio applicativo e clustering precedenti. Per fortuna ci vengono in aiuto i sistemi di orchestrazione dei container, che consentono di gestire il ciclo di vita del container in modo più agevole di quanto sarebbe possibile lavorando “a mano”. Recentemente sono stato al Codemotion a Roma e ho avuto conferma che, come già successo per i Dockers, la tecnologia che si sta diffondendo di più sul tema, anche per il suo grado di maturità e di supporto dalla community, sia Kubernetes.

Performance Tester: Container o non Container, a un certo punto dovrete fare delle prove di carico sulla vostra applicazione, possibilmente in un ambiente analogo a quello in cui l’applicazione stessa sarà esercita. Sarò un nostalgico, ma io continuo a trovarmi bene con JMeter.

Systems Monitoring: Come abbiamo visto, il Container contenente una specifica versione della vostra applicazione, a un certo punto, passata la fase di test di performance, andrà in esercizio. Dovrete avere quindi modo di capire se gli ambienti stiano performando correttamente e, in caso di problemi con i test di performance, quale parte dello stack applicativo e tecnologico vada più in sofferenza. C’è uno strumento Open Source che è lo standard mondiale su questi temi, il suo nome è Nagios.

Chiaramente il tutto presuppone che abbiate il pieno controllo delle varie fasi del ciclo di vita dell’applicazione, dalla progettazione alla gestione delle segnalazioni utente e che il team sia realmente multidisciplinare e realmente orientato al DevOps.

In pratica ho descritto un environment DevOps ideale, sta a voi provare a declinarlo e adattarlo, per quanto possibile, alla vostra realtà quotidiana, oppure chiamare un DevOps Architect (uno delle Professioni del DevOps di cui vi parlerò nel mio prossimo articolo) che vi aiuti a farlo.

Vi lascio replicando lo schema dell’ALM DevOps oriented, in cui ho messo in evidenza i tool che ho di volta in volta indicati come lo strumento più adatto per lo specifico task, con la solita avvertenza che tutti i marchi e i nomi dei prodotti citati appartengono ai rispettivi proprietari.

DevOps AML Tools Pipeline

Una visione d’insieme che spero vi sia utile a metabolizzare quanto da me esposto e che farà da base per il prossimo post (stay tuned).

Alla prossima.

I link di oggi:

 

 

One Reply to “DevOps Agile e Application Lifecycle Management”