Continuous Integration (CI): Definition, Ablauf und Bedeutung für das IT Service Management

Continuous Integration (CI) ist eine Praxis der Softwareentwicklung, bei der alle Beteiligten ihre Änderungen mindestens täglich in einen gemeinsamen Hauptzweig der Versionsverwaltung zusammenführen und jede dieser Integrationen durch einen automatisierten Build mit Tests geprüft wird. So beschreibt es Martin Fowler in der 2024 überarbeiteten Fassung seines Grundlagenartikels. Ziel ist, Integrationsfehler innerhalb von Minuten zu erkennen statt Wochen später beim Zusammenführen großer Änderungen.

CI ist damit zuerst eine Arbeitsweise und erst danach ein Werkzeug. Ein CI-Server, der Feature-Branches baut, die wochenlang nicht in den Hauptzweig zurückfließen, erfüllt die Definition nicht. Für die Unternehmens-IT ist CI aus einem zweiten Grund wichtig: Jede integrierte Änderung kann später als Change in den Betrieb gehen. Wer CI einführt, verändert deshalb auch Change Enablement, Release Management und die Arbeit im Service Desk.

Das Wichtigste in Kürze

• Prinzip: kleine Änderungen, mindestens täglich in den Hauptzweig, jede Integration automatisch gebaut und getestet. Ein fehlgeschlagener Build hat Vorrang vor neuer Arbeit.
• Abgrenzung: CI endet beim geprüften Hauptzweig. Continuous Delivery hält die Software jederzeit auslieferbar, Continuous Deployment bringt jede grüne Änderung automatisch in Produktion.
• ITSM-Bezug: Eine verlässliche Pipeline ist die Grundlage, um wiederkehrende Auslieferungen als Standard-Changes zu behandeln und Freigaben auf risikoreiche Änderungen zu konzentrieren.
• Messen: DORA nutzt fünf Kennzahlen, darunter Change-Fehlerrate und Wiederherstellungszeit nach fehlgeschlagenen Deployments. Verlässlich erheben lassen sich beide, wenn Incidents mit dem auslösenden Deployment verknüpft werden.

Stand: November 2026 · Fachlich abgeglichen mit Martin Fowler, den DORA-Capabilities, der Dokumentation von Microsoft, GitHub und GitLab sowie dem BSI IT-Grundschutz (Quellen am Ende des Artikels)

So funktioniert Continuous Integration

Ausgangspunkt ist ein gemeinsamer Hauptzweig, meist main oder trunk genannt, in dem alles liegt, was zum Bauen und Konfigurieren der Anwendung nötig ist: Quellcode, Testcode, Build-Skripte, Datenbankmigrationen und die Pipeline-Definition selbst. Ein CI-System beobachtet diesen Zweig und startet bei jeder Änderung einen definierten Ablauf.

Der Ablauf einer Integration

1. Lokal vorbereiten: Die Entwicklerin holt den aktuellen Stand des Hauptzweigs, setzt eine kleine Änderung um und führt die schnellen Tests lokal aus.
2. Integrieren: Sie führt die Änderung in den Hauptzweig zusammen, direkt oder über einen kurzlebigen Pull Request.
3. Bauen: Das CI-System kompiliert den Code, löst Abhängigkeiten auf und erzeugt ein Artefakt, etwa ein Container-Image oder ein Installationspaket.
4. Prüfen: Unit-Tests, statische Code-Analyse und weitere automatisierte Prüfungen laufen gegen genau dieses Artefakt.
5. Rückmelden: Das Ergebnis ist für das ganze Team sichtbar. Schlägt der Build fehl, wird er sofort repariert oder die Änderung zurückgenommen.
6. Weitergeben: Ein grünes Artefakt kann in nachfolgende Stufen gehen, zum Beispiel in eine Testumgebung. Das ist bereits der Übergang zu Continuous Delivery.

Entscheidend ist die Geschwindigkeit. Extreme Programming nannte zehn Minuten als Richtwert für einen Build, und DORA bezeichnet etwa zehn Minuten als Obergrenze für die Tests einer Integration. Längere Testläufe, etwa End-to-End-Tests gegen eine echte Datenbank, wandern in eine zweite Pipeline-Stufe.

Die Praktiken hinter CI

Fowler fasst CI in elf Praktiken zusammen. Für die Einführung in Unternehmen sind vor allem fünf maßgeblich:

• Alles liegt versioniert im Hauptzweig, auch Konfiguration und Infrastrukturbeschreibungen.
• Der Build läuft automatisch und testet sich selbst.
• Jede Änderung am Hauptzweig löst einen Build aus, und ein roter Build wird sofort behoben.
• Unfertige Funktionen werden versteckt, etwa über Feature-Flags, statt in langlebigen Branches zu warten.
• Getestet wird in einer Umgebung, die der Produktion möglichst gleicht.

Langlebige Feature-Branches, auf denen ein CI-Dienst nur die Branch-Stände baut, nennt Fowler „Semi-Integration“. Die Konflikte mit der Arbeit anderer bleiben dabei unsichtbar, bis spät zusammengeführt wird.

Herkunft und Werkzeuge

Grady Booch verwendete den Begriff Anfang der 1990er-Jahre nur beiläufig. Zu einer definierten Praxis wurde CI Ende der 1990er-Jahre in Extreme Programming. Martin Fowler beschrieb sie erstmals 2000 in dem Artikel, auf den sich dieser Eintrag stützt. Heute definieren Teams ihre Pipelines meist als Datei im Repository: bei GitHub Actions als Workflow-Dateien im Verzeichnis .github/workflows, bei GitLab CI/CD in der .gitlab-ci.yml, bei Azure Pipelines in einer YAML-Datei. Jenkins ist ein verbreiteter, selbst betriebener Open-Source-Server. Die Wahl des Werkzeugs ist zweitrangig, solange die Praktiken eingehalten werden.

CI, Continuous Delivery und Continuous Deployment

Die drei Begriffe werden oft unter „CI/CD“ zusammengefasst, beschreiben aber unterschiedliche Reichweiten. Fowler grenzt sie so ab: CI sorgt dafür, dass alle mindestens täglich in den Hauptzweig integrieren. Continuous Delivery stellt sicher, dass das Produkt jederzeit in Produktion gebracht werden kann. Continuous Deployment bringt jede Änderung automatisch in Produktion, sobald alle Prüfungen der Pipeline bestanden sind.

CI und DevOps

CI ist keine Methode für sich, sondern eine technische Praxis innerhalb von DevOps. DevOps beschreibt die engere Zusammenarbeit von Entwicklung und Betrieb über den gesamten Lebenszyklus. CI liefert dafür die schnelle Rückmeldung auf der Entwicklungsseite, Monitoring und Incident Management liefern sie auf der Betriebsseite.

CI und Trunk-Based Development

Trunk-Based Development ist ein Verzweigungsmodell, bei dem alle in kleinen Schritten direkt am Hauptzweig arbeiten oder nur sehr kurzlebige Branches nutzen. Fowler setzt beide Begriffe weitgehend gleich. DORA führt sie als getrennte, aber eng verbundene Capabilities. Pull Requests schließen CI nicht aus, solange sie klein bleiben und innerhalb von Stunden zusammengeführt werden.

Continuous Integration im IT Service Management

CI selbst endet beim geprüften Hauptzweig. Für die Serviceorganisation beginnt die eigentliche Frage danach: Wie kommen diese Änderungen kontrolliert in den Betrieb, und wie erfährt der Service Desk davon? In ITIL 4 betrifft das drei Practices: Change Enablement bewertet und autorisiert Änderungen, Release Management macht neue Funktionen verfügbar, Deployment Management bringt Komponenten in die Zielumgebung.

Freigaben dorthin verlagern, wo das Risiko liegt

DORA hat in der Studie „State of DevOps“ 2019 untersucht, wie Freigaben die Lieferleistung beeinflussen. Ergebnis: Schwergewichtige Genehmigungen durch externe Gremien wie ein Change Advisory Board wirkten sich negativ aus, und es fand sich kein Beleg dafür, dass sie die Change-Fehlerrate senken. Empfohlen werden stattdessen Peer Reviews im Entwicklungsprozess, ergänzt um automatisierte Tests, CI und Monitoring.

Für das IT Service Management folgt daraus kein Verzicht auf Kontrolle, sondern eine andere Verteilung. Eine Pipeline mit festgelegten Prüfungen kann einmal bewertet werden. Auslieferungen, die genau diesen Weg nehmen, lassen sich dann als Standard-Change behandeln, also als vorab autorisierte Änderung mit bekanntem Risiko. Das Gremium befasst sich mit dem, was davon abweicht: Datenbankumbauten, neue Schnittstellen, Änderungen an sicherheitskritischen Komponenten.

Ein Beispiel aus der Praxis

Angenommen, ein Versicherer entwickelt sein Kundenportal mit sechs Teams selbst. Bisher ging alle vier Wochen ein großes Release über das CAB, jedes mit einer langen Liste an Einzeländerungen. Nach der Einführung von CI und Continuous Delivery legt die IT drei Klassen fest:

• Standard-Change: Auslieferung über die freigegebene Pipeline, Review durch eine zweite Person, alle Prüfungen grün. Das Ticket entsteht automatisch und dokumentiert Version, Zeitpunkt und Prüfergebnisse.
• Normaler Change: Änderungen an Datenmodell, Schnittstellen oder Berechtigungen. Hier bewertet eine Change Authority vor dem Deployment.
• Notfall-Change: Hotfix nach einem schweren Incident. Er läuft durch dieselbe Pipeline, Bewertung und Freigabe erfolgen beschleunigt, die Dokumentation wird nachgezogen.

Damit der Service Desk Störungen einordnen kann, gehören zu jeder Auslieferung kurze Release Notes in der Wissensdatenbank. Und jeder Incident, der kurz nach einem Deployment eintritt, wird mit dem auslösenden Change verknüpft. Damit beruht die Change-Fehlerrate auf erfassten Fällen statt auf einer Schätzung im Nachhinein.

Die Rolle der ITSM-Software

Ein ITSM-Werkzeug ersetzt kein CI-System. Es hält aber fest, was die Pipeline nicht weiß: wer eine Änderung beantragt hat, welche Services betroffen sind und welche Incidents folgten. ky2help^® bildet Change Enablement und Release Management als zwei der 13 von PeopleCert akkreditierten ITIL-Practices ab, mit automatischer Historisierung und integriertem Daten-Audit. Im Standard gibt es Schnittstellen zu Jira und ServiceNow sowie eine REST-API (Webservices). Abläufe passen Sie im Prozessdesigner per Drag-and-Drop ohne Programmierung an.

Change Management ansehen

Kennzahlen, Risiken und Best Practices

Woran sich der Erfolg messen lässt

DORA misst die Lieferleistung heute mit fünf Kennzahlen. Drei beschreiben den Durchsatz, zwei die Stabilität:

• Change Lead Time: Zeit vom Commit in die Versionsverwaltung bis zum Deployment in Produktion.
• Deployment-Häufigkeit: Zahl der Deployments in einem Zeitraum.
• Wiederherstellungszeit nach fehlgeschlagenem Deployment: Zeit, bis ein Deployment behoben ist, das sofortiges Eingreifen erfordert. Sie hat die frühere Kennzahl MTTR abgelöst.
• Change-Fehlerrate: Anteil der Deployments, die sofortiges Eingreifen erfordern, etwa ein Rollback oder einen Hotfix.
• Deployment-Rework-Rate: Anteil ungeplanter Deployments, die wegen eines Incidents in Produktion nötig werden.

Die beiden Stabilitätswerte und die Wiederherstellungszeit stützen sich auf Incident-Daten. Am genauesten werden sie, wenn jeder Incident mit dem auslösenden Change verknüpft ist. Für CI selbst sind zusätzlich Build-Dauer, Anteil roter Builds und die Zeit bis zur Reparatur aussagekräftig. Mehr zur Auswahl von Messgrößen steht im Glossar unter KPI.

Typische Risiken

• Pipeline als Angriffsziel: Die Pipeline hat Zugriff auf Quellcode, Zugangsdaten und Zielumgebungen. OWASP führt unter den zehn größten CI/CD-Risiken unter anderem unzureichende Kontrolle des Ablaufs, manipulierte Pipeline-Ausführung und mangelnde Hygiene bei Zugangsdaten.
• Abhängigkeiten: Externe Bibliotheken müssen nach BSI CON.8 aus vertrauenswürdigen Quellen stammen, ihre Integrität ist zu prüfen.
• Instabile Tests: Tests, die mal grün und mal rot sind, untergraben das Vertrauen. Teams beginnen, rote Builds zu ignorieren.
• Testdaten: Produktivdaten mit Personenbezug sind nach BSI OPS.1.1.6 mindestens zu pseudonymisieren, wenn sie für Tests genutzt werden.

Best Practices für den Einstieg

• Mit einem Build beginnen, der in wenigen Minuten durchläuft, und ihn erst danach um weitere Prüfungen erweitern.
• Den Hauptzweig schützen: Änderungen nur über bestandene Prüfungen und ein Review durch eine zweite Person.
• Die Pipeline-Definition versionieren und wie Code reviewen. Das BSI fordert in CON.8 eine Versionsverwaltung, mit der sich alle Änderungen nachvollziehen und rückgängig machen lassen.
• Zugangsdaten nie im Repository ablegen, sondern im Geheimnisspeicher des CI-Systems.
• Release Notes, Known Errors und Rückfallpläne dort pflegen, wo der Service Desk sie findet.

Häufige Fragen zu Continuous Integration

Was ist Continuous Integration einfach erklärt?

Continuous Integration bedeutet, dass alle Entwicklerinnen und Entwickler ihre Änderungen mindestens täglich in einen gemeinsamen Hauptzweig einbringen. Jede Integration wird automatisch gebaut und getestet, sodass Fehler innerhalb von Minuten sichtbar werden und nicht erst beim nächsten großen Release.

Was ist der Unterschied zwischen CI und CD?

CI endet beim geprüften Hauptzweig. CD steht für Continuous Delivery oder Continuous Deployment. Continuous Delivery hält die Software jederzeit auslieferbar, die Auslieferung löst aber ein Mensch oder eine Regel aus. Continuous Deployment bringt jede Änderung automatisch in Produktion, sobald alle Prüfungen bestanden sind.

Wie oft sollte integriert werden?

Mindestens einmal täglich pro Person, besser mehrmals. Martin Fowler und DORA nennen täglich als Untergrenze. Je kleiner die Änderung, desto leichter lassen sich Fehler finden und Konflikte lösen.

Welche Tools gibt es für Continuous Integration?

Verbreitet sind GitHub Actions, GitLab CI/CD, Azure Pipelines und Jenkins. Die ersten drei sind in Plattformen für Versionsverwaltung integriert, Jenkins ist ein eigenständiger Open-Source-Server. Wichtiger als die Wahl des Werkzeugs ist, dass das Team die Praktiken einhält.

Braucht man mit CI noch ein Change Advisory Board?

Für risikoreiche Änderungen kann ein Gremium sinnvoll bleiben. Routinemäßige Auslieferungen über eine geprüfte Pipeline lassen sich dagegen als Standard-Change behandeln. DORA fand keinen Beleg dafür, dass externe Genehmigungen die Change-Fehlerrate senken, und empfiehlt Peer Reviews mit Automatisierung.

Wie unterstützt ky2help® Teams, die mit CI arbeiten?

ky2help^® ist kein CI-System, sondern die ITSM-Software für den Betrieb danach. Change Enablement und Release Management gehören zu den 13 von PeopleCert akkreditierten ITIL-Practices. Im Standard gibt es Schnittstellen zu Jira und ServiceNow sowie eine REST-API. Wie das in Ihrer Umgebung aussieht, zeigen wir in einer Live-Demo.

Quellen und weiterführende Artikel

Quellen

• Martin Fowler: Continuous Integration (überarbeitete Fassung vom 18. Januar 2024)
• DORA: Continuous integration, Streamlining change approval und DORA's software delivery performance metrics
• Microsoft Learn: Kontinuierliche Integration verwenden
• GitHub Docs: Kontinuierliche Integration · GitLab Docs: Get started with GitLab CI/CD
• OWASP: Top 10 CI/CD Security Risks
• BSI IT-Grundschutz-Kompendium, Edition 2023: CON.8 Software-Entwicklung und OPS.1.1.6 Software-Tests und -Freigaben (PDF)

Weiterlesen im Glossar und in der Wissenswelt

• DevOps und REST API
• Change Management und Change Advisory Board
• Was ist ITIL Release Management?
• ITIL Change Management und ITIL Incident Management
• ITIL und ITSM