Le strategie suggerite da DA2 per Disciplidned DevOps consentono, come detto, l’abbattimento dei Silos organizzativi in funzione di una Cultura condivisa e in funzione del comune obiettivo di migliorare il processo di Delivery.
Ripartendo dal post precedente, diamo uno sguardo al primo insieme di elementi strategici (primo solo per ordine di elencazione), ovvero quello relativo al Development, in cui le azioni si concentrano sul migliorare la validazione e il passaggio tra gli ambienti di quanto realizzato:
- Canary Test: si tratta di una pratica pensata per validare le potenzialità, di interesse e di revenue, di una nuova feature, proponendola ad un gruppo di “early adopter” e quindi dispiegandola in una sandbox che non richiede particolari azioni di deployment. Questo test e’ estremamente utile per ottenere feedback diretti e solo successivamente rinforzare quanto realizzato e attivare tutti gli aspetti della pipeline di Delivery;
- Split Test (anche A/B Test): si tratta di una pratica in cui diverse opzioni relative alla stessa feature, vengono realizzate e fatte girare in produzione per determinare “sul campo” quale di essa e’ la più efficace. Normalmente gli utenti vengono segmentanti in differenti gruppi e ognuno di esso lavora con una sola delle implementazioni. I sistemi di monitoraggio passivo, tipo monitor o logging, fornisco le necessarie informazioni per la scelta;
- Automated Regression Testing: l’utilizzo di batterie di test di regressione permette di garantire un livello relativo di qualità e promuovere per il deployment solo le build affidabili, in modo da ridurre il più possibile gli annessi problemi in produzione e, di riflesso, il carico di attività di Ops. In particolare è sempre buona pratica definire diverse batterie di regression test, potendo questi ultimi diventare onerosi da eseguire;
- Continuous Integration (CI): consente di ottenere (potenzialmente) ad ogni commit delle modifiche, nel Version Control System, una nuova Build della soluzione, integrata e sottoposta ai diversi livelli di test, da quelli funzionali a quelli di regressione di cui sopra;
Continuous Integration process
- Continuous Delivery (CD): è lo step immediatamente successivo a quello di CI, in cui la Build validata viene promossa automaticamente al successivo ambiente, ad esempio in quello di pre-produzione, dove vengono effettuate ulteriori azioni di test/verifica/validazione. Se tutte le azioni annesse sono automatizzate, e’ possibile, in ultimo, raggiungere direttamente la produzione (Continuous Deployment). Questa strategia consente di ridurre fortemente il gap dalla richiesta di una nuova feature alla sua messa in erogazione (lead time), ma richiede una forte disciplina nello sviluppo al fine di evitare che il prodotto dispiegato automaticamente sia affetto da errori importanti il cui costo aumenta significativamente in relazione all’ambiente in cui si interviene
Continuous Delivery process
- Development Intelligence: si tratta di un sub-set dell’IT intelligence (si veda Data Management Strategies), focalizzato sugli aspetti di sviluppo. In pratica, grazie a Dashboard popolate dai diversi tool utilizzati, e’ possibile avere un quadro di come procede l’attività complessiva e sui punti su cui intervenire per migliorare il tutto. Con “tool” non si intendono solo quelli digitali, ma anche, ad esempio, quelli “materiali” tipici del mondo Agile/Lean come la Kanban board.
Oltre a queste strategie development-friendly, in chiave DevOps, i team di dev possono adottare una serie di accorgimenti (operations-friendly feature) utili per supportare il dispiegamento della soluzione:
- Feature access control: utile soprattutto per supportare le strategie si sperimentazione, come Canary e Split. Si basa sulla possibilità di attivare e disattivare rapidamente specifiche funzionalità tramite un file di configurazione facilmente modificabile;
- Monitoring instrumentation: sono strumenti di monitoraggio passivo, ad esempio il log degli eventi di sistema, che consentono di monitorare il funzionamento dell’applicazione, sia da un punto di vista dell’erogazione/efficienza e sia da un punto di vista funzionale, ossia di cosa viene realmente utilizzato nell’applicazione;
- Feature toggles: è una pratica che contempla l’attivazione di un insieme di funzionalità in relazione a diversi scenari di utilizzo: si pensi alle soluzioni SaaS e ai diversi livelli di contratto annesso;
- Self-testing: questo approccio permette ad un’applicazione di auto-testarsi e segnalare il proprio stato. Ciò avviene attraverso la presenza di una serie di funzionalità minimali di test dispiegate con il prodotto: si immagini, come esempio,, ad un is-alive test che verifica periodicamente la disponibilità del servizio db;
- Self-recovery: si tratta arricchire il software con funzionalità che permettono di rispondere a situazioni di errore, tentando di ripristinare lo stato desiderato o di tamponare con soluzioni di ripiego. Si pensi, ad esempio, ad un App Mobile che effettua transazioni su un db: se la connessione e’ giù, l’App può utilizzare un local store per continuare ad operare e poi sincronizzare il tutto appena la connessione e’ nuovamente disponibile.
Prima di chiudere e’ importante evidenziare che l’ordine con cui vengono presentate le strategie non è casuale, ma rispecchia l’effort e la maturità richiesta in senso crescente. Questo fattore e’ essenziale perché ricordiamo che DA2 e’ un framework Goal Oriented, in cui per ogni goal vengono suggerite possibili strategie da adottare in relazione al proprio contesto e alla specifica maturità raggiunta.
Stay tuned!
