Continuous Integration (CI) ist die Praxis, Codeänderungen sehr häufig — idealerweise mehrfach täglich pro Entwickler — in einen gemeinsamen Hauptbranch zu integrieren und jeden Integrations-Schritt durch automatisierte Builds und Tests abzusichern. Das Ziel ist, Integrationsprobleme so früh wie möglich sichtbar zu machen und langlebige, divergierende Feature-Branches zu vermeiden, die später in einem schmerzhaften "Merge-Hell"-Schritt zusammengeführt werden müssten.
Eingesetzt wird CI in Form von Pipelines, die bei jedem Push oder Pull Request automatisch laufen: Sie kompilieren den Code, führen Unit- und Integrationstests aus, statische Analysen (Linter, Formatter, SAST-Werkzeuge), Lizenz- und Vulnerability-Scans und veröffentlichen Build-Artefakte in einem Repository. Übliche Plattformen sind GitHub Actions, GitLab CI/CD, Azure Pipelines, Jenkins, TeamCity und CircleCI. CI-fähige Repositories nutzen Branch-Schutzregeln, die einen Merge erst zulassen, wenn alle Pipeline-Schritte grün sind.
Im Kern geht es um die Reduktion des Integrationsrisikos. Klassische, branch-basierte Workflows mit langlebigen Feature-Branches verstecken Konflikte und Inkompatibilitäten, die erst beim späten Merge sichtbar werden. CI dreht diese Logik um: Statt Konflikte zu vermeiden, werden sie permanent provoziert und sofort behoben. Damit wird der Hauptbranch dauerhaft in einem deploybaren Zustand gehalten — eine Voraussetzung für Continuous Delivery und Continuous Deployment.
Historisch wurde der Begriff von Grady Booch in seinem Buch "Object-Oriented Analysis and Design" (1991) geprägt und durch Kent Beck als Bestandteil von Extreme Programming (1999) populär. Martin Fowlers Artikel "Continuous Integration" (2000) listet die heutigen Kernprinzipien auf — single source repository, automate the build, self-testing build, fast build, test in a clone of the production environment, anyone can see what's happening. Werkzeuge wie CruiseControl (2001), Hudson/Jenkins (ab 2005), Travis CI, GitHub Actions und Azure Pipelines haben die Praxis schrittweise aus dem .NET, Java- und Open-Source-Umfeld in die gesamte Industrie getragen.
Eingeführt und geprägt wurde CI maßgeblich durch die XP-Community um Kent Beck, Ron Jeffries und Ward Cunningham sowie durch Martin Fowler. Die ursprüngliche XP-Praxis sah vor, dass Code mehrfach am Tag in einen einzigen "Main"-Branch eingecheckt werden sollte — Trunk-Based Development. Mit der Verbreitung von git und dem Git-Flow rückte zwischenzeitlich der Pull-Request-Workflow in den Vordergrund, der vorübergehend kurzlebige Branches erlaubt. Die DORA-Studie "Accelerate" (2018) hat empirisch gezeigt, dass High-Performer-Teams in der Praxis eine sehr kurze Branch-Lebensdauer (häufig unter einem Tag) bevorzugen — eine Bestätigung der ursprünglichen XP-Idee, leicht angepasst an heutige Werkzeuge.