Was ist eine CI/CD-Pipeline?
Continuous Integration und Continuous Delivery
Eine CI/CD-Pipeline ist eine automatisierte Kette von Arbeitsschritten, die nach jeder Änderung im Repository anläuft und den Code baut, testet und für die Auslieferung vorbereitet. Sie ist als Datei im Projekt beschrieben und läuft damit für jeden Beitrag nach denselben Regeln.
Sobald mehr als zwei Leute am selben Code arbeiten, entscheidet die Pipeline darüber, ob eine Änderung in Minuten beim Kunden ankommt oder erst nach Tagen.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
- Löst aus
- Jeder Push und jeder Merge- oder Pull-Request
- Liegt als
- Versionierte Datei im Repository
- Typische Stufen
- Bauen, Testen, Paketieren, Ausliefern
- Verwechselt mit
- Continuous Deployment
Was beim Commit passiert
Der Auslöser ist ein Ereignis im Repository, meist ein Push oder ein Pull Request. Der Dienst liest die Pipelinebeschreibung, bei GitLab die Datei .gitlab-ci.yml im Projektwurzelverzeichnis, bei GitHub Actions eine Workflow-Datei unter .github/workflows. Darin stehen Jobs, die in Stages gruppiert sind, typischerweise erst bauen, dann testen, dann ausliefern.
Ausgeführt werden die Jobs von einem Runner, also einem Prozess auf einer Maschine oder in einem Container, der eine frische Umgebung bereitstellt. Genau darin liegt der Gewinn: Der Build läuft nicht auf dem Laptop mit den historisch gewachsenen Werkzeugen, sondern auf einem definierten Stand, den alle teilen.
Ergebnisse eines Jobs, etwa ein fertiges Paket oder ein Testbericht, werden als Artefakt abgelegt und stehen späteren Jobs zur Verfügung. Ohne diese Weitergabe würde jede Stage von vorn bauen, denn zwischen zwei Jobs bleibt vom Arbeitsverzeichnis nichts erhalten.
Delivery ist nicht Deployment
Continuous Delivery bedeutet, dass jeder erfolgreiche Durchlauf ein auslieferbares Ergebnis erzeugt. Ob es in die Produktion geht, entscheidet ein Mensch per Freigabe. Continuous Deployment geht einen Schritt weiter und rollt jede grüne Änderung automatisch aus.
Die Entscheidung dazwischen ist keine technische, sondern eine über Risiko und Rückweg. Ohne belastbare Tests, ohne Überwachung und ohne geübtes Zurückrollen ist automatisches Ausrollen nur ein schnellerer Weg in den Ausfall. Umgekehrt ist eine Freigabe, die wochenlang liegen bleibt, kein Sicherheitsgewinn, sondern sammelt Änderungen zu einem großen, riskanten Sprung.
Woran Pipelines scheitern
Der größte Feind sind unzuverlässige Tests, die mal durchlaufen und mal nicht. Sobald das Team gewohnt ist, einen roten Durchlauf einfach neu zu starten, ist die Aussagekraft der Pipeline weg und echte Fehler gehen im Rauschen unter. Solche Tests gehören repariert oder deaktiviert, nicht toleriert.
Der zweite Punkt ist die Laufzeit. Dauert ein Durchlauf eine halbe Stunde, wechselt jeder das Thema und kommt später mit kaltem Kopf zurück. Abhilfe schaffen Caches für Abhängigkeiten, parallele Jobs und eine schnelle Vorstufe mit den wichtigsten Tests, während lange Prüfungen erst danach greifen.
Und Zugangsdaten gehören nie in die Pipelinedatei, denn die liegt im Repository und ist für alle lesbar, die den Code sehen. Beide Plattformen bieten dafür verschlüsselte Variablen, deren Werte in den Protokollen maskiert werden.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
CI/CD-Pipeline und was oft damit gleichgesetzt wird
Ein reiner Build-Server kompiliert auf Zuruf oder nach Zeitplan. Die Pipeline hängt am Repository, läuft bei jeder Änderung und umfasst auch Tests und Auslieferung.
DevOps beschreibt die Zusammenarbeit von Entwicklung und Betrieb. Die Pipeline ist ein Werkzeug darin, sie ersetzt aber keine gemeinsame Verantwortung für den laufenden Betrieb.
Dort wird die Umgebung selbst als Code beschrieben. Die Pipeline führt solche Beschreibungen aus, ist aber nicht dasselbe.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Eine Pipeline, deren Rot niemand mehr ernst nimmt, ist wertlos
Der Verfall beginnt fast immer mit einem Test, der nur manchmal fehlschlägt, weil er von Zeitzonen, Ausführungsreihenfolge oder einem langsamen Netz abhängt. Nach dem dritten grundlosen Fehlschlag startet jemand den Job einfach neu, und ab da liest niemand mehr das Protokoll. Solche Tests gehören stabilisiert oder herausgenommen, sonst verliert das Team das Vertrauen in das Signal.
Der zweite wunde Punkt sind Zugangsdaten. Die Pipeline braucht Schlüssel für Registry, Testsystem und Zielumgebung, und die landen erstaunlich oft im Klartext in der Konfigurationsdatei, die jeder mit Leserecht am Repository sieht. Sauber ist die Ablage im Secret-Store des Systems, mit getrennten Rechten für Zweige und Umgebungen.
Und dann ist da die Laufzeit. Dauert die Kette länger als eine Kaffeepause, arbeiten alle weiter, statt auf das Ergebnis zu warten, und ein Fehler fällt erst auf, wenn drei weitere Änderungen darauf liegen. Zwischenspeicher für Abhängigkeiten, parallele Jobs und ein schneller Vorlauf vor den langsamen Tests bringen hier am meisten.
CI/CD-Pipeline lernen
Wie du Branch-Strategie, Merge-Regeln und automatische Durchläufe aufeinander abstimmst, klären die Trainings zu Git und GitHub an einem echten Projekt.
Häufige Fragen
Lohnt sich eine Pipeline für ein kleines Team?
Was gehört in die erste Ausbaustufe?
Wie hängen Branches und Pipeline zusammen?
Deine Ansprechpartner
Du willst das Thema nicht nur nachschlagen, sondern anwenden können? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Ordnet mit dir ein, welcher Kurs zu deinem Vorwissen passt.
Norbert Jansen
Beratung & Inhouse
Plant Inhouse-Trainings, die an euren eigenen Daten und Abläufen ansetzen.
CI/CD-Pipeline im Kurs statt im Lexikon
Nachschlagen bringt dich bis zum Verstehen. Anwenden lernst du an echten Aufgaben.