Le piattaforme e gli strumenti

Siamo giunti all’ultimo appuntamento di questa lunga serie dedicata a DevOps. Nei precedenti articoli abbiamo affrontato DevOps nelle sue fondamenta più radicate, evidenziando in modo esplicito come si tratti di un vero e proprio cambiamento culturale atto a efficientare e rendere efficace l’intera azione inerente allo sviluppo di soluzioni IT.

Vedremo ora come alcuni tra i principali framework di scaling abbiano abbracciato da tempo, e in modo sistematico, le three ways di DevOps, chiudendo la trattazione con uno sguardo al panorama di piattaforme e tool a supporto.

Scaling Agile Framework

Quando si parla di scaling agile framework ci si riferisce ad un sorta di “infrastruttura” metodologica, articolata in un insieme di principi, pratiche, regole e linee guida, utili per sviluppare un mindset Agile & Lean a livello olistico, ossia in tutta l’organizzazione [1].

Un framework di scaling resta un framework agile se fa propri i valori e i principi del Manifesto Agile, andando a estenderli e declinarli nelle diverse aree applicative.

Riferendoci al tredicesimo “Annual State Of Agile Report” (2019) [2], si evidenzia la situazione generale riportata nella figura 1.

In particolare, due dei tre framework più utilizzati, ossia Scaled Agile Framework (SAFe) e PMI Disciplined Agile (PMI DA), contemplano in modo esplicito l’approccio DevOps, e di seguito si andrà proprio a fornire una panoramica generale che descrive come ciò si sviluppi attraverso filosofie di integrazione diverse.

DevOps and Scaled Agile Framework (SAFe)

In SAFe 5.0 [3], DevOps fa parte delle competenze necessarie a rendere efficace l’Agile Product Delivery, ossia l’approccio Lean Enterprise customer-centric focalizzato sulla definizione, costruzione e rilascio di un flusso continuo di prodotti e servizi di valore per clienti e utenti.

Questa scelta inquadra DevOps primariamente nella configurazione “Enterprise” e non “Essential” del framework. Lo scopo è quello di abbattere i silos e potenziare la capacità degli Agile Release Train (ART), così come degli eventuali Solution Train, riducendo la separazione tra le aree di sviluppo e quelle di operation, e andando a sviluppare una Continuous Delivery Pipeline automatizzata.

In questo modo si favorisce la definizione, l’implementazione e la consegna di soluzioni, andando a ridurre il più possibile l’hand-off tra i diversi attori coinvolti e automatizzando tutti gli aspetti che possono essere standardizzarti ed eseguiti senza interventi manuali.

Visto che molti dei concetti e principi di SAFe (systems thinking, small batch sizes, short iterations, fast feedback, ecc.) si ispirano a Lean, e avendo più volte ribadito e dimostrato come DevOps sia proprio la declinazione attualmente più efficace di Lean nel mondo dell’IT, risulta evidente come lo stesso sia per definizione parte integrante di SAFe.

Inoltre, il framework di Leffingwell, non limita (giustamente) la discussione solo alle aree di sviluppo ed operation, ma la estende a tutti quegli aspetti (e quindi team/specialisti relativi) necessari al rilascio di valore come: security, compliance, audit, marketing, legal e altri. In tal modo si va a porre un argine a diramazioni specifiche (DevSecOps, DevDataOps, ecc), riportandole tutte sotto un unico cappello e in un contesto concreto e coerente.

CALMR

La filosofia di integrazione di DevOps in SAFe è sintetizzabile dall’approccio CALMR (rivisitazione del framework CALMS [4]), schematizzato in figura 3.

Nello specifico si ha:

• Culture of Shared Responsibility, azione focalizzata sullo sviluppo di una cultura della Condivisione delle Responsabilità, abbracciando i valori, i principi e le pratiche Lean/Agile, e quelli specifici di SAFe.
• Automation of Continuous Delivery Pipeline, automatizzare il più possibile, riconoscendo che i processi manuali sono degli “anti-pattern” rispetto ad una delivery rapida e sicura. L’automatizzazione riguarda non solo il fattore “tempo”, ma anche la capacità di migliorare la qualità della soluzione — testing, ne abbiamo parlato nell’appuntamento precedente — e l’affidabilità in generale, finanche la raccolta dei feedback dagli utenti.
• Lean Flow Accelerates Delivery, i team e i treni sono ingaggiati nel raggiungere uno stato di flow continuo, consentendo alle nuove funzionalità di passare rapidamente dall’idea al campo. Il cuore dell’azione è quello di ottimizzare a medio/lungo termine la continuous delivery pipeline.
• Measurement of Everything, viene posta l’enfasi sulla capacità di raccogliere dati in modo automatizzato e in tempo reale, sia di prodotto che di processo, permettendo di misurare costantemente l’impatto delle modifiche apportante. In tal modo è possibile intervenire prontamente laddove si riscontrano scostamenti da quanto atteso, e prendere decisioni su “dati oggettivi” piuttosto che su “intuizioni”.
• Recovery enable low risk releases, il sistema deve essere basato su un’architettura in grado di permette il ripristino di singole parti atomiche, disaccoppiate tra loro, in modo tale da ridurre e localizzare l’impatto di un eventuale failure. Si tratta di abilitare le tecniche di Release on Demand.

DevOps and PMI Disciplined Agile

Nel caso di PMI Diciplined Agile [5], ci si trova difronte a una specifica area denominata Disciplined DevOps, che va a estendere il core del framework, rappresentato da Disciplined Agile Delivery.

Disciplined DevOps è la concretizzazione disciplinata del principio della Continuous Delivery, ossia un efficiente Value Stream in grado di portare continuamente nuovo valore nelle mani degli stakeholder.

Ma cosa rende DevOps “disciplinato”? La sintesi la si incontra nella specifica definizione data da DA:

Disciplined DevOps is the streamlining of IT solution development and IT operations activities, and supporting enterprise-IT activities, to provide more effective outcomes to an organization.

Non solo Dev e Ops, quindi, ma l’intero ecosistema a supporto della soluzione è chiamato a collaborare per il suo successo, similarmente a quanto suggerito da SAFe, andando ad inglobare le derivazioni come DevSecOps, DevDataOps, DevXXXOps, e così via.

Nella sostanza, DA suggerisce di estendere gradualmente l’approccio DevOps alle varie funzioni coinvolte, in modo da far maturare progressivamente nel proprio contesto la Cultura necessaria a tale cambiamento.

Come è visibile dal poster, Disciplined DevOps individua 5 process blade (specifiche aree di intervento) espliciti, oltre a “inglobare” quelle di Disciplined Agile Delivery:

Nello specifico si ha:

• IT Operations, fornisce un ecosistema IT affidabile. Si tratta di garantire l’opportuno livello di Quality of Services ai propri utenti, cosa che può risultare non banale nelle organizzazioni con molti sistemi legacy e alto debito tecnico annesso.
• Support, anche Help Desk o End-User support, si concentra nell’aiutare gli utenti finali a lavorare con le soluzioni realizzate. Idealmente, le soluzioni dovrebbero essere utilizzate senza il bisogno di nessun supporto in merito, ma spesso ciò non accade e il “support” è “l’ultima linea di difesa” per deliziare i clienti con i propri sforzi.
• Security, il cui focus è attivare le azioni necessarie a proteggere l’organizzazione da minacce informatiche, virtuali o fisiche che siano. Ciò include procedure come la governance della sicurezza e la gestione delle vulnerabilità. Il tutto impatta sulla capacità di ripristino di emergenza e continuità aziendale, e deve essere un aspetto fondamentale della cultura organizzativa.
• Data Management, in ottica DA, che promuove un approccio pragmatico e semplificato alla gestione dei dati che si adatta al resto dei processi IT: ottimizzare l’intero flusso di lavoro, non sub-ottimizzando la strategia di gestione dei dati. Una gestione dei dati, agile e disciplinata, è una gestione evolutiva e collaborativa, grazie a strategie concrete che forniscono i dati giusti al momento giusto alle persone giuste.
• Release Management, si occupa della gestione dei rilasci, grazie alla pianificazione, il coordinamento e la verifica della distribuzione (deploy) delle soluzioni in produzione. Il versioning richiede la collaborazione tra Dev e Ops, cosa che l’approccio agile può portare ad essere anche un’unica entità grazie al concetto di “you build it, you run it”.

Piattaforme Digitali e Tool

Per creare una DevOps Delivery Pipeline robusta, non è possibile fare a meno di tool che consentono di automatizzare tutto il possibile. D’altronde, proprio alcune delle pratiche portanti, che possiamo far risalire a eXtreme Programming, non potrebbero essere realizzate senza: si pensi alla Continuous Integration che senza un tool a supporto sarebbe semplicemente irrealizzabile.

Attualmente, il panorama delle possibili soluzioni conta decine di soluzioni, stand-alone o integrate.

Una strategia per potersi districare tra essi è quello di concentrarsi su quattro aree primarie da coprire necessariamente per supportare una robusta adozione di DevOps, piuttosto che partire dal singolo tool o dalla specifica piattaforma.

Andando ad esplorare tali aree nel dettaglio si ha:

• Agile Planning, specifica della gestione del progetto e del relativo stato di avanzamento. Tra le funzionalità primarie da soddisfare si annoverano Delivery plans, Dashboards, Kanban boards, ecc.
• Develop and Test, specifica dello sviluppo vero e proprio e degli aspetti di testing fino alla Continuous Integration (inclusa). Qui si evidenziano attività relative al Development, Source Control, Continuous Integration, Testing, Security scanning, ecc.
• Release, incentrata su tutti quegli aspetti che consentono di spostare la build (increment), generata durante la continuous integration, sui successivi stage di validazione, fino alla produzione stessa. La scelta se rendere automatico anche il deploy in produzione è di business, e non tecnica. Qui si annoverano: Continuous Delivery, Functional Testing e Release Management.
• Monitor and Learn, dedicata al monitoraggio delle soluzioni e alla raccolta sistematica dei feedback (automatici o espliciti), attraverso azioni di: Aplication Analytics, Logging & Operations Analytics, Mobile Crash Reporting.

Nell’individuazione della soluzione più adatta si può decidere di costruire una propria “piattaforma”, integrando tool specifici, o scegliere una piattaforma integrata (come Azure DevOps, Atlassian, ecc.), oppure effettuare un mix delle due, sostituendo alcune funzionalità base della piattaforma scelta con tool più verticali laddove se ne dovesse ravvisare la necessità.

Conclusioni

SI conclude qui il nostro lungo viaggio nel mondo DevOps.

L’obiettivo, fin dal principio, è stato quello di evidenziare ed enfatizzare come DevOps sia un vero e proprio cambiamento culturale, che impatta non solo l’area di sviluppo e di operation, ma l’intera azione di business, andando ben oltre l’adozione di un tool o di una piattaforma di automazione.

Si tratta di efficientare l’intera delivery pipeline, ossia la capacità di gestire al meglio tutte le attività necessarie a trasformare una idea (o un requisito) in una soluzione funzionante (o un incremento) utilizzabile dall’utente finale.

Il tutto, riducendo gli sprechi, dovuti spesso ad una burocrazia eccessiva e a scarsa comunicazione, andando ad automatizzare tutto il possibile e velocizzando i feedback ad ogni livello, sforzandosi sempre di risalire al cuore di ogni eventuale problema (root cause analysis). Feedback che non servono solo ad analizzare eventuali problematiche, ma che sono anche l’humus per far germogliare una cultura orientata alla sperimentazione e al miglioramento continuo, fondamentale per poter adattarsi in un mercato in continua evoluzione e scoprire “modi migliori di creare valore, sviluppandolo e aiutando gli altri a fare lo stesso”.

Per ogni commento, domanda o suggerimento, non esitate a contattarmi.