Promuovere l'eccellenza DevOps: come sfruttare le metriche DORA per ottenere risultati migliori

Informazioni sul nostro prodotto e modello di consegna

Panoramica del prodotto/progetto

Freya Fusion è una piattaforma di tecnologia normativa avanzata che sfrutta l'intelligenza artificiale e soluzioni Cloud-based per semplificare i processi di conformità. Le sue caratteristiche principali includono un Regulatory Cloud basato sull'intelligenza artificiale per una supervisione intelligente, componibilità tra dati, contenuti, applicazioni e interfacce utente per una maggiore flessibilità e processi normativi allineati con una pianificazione interfunzionale. La piattaforma offre anche soluzioni di automazione integrate, un Knowledge Graph per approfondimenti strutturati e un' interfaccia utente conversazionale per migliorare l'interazione con l'utente. Progettato per garantire l'efficienza, Freya Fusion combina tecnologia all'avanguardia ed esperienza normativa per semplificare i flussi di lavoro di conformità complessi.

Processo attuale ed ecosistema di consegna

Metodologia Agile e strumenti

In Freya Fusion sfruttiamo la metodologia Agile integrata con pratiche DevSecOps per garantire sicurezza, conformità ed efficienza dal codice al rilascio. Nel nostro framework Agile, le funzionalità fungono da elementi di lavoro di rilascio principali. Più funzionalità vengono raggruppate e validate insieme per formare un candidato al rilascio (RC), garantendo una fornitura di valore incrementale e controllata.

Azure DevOps (ADO) e integrazioni di plugin

Panoramica della pipeline CI/CD

Le pipeline di integrazione continua e distribuzione continua (CI/CD) automatizzano il processo di consegna del software dallo sviluppo alla produzione, garantendo rilasci più rapidi, qualità costante e riduzione degli errori manuali.

Integrazione continua (CI) – La fase di compilazione e test utilizzata dal team Sprint

• Code Commit: gli sviluppatori caricano le modifiche in un archivio condiviso (ad esempio, Azure Repos, GitHub).
• Compilazione automatica: la pipeline compila il codice, risolve le dipendenze e crea i pacchetti degli elementi.
• Test automatici: vengono eseguiti test di unità, test di integrazione e scansioni di sicurezza (SAST/DAST) per individuare tempestivamente i problemi.
• Archiviazione degli elementi: le versioni validate vengono memorizzate negli archivi

Distribuzione continua (CD) – La fase di rilascio utilizzata dal team di distribuzione

• Ambienti di staging: il codice passa attraverso DevSecOps → SQA → PreProd → Produzione con controlli di approvazione.
• Distribuzioni automatiche: la distribuzione avviene tramite pipeline di rilascio con tempi di inattività minimi
• Controlli post-distribuzione: test di fumo automatici, monitoraggio delle prestazioni e meccanismi di rollback in essere regolati dalle SOP.

Tipi di rilascio: Principale, Minore, Patch, Hotfix

I rilasci sono classificati in principale, minore, patch o hotfix a seconda dell'intento e delle funzionalità rilasciate in quella versione.

• Principale – Indica il rilascio iniziale o un rilascio in cui le funzionalità incidono sulla funzionalità senza retrocompatibilità
• Minore – Indica il rilascio di nuove funzionalità con retrocompatibilità e miglioramenti o ottimizzazioni delle funzioni esistenti
• Patch – Indica il rilascio di correzioni di bug raggruppate, aggiornamenti di sicurezza e piccoli miglioramenti con retrocompatibilità
• Hotfix – Indica un rilascio di emergenza per risolvere problemi critici segnalati in produzione nella versione distribuita.

Le metriche chiave che contano

Spiegazione delle quattro metriche DORA:

In base agli standard del settore, vi sono 4 metriche chiave che devono essere monitorate e ottimizzate per il successo delle organizzazioni.

1. Lead Time (la rapidità con cui rilasciamo il software in produzione)
2. Frequenza di distribuzione (la frequenza con cui si effettuano i rilasci).
3. Tasso di errore delle modifiche (la frequenza con cui le distribuzioni falliscono).
4. Tempo medio di ripristino (MTTR) (la rapidità con cui si risolvono i guasti).

Lead Time è una delle quattro metriche chiave di DevOps Research and Assessment (DORA). Misura il tempo necessario affinché le modifiche al codice passino dal commit alla distribuzione in produzione, riflettendo l'efficienza del processo di rilascio del software. Questa metrica indica la durata media intercorrente tra il momento in cui una modifica al codice viene effettuata e quello in cui viene distribuita con successo in produzione.

Il Lead Time indica:

• velocità di consegna ed efficienza dei processi.
• Tempi di consegna più brevi sono correlati a cicli di feedback più rapidi e maggiore agilità.

Frequenza di rilascio traccia la frequenza con cui le modifiche al codice vengono distribuite con successo in produzione. Riflette la velocità e la coerenza del tuo rilascio software

La frequenza di rilascio indica:

• Agilità del team e maturità del processo.
• Rilasci frequenti riducono il rischio consentendo modifiche più piccole e incrementali (rispetto a rilasci grandi e rari).
• È correlato a cicli di feedback più rapidi e maggiore soddisfazione del cliente.

Tempo medio di recupero (MTTR) misura il tempo medio necessario per ripristinare il servizio dopo un guasto (ad esempio, interruzione, calo delle prestazioni o bug). Riflette la resilienza del tuo team e l'efficienza nella gestione degli incidenti.

L'MTTR indica:

• Riduce al minimo i tempi di inattività e l'impatto sugli utenti.
• Un MTTR elevato indica debugging lento, monitoraggio inadeguato o processi di rollback inefficienti.
• È correlato a fiducia dei clienti, costi operativi e stress del team.

Tasso di fallimento delle modifiche (CFR) misura la percentuale di rilasci che causano guasti in produzione, richiedendo interventi correttivi (ad esempio, rollback, hotfix o patch). Riflette la stabilità e affidabilità del tuo processo di rilascio.

Il CFR indica:

• Indica quanto spesso i rilasci introducono difetti (bug, interruzioni, problemi di prestazioni).
• Un CFR elevato suggerisce test scarsi, monitoraggio inadeguato o pratiche di rilascio rischiose.
• È correlato a stress del team, fiducia dei clienti e costi operativi.

Ulteriori metriche di supporto:

1. Work in Progress (WIP): misura il numero di attività non completate (ad esempio modifiche di codice, funzionalità, bug) attualmente presenti nella pipeline. Questa metrica aiuta a valutare i colli di bottiglia e la necessità di suddividere la funzionalità o la user story
2. Cycle Time: tempo impiegato dall' inizio del lavoro (ad esempio la creazione del ticket) fino al completamento
3. Numero di Pull Request: metrica che traccia il numero di PR create, unite o rifiutate in un determinato periodo di tempo (giornaliero, settimanale o mensile). Aiuta i team a valutare la produttività degli sviluppatori, l'efficienza della collaborazione e i colli di bottiglia nel flusso di lavoro.
4. Incidenti segnalati dai clienti: numero di problemi in produzione segnalati dai clienti che indicano la qualità dei test interni
5. Bug aperti: questa metrica tiene traccia del numero di difetti irrisolti (bug) presenti nel sistema in un dato momento. Aiuta a misurare la qualità del software, il debito tecnico e l' efficienza del team nella gestione dei problemi.
6. Bug aperti di lunga data: i bug aperti di lunga data sono difetti che rimangono irrisolti per un periodo prolungato (solitamente 30 o più giorni). Il loro monitoraggio aiuta a identificare inefficienze nei processi, lacune nella definizione delle priorità e debito tecnico
7. Bug rimandati: si tratta di difetti che sono stati riconosciuti ma intenzionalmente posticipati per una risoluzione successiva. Sebbene il rinvio possa essere una strategia legittima, un eccesso di bug rimandati può indicare l'accumulo di debito tecnico, problemi di definizione delle priorità o inefficienze nei processi.
8. Stato della build CI: questa metrica monitora la stabilità e l'affidabilità della pipeline di Integrazione Continua (CI) tracciando il tasso di successo/fallimento di build e test automatizzati. Un sistema CI efficiente è fondamentale per ricevere feedback rapidi, rilasciare prodotti di alta qualità e garantire la produttività degli sviluppatori
9. Stato della release CD: questa metrica monitora la stabilità, la velocità e il tasso di successo della distribuzione automatizzata. Un sistema CD efficiente garantisce rilasci affidabili, frequenti e a basso rischio.
10. Test di integrazione: i test di integrazione verificano che moduli, servizi o sistemi sviluppati indipendentemente funzionino correttamente quando vengono combinati. Rappresentano una fase fondamentale in DevOps per individuare i problemi prima che arrivino in produzione.
11. Suite di monitoraggio della produzione: insieme di strumenti e pratiche per verificare lo stato del sistema, rilevare anomalie e risolvere i problemi in tempo reale per le applicazioni in produzione. È fondamentale per i team SRE, DevOps e Operations mantenere la disponibilità, le prestazioni e la soddisfazione degli utenti.

Perché le metriche sono importanti in un'organizzazione di successo

Il monitoraggio delle metriche DevOps e operative (come DORA, Lead Time, frequenza dei rilasci, MTTR, CFR, avvisi di monitoraggio e così via) fornisce informazioni utili che favoriscono il successo aziendale, l'eccellenza tecnica e il vantaggio competitivo.

1. Velocizza l'ingresso sul mercato
   • Metriche: Lead Time, frequenza dei rilasci, Cycle Time
   • Impatto:
     • Rilasci più rapidi → maggiore rapidità di risposta alle richieste del mercato.
     • Cicli di feedback più brevi → maggiore velocità di innovazione rispetto ai concorrenti.
2. Migliora la qualità e l'affidabilità del software
   • Metriche: Tasso di errore delle modifiche (CFR), tempo medio di ripristino (MTTR), bug aperti
   • Impatto:
     • Minori errori di produzione → Maggiore soddisfazione del cliente.
     • Risoluzione degli incidenti più rapida → Minimizzazione delle perdite di fatturato
3. Riduci costi e sprechi
   • Metriche: Stato di compilazione CI, errori nei test di integrazione, test instabili
   • Impatto:
     • Rilevamento precoce dei bug → Meno costoso da correggere nello sviluppo rispetto alla produzione
     • Processi efficienti → Risparmio sui costi cloud e di calcolo
4. Migliora la produttività e il morale del team
   • Metriche: Tempo del ciclo delle PR, limiti WIP, tasso di successo dei rilasci
   • Impatto:
     • Meno colli di bottiglia → Gli sviluppatori dedicano più tempo alla scrittura del codice e meno all'attesa.
     • Controlli automatizzati → Riduzione dello stress dovuto al lavoro manuale.
5. Allinea DevOps e obiettivi aziendali
   • Metriche: Consegna di unità vendibili, tasso di incidenti con i clienti, impegni di operatività
   • Impatto:
     • Collega l'attività di ingegneria a fatturato, crescita degli utenti e fidelizzazione.
6. Processo decisionale basato sui dati
   • Metriche: Tendenze di MTTR, invecchiamento dei bug, frequenza di rilascio
   • Impatto:
     • Dai priorità a miglioramenti ad alto impatto
     • Giustifica gli investimenti in automazione, formazione o strumenti con prove del ROI.

Riepilogo:

Mediante l'automazione del monitoraggio e dell'ottimizzazione di queste metriche chiave, le organizzazioni possono ottenere vantaggi significativi, tra cui:

• Decisioni basate sui dati – Sfrutta approfondimenti attuabili per guidare la strategia e gli investimenti.
• Eccellenza ingegneristica – Promuovi il miglioramento continuo nelle pratiche di sviluppo e operative.
• Competitività di settore – Allinea la tua attività ai parametri di riferimento migliori della categoria (o superali).
• Successo del cliente – Offri soluzioni affidabili e di alta qualità che soddisfano le aspettative degli utenti.
• Governance e leadership – Garantisci trasparenza e responsabilità a tutti i livelli.

Questo approccio strutturato garantisce processi più intelligenti, prestazioni superiori e una crescita aziendale sostenuta.

Riferimenti

• Accelerate di Forsgren, Humble & Kim
• Documentazione di Azure DevOps
• Report DevOps Research and Assessment (DORA)