Integrazione Continua

L'Integrazione Continua è ampiamente fraintesa. Non è solo un server di build. Non è solo eseguire test ad ogni commit. Questi sono strumenti che supportano la CI—ma la CI stessa è una pratica.

La vera CI significa:

• Tutti fanno commit sul branch principale (o trunk) almeno una volta al giorno
• Ogni commit attiva una build e l'esecuzione dei test
• Se la build si rompe, risolverla è la massima priorità
• Il branch principale è sempre in uno stato deployabile

La parte "continua" è fondamentale. Se integri settimanalmente, non è continuo. Se hai branch di funzionalità di lunga durata, non è continuo. CI significa integrare il tuo lavoro con quello di tutti gli altri ogni giorno, di solito più volte al giorno.

La vera CI richiede lo sviluppo basato sul trunk: tutti fanno commit sul branch principale (spesso chiamato "trunk" o "main").

Sembra spaventoso. Le persone non romperanno le cose? È qui che entra in gioco la disciplina:

• Esegui i test prima di fare commit (non rompere la build)
• Fai commit di piccole modifiche (più facili da integrare, più facili da correggere)
• Correggi immediatamente le build rotte (tutti si fermano finché non è verde)
• Usa feature flag per funzionalità incomplete (così possono essere unite ma non attivate)

I branch di lunga durata sono il nemico della CI. Quando sviluppi su un branch per settimane, non stai integrando. Stai solo posticipando l'integrazione—e più aspetti, più diventa difficile.

Branch per ore, non per giorni. Integra quotidianamente, non settimanalmente.

Perché la CI funzioni, il ciclo di build e test deve essere veloce. Martin Fowler suggerisce la regola dei 10 minuti: l'intera build, inclusi tutti i test, dovrebbe completarsi in meno di 10 minuti.

Perché 10 minuti? Perché:

• Gli sviluppatori hanno bisogno di feedback rapido sulle loro modifiche
• Aspettare un'ora per sapere se hai rotto qualcosa è troppo lento
• Le build lunghe incoraggiano gli sviluppatori a saltare l'esecuzione dei test localmente

Se la tua build richiede troppo tempo:

• Parallelizza i test
• Usa hardware più veloce
• Ottimizza i test più lenti
• Considera la categorizzazione dei test (test unitari veloci vs test di integrazione lenti)
• Rivedi il design dei test (troppo database? troppa rete?)

Alcuni team eseguono un sottoinsieme veloce localmente (test unitari) e la suite completa sul server CI. Va bene purché la suite completa venga eseguita abbastanza velocemente da fornire feedback tempestivo.

La build si romperà. Ciò che conta è cosa succede dopo.

La regola: Quando la build si rompe, risolverla diventa la massima priorità. Tutto il resto si ferma.

Questo può sembrare estremo, ma considera: una build rotta significa che il team non può fidarsi del branch principale. Il lavoro di tutti è bloccato perché non possono integrare in sicurezza. Ogni minuto in cui la build è rotta è un minuto di rischio accumulato.

Chi la risolve? Di solito la persona che l'ha rotta. Ma se è bloccata, altri aiutano. Una build rotta è un problema del team, non un problema individuale.

Come prevenire le rotture:

• Esegui i test localmente prima di fare commit
• Mantieni le modifiche piccole (modifiche più piccole = rischio minore)
• Presta attenzione alle notifiche CI (risolvi velocemente)
• Non fare commit e andartene per la giornata

Alcuni team usano una rotazione "sceriffo CI"—qualcuno responsabile di monitorare la build e coordinare le correzioni. Questo previene l'effetto spettatore dove tutti presumono che qualcun altro la risolverà.

La CI è la base per pratiche più avanzate:

Continuous Delivery (CD): Ogni commit può essere deployato in produzione. Il deployment è una decisione di business, non tecnica.

Continuous Deployment: Ogni commit che supera i test viene automaticamente deployato in produzione. Nessuna approvazione umana richiesta.

Non ogni team ha bisogno del continuous deployment. Ma ogni team beneficia della CI. Inizia da lì.

Metriche CI da monitorare:

• Tempo di build (dovrebbe essere sotto i 10 minuti)
• Frequenza di build (dovrebbe essere più volte al giorno per sviluppatore)
• Tempo medio per correggere build rotte (dovrebbe essere minuti, non ore)
• Copertura dei test (non una metrica perfetta, ma un segnale)

La CI non riguarda solo il rilevamento di bug. Riguarda la creazione di un ritmo dove l'integrazione è noiosa, routinaria e sicura. Quando l'integrazione è sicura, tutto il resto diventa più facile.