DevOps è diventato nel giro di pochi anni uno dei principali approcci con cui le organizzazioni affrontano la realizzazione di soluzioni IT al servizio del Business. Questo perché, effettivamente, la sua adozione profonda, organizzativa e tecnico/tecnologica, consente di ottimizzare i processi di delivery di soluzioni con reale Valore per il cliente, andando ad utilizzare al meglio le Persone e le risorse a disposizione.

Da questo blog abbiamo affrontato più volte la tematica primariamente da un punto di vista metodologico, evidenziando come DevOps sia prima di tutto un cambiamento Culturale basato su cinque pillar fondamentali: Comunicazione, Integrazione, Collaborazione, Automazione e Misurazione.

Proviamo, ora, a fare un viaggio attraverso l’ecosistema che Microsoft mette a disposizione di quanti vogliano intraprendere una trasformazione in chiave DevOps, utilizzando soluzioni flessibili, moderne ed integrate che consentono di attraversare tutte le fasi organizzativi ed operative annesse ad una nuova iniziativa IT.

 Microsoft DevOps Philosophy

Le quattro aree in cui ci si muoverà possono essere così specializzate:

• Agile Planning: tutto inizia con una idea… e un piano per trasformarla in realtà.
  • Inizio, vengono effettuate le attività necessarie a validare la sostenibilità dell’iniziativa;
  • Pianificazione, viene creato un project charter di riferimento;
  • Gestire il lavoro, vengono adottate le diverse metodologie e pratiche operative;
  • Tracciare i progressi, viene misurato l’avanzamento del progetto ed i miglioramenti ottenuti nelle diverse aree.
• Develop and Test: una volta che le iterazioni sono partite, i team agili si occupano di trasformare grandi idee in funzionalità.
  • Scrittura del codice, il codice viene scritto dai dev;
  • Unit Test, gli stessi dev realizzano i test relativi al proprio codice;
  • Version Control, una vota completata la scrittura ed una prima validazione, tutto il codice viene salvato nel Version Control System del prodotto;
  • Build, il codice viene integrato in un’ottica di Continuous Integration e quindi viene scatenata la build del nuovo Increment (tutto il codice scritto fino a quel momento);
  • Verifica delle Build, il processo di Continuous Integration si completa con l’esecuzione automatizzata dei test annessi.
• Release: quando tutti i test annessi alla build sono superati, la stessa comincia ad essere dispiegata sui diversi ambienti previsti dal processo di release per le validazioni successive.
  • Ambiente per i test funzionali, l’Increment viene valutato in funzione della sua aderenza ai requisiti funzionali (User Acceptance Test);
  • Ambiente per i test di integrazione e security, qui l’artefatto viene integrato con tutti gli elementi “esterni”, viene validata l’integrazione, così come gli aspetti di security;
  • Ambiente di pre-produzione per stress test, l’Increment è sottoposto a tutta una serie di stress-test per validarne l’affidabilità e la risposta in condizioni di funzionamento non ottimali o inattese;
  • Ambiente di produzione, l’Increment diventa la nuova release del nostro prodotto che viene rilasciata in produzione.
• Monitor e Learn: una volta in produzione, l’applicazione viene costantemente monitorata in modo da ottenere preziose informazioni di allineamento e miglioramento.
  • Monitoraggio, la soluzione in erogazione viene costantemente monitorata, tramite appositi tool di instrumentazione, al fine di ottenere informazioni costanti sul suo funzionamento;
  • Feedback, tutte le informazioni di funzionamento, insieme a quelle esplicite degli utenti, vengono raccolte e diventano un elemento portante per il planning delle successive attività.

Lo scopo è quello di favorire il flusso costante (flow, 1° principio di DevOps) del lavoro lungo tutta la pipeline di delivery andando ad individuare quanto prima, e possibilmente in modo automatizzato, i problemi, trasformandoli in feedback (feedback, 2° principio di DevOps) e consento al team di prodotto di migliorare costantemente l’intero processo (learn and experimentation, 3° principio di DevOps).

Fondamentale è la pratica di conferire a tutti i membri operativi del team, nessuno escluso, la possibilità di “interrompere” le attività in corso per risolvere qualsiasi problema si verifichi sulla pipeline stessa, esattamente come avviene per TPS (Toyota Production System) /Lean con l’Andon cord.

Andon cord

Questo approccio è fondamentale per identificare i problemi il più vicino possibile alla fonte, ed evitare che si sommino e propaghino lungo la pipeline andando ad aumentare il Debito Tecnico.

Nei prossimi post andremo ad affrontare in dettaglio ognuno di questi macro aspetti, in relazione a Visual Studio Team Services (o TFS), Office 365, Visual Studio, e le altre soluzioni del mondo Microsoft, evidenziando come sia possibile integrarli con soluzioni terze laddove sia necessario estenderne le funzionalità o coprire aree attualmente non contemplate.

L’obiettivo è quello di dare una visione lineare su come l’ecosistema di Redmond sia in grado di supportare le necessità di chi decide di abbracciare il paradigma DevOps, sia nelle pratiche metodologiche che negli aspetti tecnici/tecnologici.

Non entreremo, quindi, nel dettaglio delle singole funzionalità offerte dai differenti tool, né, tantomeno, li riporteremo necessariamente tutti in modo esplicito, lasciando al lettore la scelta di approfondire ciò che ritiene opportuno tramite l’ottima documentazione e i blog tematici disponibili online.

Per ora è tutto, ci aggiorniamo al prossimo post.. stay tuned