Introduzione
Nei due precedenti articoli della serie abbiamo enfatizzato l’importanza di superare il Value Canyon grazie a un approccio olistico basato sulla cultura e che sfrutta la progressione delle tre vie per DevOps per costruire un’organizzazione orientata al cliente.
In questo nuovo appuntamento, andremo a esplorare i cinque pilastri portanti di DevOps e l’insieme degli attori e degli strumenti che danno corpo alla DevOps Delivery Pipeline.
I cinque pilastri di DevOps
Lo sviluppo di una cultura che possa accompagnare l’organizzazione nel percorso di trasformazione DevOps si basa su cinque pilastri fondamentali; tali five pillars sono di seguito illustrati.
Comunicazione
Si punta a una comunicazione con pochi formalismi e massima trasparenza. La comunicazione è alla base della creazione di relazioni sociali, intra-team e inter-team, fondamentali per costruire una realtà basata sulle Persone e su un ambiente in grado di valorizzarne le professionalità.
Integrazione
Per integrazione, si intende sinergia in chiave olistica rispetto al business. I diversi work center — ossia i team, secondo la nomenclatura Lean — devono avere visione di quello che accade complessivamente, con focus su quelli a valle e a monte delle proprie attività.
Collaborazione
Collaborazione comporta anzitutto massimizzare il risultato complessivo. Il modo migliore per affrontare le sfide che immancabilmente si presentano è quello della collaborazione a tutti i livelli: ridurre i processi a “quelli che non si avvertono” è un dovere dei manager chiamati a creare un contesto aziendale efficace ed efficiente.
Automazione
L’utilizzo di piattaforme e tool per efficientare il processo è in sintesi il significato di automazione. I prodotti e le organizzazioni odierne richiedono strumenti, a supporto, che siano innovativi e accessibili, permettendo di automatizzare le attività ripetitive che, in quanto poco stimolanti, sono spesso fonte di errori banali.
Misurazione
La misurazione consiste nell’avere elementi oggettivi per valutare i miglioramenti ottenuti. Misurare i propri progressi attraverso metriche realistiche (actionable metrics) è un’azione fondamentale per capire se si sta andando nella direzione giusta o se sia necessario rivedere le proprie ipotesi perché la verifica sul campo ha dato un esito diverso dalle attese.
Ognuno di questi pilastri deve essere presente all’interno della propria azione di delivery — non deploy, che ricordiamo essere un’azione tecnica a supporto della delivery — creando un ecosistema complessivo che può assumere diverse sfaccettature e che va opportunamente bilanciato al fine di ottimizzare l’intero flusso di delivery in funzione degli obietti di business, in chiara logica Lean.
Be CALMS… and stay Agile
Proprio per attuare questo bilanciamento, all’interno del proprio DevOps journey, è possibile sfruttare il meta-framework operativo CALMS, creato da Damon Edwards e Jez Humble, il cui nome è un acronimo formato dalle diverse leve a disposizione per raggiungere tale obiettivo: Culture, Automation, Lean, Metrics, Sharing.
Culture
Culture, gestire il cambiamento focalizzandosi sulla collaborazione e la comunicazione Hearts & Minds, Embrace Change
Automation
Automation aiuta a rimuovere le azioni manuali lungo la catena del valore: “Continuous Integration, Continuous Deployment, Infrastructure-as-a-code”.
Lean
Si utilizzano i principi lean per velocizzare, standardizzare e rendere efficienti le attività: “Customer Value focus, Small batch size”.
Metrics
Le metriche consentono di misurare ogni cosa che si ritenga utile valutare, utilizzando i risultati per rifinire costantemente le attività: “Measure Everything, Show the improvement”.
Sharing
Condividere (sharing) le esperienze di successo e di fallimento contribuisce a una crescita diffusa: “Open Information Sharing, Collaboration”.
L’obiettivo è proprio quello di avere un giusto bilanciamento sul livello di maturità dei cinque elementi, ottenendo costantemente una istantanea dell’azione di Change Management che permetta di individuare le successive strategie di miglioramento.
DevOps Delivery Pipeline
Quanto appena detto ci proietta direttamente a parlare della DevOps Delivery Pipeline (DDP, nota anche come Agile Deployment Pipeline, Continuous Delivery Pipeline, Build Pipeline, etc.): si tratta del flusso che descrive le azioni primarie per portare la soluzione nelle “mani” dell’utente finale.
DevOps Delivery Pipeline è un concetto ispirato al Value Stream del Lean:
Tutte le attività necessarie a produrre una soluzione consumabile sono parte di un flusso complessivo in cui ogni area di lavoro produce un elaborato che viene prelevato dall’area di lavoro a valle quando questa è pronta a riceverlo (pull).
Value Stream Mapping
La tecnica più utilizzata per visualizzare il flusso complessivo è quella del Value Stream Mapping [1] in cui vengono mappati l’insieme dei processi e delle attività che concorrono alla realizzazione di una soluzione, partendo dal concepimento della stessa fino alla consegna della soluzione finita.
Il presupposto, sul quale basare l’analisi, non è il miglioramento della singola area di lavoro, bensì l’ottimizzazione globale e continua. In tal modo è possibile individuare le cause degli sprechi nel flusso specifico, rendendone partecipi tutti gli attori interessanti al fine di approntare opportune soluzioni e condividere i miglioramenti apportati.
L’uso che stiamo facendo della parola “consumabile” merita una specifica riflessione. Produrre una “soluzione consumabile” significa considerare tutte le attività necessarie a rendere realmente utilizzabile la soluzione da parte dell’utente finale (un esempio per tutti: la creazione del manuale utente), e non fermarsi all’ipotetico termine dello sviluppo.
Tornando alla DevOps Delivery Pipeline, è possibile descriverla schematicamente attraverso la figura 4:
DDP: first mile e last mile
La DDP si compone di due macro-aree (o momenti): first mile e last mile.
Il first mile è la prima parte della pipeline, con focus sullo sviluppo della soluzione (codice, nel caso di software, manufatti specifici nel caso di altre tipologie di prodotto/soluzione). In essa identifichiamo:
- Agile Project Management per gestire in modo integrato le diverse fasi di delivery;
- Integrated Development Environment (IDE) per sviluppare il codice con strumenti moderni e integrati;
- Version Control System per la gestione efficace della propria codebase;
- Continuous Integration per integrare e testare giornalmente i diversi manufatti.
Il last mile è la seconda parte della pipeline, con focus sul deploy e il relativo supporto a livelli di servizio in produzione (o in esercizio). In essa identifichiamo:
- Continuous Integration che viene largamente utilizzato con un efficace supporto dei tool;
- Continuous Deployment che è l’area su cui attualmente le società stanno facendo i maggiori investimenti.
Continuous Integration
Come si può notare, la Continuous Integration (CI) è una sorta di “confine” che assembla i manufatti realizzati, li testa, e li “consegna” alla fase di verifica, validazione ed erogazione. Grazie ad essa è possibile:
- portare rapidamente alla luce i problemi;
- ridurre i rischi annessi allo scheduling e al budget in generale;
- rendere la qualità del codice visibile e misurabile.
- eseguire frequentemente e automaticamente i test per validare la soluzione.
L’essenza della Continuous Integration è condensata nei 10 principi ad essa relativi, che si riflettono in modo diretto su pratiche concrete nello sviluppo dei prodotti.
- Mantenere un Single Source Repository
- Automatizzare le build
- Rendere la build self-testing
- Chiunque può fare il commit giornalmente sulla main-line
- Ogni commit deve generare una build della mainline su una macchina di integrazione
- Mantenere le build veloci
- Effettuare i test in un ambienteclone di quello di produzione
- Rendere semplice l’accesso all’ultima build
- Tutti possono vedere cosa sta accadendo
- Deploy automatizzato
Per completezza della trattazione è doveroso evidenziare che la CI nasce intorno al 1999 all’interno della community di eXtreme Programming (XP) come risposta alla sempre crescente complessità dell’integrazione delle varie parti di un sistema software [2].
Conclusioni
Si chiude qui il terzo appuntamento con il nostro percorso alla scoperta di DevOps. Nel prossimo articolo parleremo delle strategie di testing e vedremo come esse sono un aspetto essenziale, e non un’opzione, per applicare proficuamente DevOps nello sviluppo delle proprie soluzioni.
Nel frattempo, aspettiamo i vostri feedback.