integrazione continuasviluppo, test e rilascio per non addetti ai lavori

il problema: integration hell

L'obiettivo principale della CI è quello di evitare il cosiddetto

integration hell

ossia il caso limite in cui ciascun membro del team si trova ad integrare il proprio lavoro con quello altrui solamente a sviluppo completato

il tunnel (senza uscita ?)

come possiamo pretendere, allora, di stimare un tempo di integrazione a fine progetto, quando non abbiamo nemmeno una predizione a livello locale dei problemi emersi ?

siamo finiti nel tunnel: la scadenza è sempre più vicina

lo sviluppo è terminato e non abbiamo idea di quando il software sarà correttamente funzionante anche se tecnicamente “è finito”

"Il software funzionante accompagnato da una documentazione completa"

Insieme, questi principi creano una solida base per il processo di integrazione continua (Continuous integration) del software.

Due dei quattro principi chiave dello sviluppo agile del software sono

“Rispondere al cambiamento seguendo un piano"

È il momento di dire addio alle pianificazioni “waterfall” (a cascata) rappresentate con favolosi diagrammi di Gantt o enormi fogli di calcolo

uscire dal tunnel: integrazione continua

il concetto chiave è infatti quello di spostare il momento dell'integrazione: non più alla fine del processo di sviluppo, ma inserirlo all'interno di esso.

il processo di rilascio deve essere affidabile e coerente e il successo dipende molto dalla squadra di persone che collaborano per la sopravvivenza del prodotto.

effettuare piccoli cambiamenti di codice ed integrarli subito significa dover correggere al più bug recenti e non interi moduli software, con il risultato di avere in qualsiasi momento un software già integrato.

come lavoriamo

Nella fase di pianificazione, tipicamenteun processo di rilascio è costituito da: 30 issue per sprint, 12 epic nel backlog e 10/12 major contributors per release.

mantenere la rotta (... come lavoriamo)

gli sprint durano in media 10 giorni e al termine circa il 73% delle issue (ticket) risulta completato

integrazione continua = “controllo continuo”

“Non inviare codice difettoso e non scaricarlo !”

integrazione continua significa anche necessariamente controllo continuo sul processo

se la una build privata non è funzionante, il codice difettoso non va assolutamente inviato al repository

uno degli scopi principali della CI è quellodi avere sempre disponibile un software funzionante e rilasciabile in produzione

pro e contro

la Continuous Integration è innanzitutto una pratica

e non il semplice utilizzo di strumenti

è quindi necessario accettare un’inevitabile curva di apprendimento

tanto più ripida quanto più le competenze del team sono lontane dai concetti appena illustrati.