Bei der fortlaufenden Integration versucht man, möglichst häufig seine lokalen Änderungen wieder in den gemeinsamen Quellcodebestand zu integrieren. Möglichst häufig bedeutet mehrfach am Tag. Eine Daumenregel heißt, dass mind. abends integriert werden muss. Hardcore-Integrierer werfen Code weg, den sie abends nicht mehr integrieren können - was um so weniger ins Gewicht fällt, je häufiger man integriert.
Fortlaufende Integration ist eng verbunden mit UnitTests. Nur wenn ausreichend viele Tests existieren, kann ständig integriert werden, ohne den gemeinsamen Codebestand zu korrumpieren. Vor jeder Integration sollten alle Tests zu 100% durchlaufen (TestVorCommit).
Es erfordert jedoch Disziplin vor jeder Integration alle UnitTests auszuführen. Daher existieren Werkzeuge, die vor oder nach der Integration den gemeinsamen Codebestand testen, sogenannte IntegrationsServer. In kleinen Teams kann auch ein IntegrationsToken helfen.
Im Terminus von CMM bedeutet fortlaufende Integration, dass eine "Rollende Baseline" existiert. Diese repräsentiert den aktuell integrierten Stand der Arbeitsergebnisse. Wird nicht kontinuierlich integriert, so muss der Integritätstest der Baseline in regelmäßigen Abständen erfolgen. Hier bietet sich die gleichzeitige Versionierung der Baseline an, da die Differenz zur letzten Rückfallebene sonst unüberschaubar groß wird. Bei kontinuierlicher Integration finden häufiger Integrationstests statt so dass die zur Aufhebung der Integrität führende Änderung zeitnah erkannt werden kann und eine Herstellung der Integrität ohne explizite Rückfallebene allein auf der Basis versionierter Teilergebnisse möglich ist.