Integrazione continua - Requisiti
Di seguito è riportato l'elenco dei requisiti più significativi per l'integrazione continua.
Check-In Regularly- La pratica più importante per il corretto funzionamento dell'integrazione continua è costituita da frequenti check-in nel trunk o nella linea principale del repository del codice sorgente. Il check-in del codice dovrebbe avvenire almeno un paio di volte al giorno. Fare regolarmente il check-in porta molti altri vantaggi. Rende le modifiche più piccole e quindi meno probabilità di rompere la build. Significa che la versione più recente del software a cui ripristinare è nota quando viene commesso un errore in una build successiva.
Aiuta anche ad essere più disciplinato nel refactoring del codice e ad attenersi a piccoli cambiamenti che preservano il comportamento. Aiuta a garantire che le modifiche che alterano molti file abbiano meno probabilità di entrare in conflitto con il lavoro di altre persone. Consente agli sviluppatori di essere più esplorativi, provando idee e scartandole tornando all'ultima versione impegnata.
Create a Comprehensive Automated Test Suite- Se non si dispone di una suite completa di test automatizzati, una build passata significa solo che l'applicazione può essere compilata e assemblata. Sebbene per alcuni team questo sia un grande passo, è essenziale disporre di un certo livello di test automatizzati per garantire che la tua applicazione funzioni effettivamente.
Normalmente, ci sono 3 tipi di test condotti in Continuous Integration, vale a dire unit tests, component tests, e acceptance tests.
Gli unit test vengono scritti per testare il comportamento di piccole parti dell'applicazione in isolamento. Di solito possono essere eseguiti senza avviare l'intera applicazione. Non raggiungono il database (se la tua applicazione ne ha uno), il filesystem o la rete. Non richiedono che l'applicazione venga eseguita in un ambiente simile alla produzione. I test unitari dovrebbero essere eseguiti molto velocemente: l'intera suite, anche per un'applicazione di grandi dimensioni, dovrebbe essere in grado di funzionare in meno di dieci minuti.
I test dei componenti verificano il comportamento di diversi componenti dell'applicazione. Come gli unit test, non richiedono sempre l'avvio dell'intera applicazione. Tuttavia, possono colpire il database, il filesystem o altri sistemi (che potrebbero essere bloccati). I test dei componenti in genere richiedono più tempo per essere eseguiti.
Keep the Build and Test Process Short - Se la compilazione del codice e l'esecuzione degli unit test impiegano troppo tempo, si verificheranno i seguenti problemi.
Le persone smetteranno di eseguire una compilazione completa ed eseguiranno i test prima del check-in. Inizierai a ottenere più build fallimentari.
Il processo di integrazione continua richiederà così tanto tempo che sarebbero stati eseguiti più commit nel momento in cui sarà possibile eseguire nuovamente la build, quindi non saprai quale check-in ha interrotto la build.
Le persone effettueranno il check-in meno spesso perché devono sedersi per anni in attesa che il software venga creato e che i test vengano eseguiti.
Don’t Check-In on a Broken Build- Il più grande errore dell'integrazione continua è il check-in su una build non funzionante. Se la build si interrompe, gli sviluppatori responsabili stanno aspettando di risolverlo. Identificano la causa della rottura il prima possibile e la risolvono. Se adottiamo questa strategia, saremo sempre nella posizione migliore per capire cosa ha causato la rottura e ripararla immediatamente.
Se uno dei nostri colleghi ha effettuato un check-in e di conseguenza ha rotto la build, per avere le migliori possibilità di risolverlo, avrà bisogno di una chiara analisi del problema. Quando questa regola viene infranta, inevitabilmente ci vuole molto più tempo per correggere la build. Le persone si abituano a vedere la build danneggiata e molto rapidamente ti trovi in una situazione in cui la build rimane sempre danneggiata.
Always Run All Commit Tests Locally Before Committing- Assicurarsi sempre che i test progettati per l'applicazione vengano eseguiti prima su una macchina locale prima di eseguirli sul server CI. Questo per garantire che vengano scritti i casi di test corretti e se si verifica un errore nel processo CI, è a causa dei risultati del test non riusciti.
Take Responsibility for All Breakages that Result from Your Changes- Se si esegue il commit di una modifica e tutti i test scritti vengono superati, ma altri si interrompono, la build è comunque danneggiata. Di solito questo significa che hai introdotto un bug di regressione nell'applicazione. È tua responsabilità, poiché hai apportato la modifica, correggere tutti i test che non vengono superati a seguito delle modifiche. Nel contesto della CI questo sembra ovvio, ma in realtà non è una pratica comune in molti progetti.