Integrazione continua - Panoramica
L'integrazione continua è stata introdotta per la prima volta nel 2000 con il software noto come Cruise Control. Nel corso degli anni, l'integrazione continua è diventata una pratica chiave in qualsiasi organizzazione di software. Questa è una pratica di sviluppo che richiede ai team di sviluppo di garantire che una build e il successivo test siano condotti per ogni modifica di codice apportata a un programma software. Questo concetto aveva lo scopo di rimuovere il problema di trovare le occorrenze tardive dei problemi nel ciclo di vita della build. Invece degli sviluppatori che lavorano in isolamento e non si integrano abbastanza, è stata introdotta l'integrazione continua per garantire che le modifiche al codice e le build non fossero mai eseguite in modo isolato.
Perché l'integrazione continua?
L'integrazione continua è diventata una parte integrante di qualsiasi processo di sviluppo software. Il processo di integrazione continua aiuta a rispondere alle seguenti domande per il team di sviluppo software.
Tutti i componenti software funzionano insieme come dovrebbero? - A volte i sistemi possono diventare così complessi che ci sono più interfacce per ogni componente. In questi casi, è sempre fondamentale garantire che tutti i componenti software funzionino perfettamente l'uno con l'altro.
Il codice è troppo complesso per scopi di integrazione? - Se il processo di integrazione continua continua a fallire, potrebbe esserci la possibilità che il codice sia troppo complesso. E questo potrebbe essere un segnale per applicare modelli di progettazione adeguati per rendere il codice meno complesso e più gestibile.
Il codice è conforme agli standard di codifica stabiliti? - La maggior parte dei casi di test verificherà sempre che il codice aderisca agli standard di codifica appropriati. Eseguendo un test automatico dopo la compilazione automatica, questo è un buon punto per verificare se il codice soddisfa tutti gli standard di codifica desiderati.
Quanto codice è coperto dai test automatici? - Non ha senso testare il codice se i casi di test non coprono la funzionalità richiesta del codice. Quindi è sempre una buona pratica assicurarsi che i casi di test scritti coprano tutti gli scenari chiave dell'applicazione.
Tutti i test hanno avuto esito positivo dopo l'ultima modifica? - Se un test fallisce, non ha senso procedere con la distribuzione del codice, quindi questo è un buon punto per verificare se il codice è pronto per passare alla fase di distribuzione o meno.
Flusso di lavoro
L'immagine seguente mostra un rapido flusso di lavoro del funzionamento dell'intero flusso di lavoro di integrazione continua in qualsiasi progetto di sviluppo software. Lo esamineremo in dettaglio nei capitoli successivi.
Quindi, in base al flusso di lavoro di cui sopra, questo è generalmente il modo in cui funziona il processo di integrazione continua.
Innanzitutto, uno sviluppatore salva il codice nel repository di controllo della versione. Nel frattempo, il server Continuous Integration sulla macchina di compilazione dell'integrazione esegue il polling del repository del codice sorgente per le modifiche (ad esempio, ogni pochi minuti).
Subito dopo il commit, il server Continuous Integration rileva che sono state apportate modifiche nel repository di controllo della versione, quindi il server Continuous Integration recupera l'ultima copia del codice dal repository e quindi esegue uno script di build, che integra il software
Il server Continuous Integration genera feedback inviando tramite posta elettronica i risultati della compilazione ai membri del progetto specificati.
Gli unit test vengono quindi eseguiti se la compilazione di quel progetto viene superata. Se i test hanno esito positivo, il codice è pronto per essere distribuito sul server di staging o di produzione.
Il server Continuous Integration continua a eseguire il polling delle modifiche nel repository di controllo della versione e l'intero processo si ripete.