Analizzare l'integrazione continua
L'integrazione continua è una delle otto funzionalità della tassonomia di DevOps.
Scopri perché l'integrazione continua è necessaria
Il 23 settembre 1999, il Mars Climate Orbiter ha riposto i pannelli solari per proteggerli da una discesa temporanea nell'atmosfera marziana.
Dopo essere entrato correttamente in orbita, il satellite avrebbe dovuto inoltrare le foto di Marte alla terra per diversi anni. Sfortunatamente, il velivolo è bruciato nell'atmosfera marziana.
Un bug nel software di controllo a terra, fornito da terze parti, ha calcolato il valore in un'unità del sistema imperiale, ossia in libbre per secondo. Il software creato dalla NASA prevedeva che il valore fosse espresso in un'unità del sistema metrico, ossia in newton per secondi. Poiché questi valori non sono stati convertiti correttamente, le piccole discrepanze nella posizione del velivolo si sono sommate nel corso di milioni di chilometri.
Il controllo di qualità non ha notato l'uso di un'unità del sistema imperiale nel software esterno, anche se gli standard di codifica della NASA al momento imponevano l'utilizzo delle unità del sistema metrico. Inoltre, i calcoli erano stati eseguiti manualmente anziché con il software fornito, a causa di errori del formato dei file e di bug vari. Questa situazione è un esempio della necessità dell'integrazione continua.
Esplorare l'integrazione continua
L'integrazione continua è una mentalità e una strategia del team. Inoltre, l'autore e relatore Martin Fowler afferma che l'integrazione continua è una procedura di sviluppo di software in cui i membri di un team integrano frequentemente il loro lavoro, in genere ogni persona esegue l'integrazione almeno una volta al giorno, il che porta a numerose integrazioni quotidiane.
Ogni integrazione viene verificata da una creazione automatizzata (incluso il test) per rilevare gli errori di integrazione nel minor tempo possibile.
Se eseguito in maniera corretta, questo approccio porta a meno problemi di integrazione perché questi vengono rilevati prima nel processo.
Gli obiettivi dell'integrazione continua sono:
- Sfruttare la collaborazione
- Abilitare lo sviluppo parallelo
- Ridurre al minimo il debito di integrazione
- Fungere da Quality Gate
- Automatizzare tutti gli elementi
Nota
Si noti come gli obiettivi dell'integrazione continua includano la collaborazione continua, il recapito continuo e la qualità continua.
Ma cosa accade quando non esiste un'integrazione continua? Una mancanza di lavoro di integrazione continua può spesso causare:
- Lunghi cicli di sviluppo
- Codice non di compilazione
- In qualsiasi momento, il codice sorgente potrebbe non essere funzionante
- Blocchi del codice
- Molti errori di compilazione/bug
- Rami di lunga durata, che causano attività di merge di più giorni
- Codice mancante dal controllo del codice sorgente
- Difetti di sicurezza trovati in ritardo nel ciclo di sviluppo
- Grande debito tecnico
- Numeri di code coverage bassi o inesistenti
- Qualità complessiva ridotta
- Comunicazione e collaborazione limitate
- Codice che non rispetta gli standard di codifica
- Revisioni del codice scarse o inesistenti
- Test tardivi nel ciclo di sviluppo
- In molti casi manuali, se esistenti
I punti di integrazione sono il ciclo di feedback rapido usato per migliorare il sistema. Quando la tempistica dei punti di integrazione salta, il progetto è in pericolo. Ecco che cosa ne dice Dantar Oosterwal nel libro The Lean Machine:
Lo svantaggio dei punti di integrazione è che controllano lo sviluppo del prodotto. Sono i punti di leva per migliorare il sistema. Quando la tempistica dei punti di integrazione salta, il progetto è in pericolo.
Dantar Oosterwal, The Lean Machine
© Scaled Agile, Inc.
Se ci si chiede se il team stia effettivamente eseguendo l'integrazione continua, queste domande possono essere utili per stabilire la risposta.
- Tutti gli sviluppatori eseguono lo sviluppo basato su trunk?
- Ogni modifica apportata a un trunk avvia un processo di compilazione?
- Quando la compilazione e il test non riescono, il team corregge la versione entro pochi minuti?
Anche le prestazioni vengono influenzate dalla presenza o dall'assenza dell'integrazione continua. I dati raccolti e analizzati per il libro The Science Of DevOps - Accelerate - Building and scaling high performing technology organizations di Nicole Forsgren, Jez Humble e Gene Kim mostrano che quando la velocità di immissione sul mercato delle organizzazioni con basse prestazioni aumenta, la loro qualità diminuisce.
Ma le organizzazioni con prestazioni elevate riescono a mantenere la qualità aumentando al contempo la velocità di immissione sul mercato. Hanno cicli di distribuzione più brevi (e meno complessi) e usano l'integrazione continua per correggere immediatamente i problemi, aumentando il flusso e l'efficienza.
| 2017 | Organizzazioni con prestazioni elevate | Organizzazioni con prestazioni medie | Organizzazioni con prestazioni basse |
|---|---|---|---|
| Frequenza di distribuzione | Più distribuzioni al giorno | 1 settimana - 1 mese | 1 settimana - 1 mese |
| Lead time per la modifica | < 1 ora | 1 settimana - 1 mese | 1 settimana - 1 mese |
| Tempo medio di ripristino | < 1 ora | < 1 giorno | 1 giorno - 1 settimana |
| Percentuale di errori di modifica | 0-15% | 0-15% | 31-45% |