Sotto il nome di "Integrazione Continua" (Continuous Integration) si raccolgono metodologie e processi per che automatizzano l'integrazione di un progetto, ad ogni check-in o ad intervalli schedulati. La necessità alla base di questo processo è quella di minimizzare i problemi che si possono verificare in progetti gestiti da team di sviluppo numerosi, ma in generale i vantaggi che si ottengono sono così grandi che in pratica, una volta automatizzato il primo progetto, non se ne può più fare a meno.
Uno scenario tipico è quello in cui lo sviluppatore A effettua un update in locale del codice ed inizia ad applicare le sue modifiche. Quando A è pronto per inviare i suoi cambiamenti al repository, è possibile che altri sviluppatori abbiano modificato contemporaneamente altri file in modo non compatibile alle modifiche di A. Per evitare questo tipo di problema, ogni sviluppatore dovrebbe sempre fare un update prima di inviare le modifiche al server, in modo da verificare eventuali incompatibilità con il codice attualmente nella trunk.
Purtroppo talvolta questa regola viene dimenticata ed è quindi possibile che alcuni sviluppatori lavorino su una base di codice non corretta, destabilizzando cosi la trunk. L'esempio tipico è: lo sviluppatore A effettua un rename di una funzione con un tool di refactoring, lo sviluppatore B intanto ha scritto una parte di codice che utilizza la funzione rinominata ed effettua il check-in, A effettua anche lui il check-in senza controllare ed il codice non compila più.
Altri problemi si hanno quando gli sviluppatori non eseguono regolarmente gli unit test prima di effettuare il check-in; questo comportamento genera confusione, perché ad un certo punto ci si accorge che i test non vengono più eseguiti correttamente, ma i cambiamenti intercorsi dall'ultima esecuzione corretta sono così grandi, che capire la causa della regressione diventa impossibile.
La soluzione a questa tipologia di problemi è realizzare una macchina di integrazione continua, la quale, ad ogni checkin, lancia uno script di build sulla codebase più recente.
Questo processo permette di individuare subito le broken build, ovvero le build per cui il codice non compila, o alcuni test falliscono, o alcune metriche non sono rispettate, etc, evitando quindi il classico "integration hell", dove le modifiche dei vari team vengono integrate tutte in una volta, generando solitamente ore insonni alla ricerca dei problemi.
