Di seguito una spiegazione di come sono state estratte le nuove metriche e un breve commento sui nuovi valori. Nella tabella 6.1 un sommario dell’impatto dell’adozione di architettura microservizi e pratiche DevOps rispetto all’applicazione originale.
Metrica Unità Prec. Oggi Cambiamento
Frequenza di rilascio rilasci/giorno 0.071 2.7 +3700% Durata ciclo di rilascio ore 8/24 0.19 -97.6%/-99.2%
Commits per giorno commit/giorno 2 7.1 +255%
Tempo medio di recupero (MTTR) ore 36 0.5 -98.6% Tickets di supporto aperti tickets/mese 40 19 -52.5%
Tempo risoluzione problematiche giorni 4 3 -25%
Interruzione di servizio minuti/notte 30 0 -100% Preparazione ambiente di sviluppo minuti 120 9 -92.5% Creazione ambiente di produzione ore 16 0.35 -97.8% Tabella 6.1: Sommario delle metriche considerate per valutare l’impatto dell’azione dell’approccio DevOps su un’architettura a microservizi.
Frequenza dei rilasci in produzione
• Valore originale: 0,071 rilasci al giorno (1 volta ogni 14 giorni) • Valore attuale: 2,7 rilasci al giorno
• Fonte: dato misurato da frequenza pipeline CI/CD ramo master
L’operazione, oltre a essere promossa dalla pratica DevOps di integrazione continua, ora è totalmente automatizzata. A differenza del modello originale dove l’operazione di rilascio allocava uno sviluppatore per un’intera giornata, ora quest’ultimo può dedicarsi ad altro mentre il sistema procede in automatico. Inoltre nel modello a microservizi i rilasci impattano solo quelli che sono effettivamente cambiati, limitando così l’impatto di gestione sull’intero ciclo di rilascio.
Durata ciclo di rilascio
• Valore medio: 1 giorno
• Valore attuale: circa 11 minuti
• Fonte: dato ricavato dalla durata media delle pipeline su branch master
Si passa da un modello manuale con scambio di artefatti effettuato tramite email a un sistema di rilasci totalmente automatico che non prevede interazione umana.
Tempo di sviluppo di un’idea
• Valore originale: 14 giorni • Valore attuale: 3,7 giorni
• Fonte: Gitlab Merge Request Analytics (da feature branch a dev)
Seppur le abilità individuali dei membri del team rimangano costanti, questo dato si può giustificare rispetto due pratiche introdotte con l’approccio DevOps: (i) effettuare CI riduce notevolmente i costi di integrazione rispetto all’integrazione totale a fine sviluppo funzionalità; (ii) i controlli di qualità sono effettuati automaticamente durante tutta la fase di sviluppo (durante CI) e nel caso di creazione di ambiente feature review un addetto al controllo della qualità può seguire gli sviluppi e dare feedback costante agli sviluppatori (in contrapposizione al modello originale dove a fine sviluppo veniva richiesto ai sistemisti di installare tali modifiche in ambiente stage).
Numero di commit al giorno
• Valore originale: 2 • Valore attuale: 7.1
• Fonte: Gitlab analytics (branch develop)
DevOps promuove l’integrazione continua del lavoro di tutto gli sviluppatori. Nel modello originale il sistema di versionamento non aveva supporto al tracciamento delle problema- tiche e alcuna automazione: gli sviluppatori lo utilizzavano come sistema di backup del codice e pertanto usavano effettuare commit a fine giornata.
Tempo medio di recupero (MTTR)
• Valore originale: 1,5 giorni • Valore attuale: circa 30 minuti • Fonte: dato misurato
In uno scenario di rilascio su ambiente Cloud, come quello del nuovo sistema redazionale, il motivo più probabile di guasto grave è dovuto a corruzione dovuta a bug nel software, piuttosto che fallimento critico dell’hardware (es: migrazione del database fallita). Di conseguenza viene naturale ricorrere a funzionalità di ripristino temporale offerti dagli stessi servizi cloud (es: ripristinare il database alle 9:30 di questa mattina). Anche sce- nari più disastrosi che prevedono la rigenerazione totale di un ambiente produzione si risolvono con operazioni per lo più automatiche (vedi metriche Tempo per la creazione di
un ambiente di produzione e Tempo di Rilascio).
Tasso di fuga degli errori
• Valore originale: al 50% dei rilasci succede almeno una commit di hotfix • Valore attuale: 10% dei rilasci succede almeno una commit di hotfix • Fonte: Analisi su branch denominate "hotfix-"
Rispetto alla metodologia originale, ai controlli di qualità manuali svolti sull’ambiente di test, si affiancano livelli di controllo automatici che intercettano la maggior parte degli errori: unit test, analisi statica del codice e analisi delle vulnerabilità dei container e test e2e sull’intera applicazione.
Numero di issue/ticket aperti
• Valore originale: 40 issue al mese • Valore attuale: 19 issue al mese • Fonte: Gitlab Issue Analytics
Il valore attuale risulta dimezzato. Un fattore chiave che giustifica questo dato, oltre ai diversi controlli di qualità introdotti nel ciclo di sviluppo, è l’introduzione di un sistema di monitoraggio che ci permette di essere proattivi rispetto alle anomalie rilevate sull’am- biente di produzione. Questo permette di risolvere eventuali problemi ancor prima che l’utente possa rilevarli ed aprire un ticket.
Tempo di risoluzione delle problematiche
• Valore originale: 4 giorni • Valore attuale: 3 giorni
• Fonte: dato misurato su portale Gitlab
Il valore rimane pressoché lo stesso. La spiegazione è data dal fatto che questa metrica cattura l’abilità del team di risolvere problematiche legate al codice. Questa abilità, seppur influenzabile da strumenti che migliorano la qualità di sviluppo dell’applicazione, rimane legata alle singole capacità degli sviluppatori del gruppo di sviluppo.
Tempo di inattività del sistema
• Valore originale: circa 30 minuti ogni notte • Valore attuale: nessuno
• Fonte: dato misurato
Nella nuova implementazione il sistema non ha momenti di interruzione pianificati. Gli aggiornamenti vengono eseguito a caldo e tramite tecnica di rolling update non c’è mai interruzione di servizio.
Tempo impiegato configurazione ambiente sviluppo
• Valore originale: 2 ore
• Valore attuale: circa 9 minuti
• Fonte: dato misurato da esecuzione docker-compose up
Per avere un ambiente di sviluppo i passi da effettuare sono due: git clone del repository e docker-compose up. Misuriamo il docker-compose up di una macchina che non ha in cache nessuna immagine pre-esistente. NB: il dato è influenzato dalla velocità di download.
Tempo per la creazione di un ambiente di produzione
• Valore originale: 2 giorni • Valore attuale: circa 21 minuti
• Fonte: dato ricavato da durata pipeline su ambiente review
Si misura la creazione dell’ambiente dinamico tramite pipeline di review, che include crea- zione infrastruttura tramite terraform, rilascio dell’intero stack applicativo e validazione del sistema tramite test e2e.