Was ist eine CI/CD-Pipeline?
Continuous Integration und Continuous Delivery
Eine CI/CD-Pipeline ist eine automatisierte Abfolge von Arbeitsschritten, die nach jeder Änderung im Repository den Code baut, testet und für die Auslieferung bereitstellt. CI steht für Continuous Integration, CD für Continuous Delivery oder, eine Stufe weiter, Continuous Deployment.
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
CI, Continuous Delivery und Continuous Deployment
Hinter dem Kürzel stecken drei aufeinander aufbauende Praktiken. Die Pipeline ist das Werkzeug, mit dem ein Team sie umsetzt:
| Praxis | Was sie bedeutet | Am Ende steht |
|---|---|---|
| Continuous Integration | Änderungen werden oft, meist mehrmals täglich, in den gemeinsamen Stand gemergt und dabei automatisch gebaut und getestet | Ein grüner Durchlauf mit Testbericht |
| Continuous Delivery | Jeder erfolgreiche Durchlauf erzeugt ein auslieferbares Paket, in Produktion geht es per Freigabe | Ein Release, das jederzeit ausgerollt werden kann |
| Continuous Deployment | Jede grüne Änderung geht ohne menschliche Freigabe in Produktion | Die neue Version im Betrieb |
Die Entscheidung zwischen Delivery und Deployment 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.
Die typischen Stufen einer Pipeline
Wie viele Stufen eine Pipeline hat, hängt vom Projekt ab. Eine ausgebaute Pipeline durchläuft meist diese Schritte, wobei jede Stufe nur startet, wenn die vorherige grün ist:
-
Auslöser
Ein Push, ein Merge Request oder Pull Request, ein Tag oder ein Zeitplan startet den Durchlauf.
-
Build
Der Code wird kompiliert oder gebündelt, Abhängigkeiten werden in festgelegten Versionen installiert.
-
Statische Prüfungen
Linter, Formatprüfung, Sicherheitsscans des Codes und eine Prüfung der Abhängigkeiten auf bekannte Schwachstellen.
-
Tests
Erst die schnellen Unit-Tests, danach Integrationstests und, wo vorhanden, End-to-End-Tests.
-
Paketieren
Das Ergebnis wird als Artefakt abgelegt, häufig als Container Image in einer Registry.
-
Deployment in eine Testumgebung
Die neue Version läuft zuerst auf einer Staging-Umgebung, wo weitere Prüfungen oder Abnahmen stattfinden.
-
Auslieferung
Per Freigabe oder automatisch geht dasselbe Artefakt in Produktion, ohne neu gebaut zu werden.
Wie eine Pipelinedatei aussieht
Die Pipeline ist als Datei im Repository beschrieben und wird damit versioniert wie der Code. Bei GitLab heißt sie .gitlab-ci.yml und liegt im Projektwurzelverzeichnis, bei GitHub Actions liegen Workflow-Dateien im Ordner .github/workflows. Darin stehen Jobs, die in Stages gruppiert sind. Ein vereinfachtes Beispiel für GitLab mit Build, Test und einer manuell freigegebenen Auslieferung vom Hauptbranch:
stages:
- build
- test
- deploy
build:
stage: build
image: node:22
script:
- npm ci
- npm run build
artifacts:
paths:
- dist/
test:
stage: test
image: node:22
script:
- npm ci
- npm test
deploy:
stage: deploy
script:
- ./deploy.sh
environment: production
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
when: manualAusgeführt werden die Jobs von einem Runner, also einem Prozess auf einer Maschine oder in einem Container, der für jeden Job 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.
Zwischen zwei Jobs bleibt vom Arbeitsverzeichnis nichts erhalten. Was ein späterer Job braucht, etwa das gebaute Paket im Ordner dist, wird deshalb als Artefakt weitergegeben. Das „when: manual“ im Beispiel macht aus der Pipeline Continuous Delivery: Die Auslieferung steht bereit und startet erst auf Knopfdruck.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
CI/CD-Pipeline und was oft damit gleichgesetzt wird
Ein klassischer Build-Server kompiliert auf Zuruf oder nach Zeitplan, die Konfiguration liegt oft nur in seiner Oberfläche. Eine Pipeline hängt am Repository, ist dort als Code beschrieben und umfasst auch Tests und Auslieferung. Werkzeuge wie Jenkins können beides sein, je nachdem, wie sie eingerichtet sind.
DevOps beschreibt die Zusammenarbeit von Entwicklung und Betrieb mit gemeinsamer Verantwortung für den laufenden Dienst. Die Pipeline ist ein Werkzeug darin, sie ersetzt aber keine gemeinsame Verantwortung für den Betrieb.
Dort wird die Umgebung selbst als Code beschrieben, etwa Server, Netze und Datenbanken. Die Pipeline führt solche Beschreibungen häufig 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 Pipelinedatei, die jeder mit Leserecht am Repository sieht. Sauber ist die Ablage in den geschützten Variablen oder im Secret-Store der Plattform, deren Werte in den Protokollen maskiert werden, mit getrennten Rechten für Branches 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. Caches für Abhängigkeiten, parallele Jobs und ein schneller Vorlauf mit den wichtigsten Tests vor den langsamen Prüfungen 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.
Kurse, die CI/CD-Pipeline behandeln
Häufige Fragen
Welche Werkzeuge gibt es für CI/CD?
Lohnt sich eine Pipeline für ein kleines Team?
Was gehört in die erste Ausbaustufe?
Wie hängen Branches und Pipeline zusammen?
Passt thematisch dazu
Läuft dieselbe Testsuite lokal grün und im Durchlauf rot, liegt das an der Umgebung, und die sechs Stellen, an denen sich die Umgebung unterscheidet, sind schnell durchgesehen.
Ob GitLab CI/CD oder GitHub Actions besser zu euren Repositorys und Runnern passt, klärt der Vergleich der beiden großen Pipeline-Plattformen.
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.