Was ist eine CI/CD Pipeline?
Eine CI/CD Pipeline ist eine automatisierte Abfolge von Schritten, die Code-Änderungen vom Commit bis zum fertigen Deployment führt. Sie baut die Software, führt Tests aus, prüft Qualitätskriterien und liefert das Ergebnis am Ende in die Zielumgebung aus.
Auch bekannt als: CI-Pipeline · CD-Pipeline · Build-Pipeline · Deployment-Pipeline
Ist CI/CD Pipeline bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Eine Pipeline startet mit einem Auslöser, meist einem Git-Ereignis: ein Push, ein Merge in den Hauptbranch oder ein Tag. Danach laufen die Stages nacheinander ab, typischerweise Checkout, Build, Unit-Test, statische Codeanalyse, Quality Gate, Packaging, Integrationstest und Deploy. Jede Stage übergibt ihr Ergebnis an die nächste und bricht die Kette ab, wenn sie scheitert. Je nach Reifegrad kommen Security-Scans, SBOM-Generierung und Freigabeschritte hinzu.
Die Pipeline-Definition liegt heute in der Regel als Pipeline as Code im Repository, etwa als Jenkinsfile, .gitlab-ci.yml oder GitHub-Workflow. Damit gilt für die Pipeline dasselbe wie für den Anwendungscode. Jede Änderung ist versioniert, geht durch das Code-Review und lässt sich zurückverfolgen.
Im Industrial-DevOps-Kontext kommen eigene Stages hinzu. Firmware wird per Cross-Compilation für den Zielcontroller gebaut, Hardware-in-the-Loop-Tests (HiL) prüfen sie auf einem Prüfstand gegen simulierte Sensorsignale, und OT-Proxy-Agents bringen das Artefakt in segmentierte Produktionsnetze. Dazu kommt Wartungsfenster-Logik, die ein Deployment nur in freigegebenen Zeiträumen zulässt. Eine Pipeline für eine SPS-Steuerung sieht deshalb anders aus als eine für ein Web-Backend.
Pipelines verlieren ihr Vertrauen meist durch drei Dinge: flaky Tests, die mal grün und mal rot sind, fehlende Parallelisierung und lange Laufzeiten sowie monolithische Definitionen ohne klare Stage-Trennung. Eine gute Pipeline scheitert früh und sagt verständlich, warum. Das Gegenbeispiel kennt jeder, der es erlebt hat. Kurz vor Feierabend bricht der Build in Minute 38 im letzten Schritt ab, und der Fehler steckte im ersten Commit des Tages.
Inzwischen gehören Supply-Chain-Stages zum Standardaufbau: Artefakt-Signierung, SBOM-Generierung und Provenance-Nachweise. Cyber Resilience Act und NIS2 haben sie aus der Kür in die Pflicht geholt. Gleichzeitig entstehen Pipeline-Definitionen immer öfter mit KI-Unterstützung. Assistenten wie Claude Code erzeugen aus einem bestehenden Projekt ein lauffähiges Jenkinsfile oder eine .gitlab-ci.yml und erklären fehlgeschlagene Stages aus dem Build-Log. Das Review durch jemanden, der die Zielumgebung kennt, bleibt nötig. Es beginnt nur nicht mehr bei einer leeren Datei, sondern bei einem prüfbaren Entwurf.
Firmware geht erst nach bestandenem HiL-Test ins OTA-Rollout
Ein Hersteller vernetzter Steuerungen prüfte Firmware bisher von Hand am Labortisch. Heute kompiliert die Pipeline für den Zielcontroller, flasht das Image auf einen HiL-Prüfstand und misst das Echtzeitverhalten gegen simulierte Sensorsignale. Nur ein Image, das diese Stage besteht, wird für das Over-the-Air-Update (OTA) freigegeben.
Kritische CVE stoppt den Build vor dem Packaging
Bei einem Fertigungsbetrieb fielen verwundbare Bibliotheken früher erst im jährlichen Security-Audit auf. Jetzt bricht die Pipeline ab, sobald der Dependency-Scan eine kritische CVE meldet oder die SBOM nicht erzeugt werden kann. Eine ungeprüfte Komponente erreicht dadurch keine Produktionsumgebung mehr.
Was ist der nächste Schritt für Ihre Pipeline?
Ob erste Pipeline oder Feinschliff einer bestehenden — der sinnvolle nächste Schritt hängt daran, wie weit Sie schon sind. Zwei Klicks ordnen ein, wo Ihr Hebel liegt.
Wie weit ist Ihre Pipeline heute?
- Was ist der Unterschied zwischen einer Pipeline und einem einzelnen Build-Job?
- Ein Build-Job erledigt genau eine Aufgabe, etwa das Kompilieren. Eine Pipeline verkettet mehrere solcher Schritte mit Abhängigkeiten, Bedingungen und Fehlerbehandlung. Sie kennt den Zustand über alle Stages hinweg und entscheidet, ob es weitergeht.
- Wie lange darf eine CI/CD-Pipeline laufen?
- Für die schnelle CI-Schleife gelten zehn Minuten als Richtwert, damit Entwickler zeitnah Feedback bekommen. Lang laufende Integrations- oder HiL-Tests gehören in einen nachgelagerten Strang. Der läuft parallel und blockiert die schnelle Schleife nicht.
- Sollte jede Anwendung eine eigene Pipeline haben?
- In der Regel ja, eine Pipeline pro deploybarer Einheit. Gemeinsame Logik lagern Sie in wiederverwendbare Bausteine wie Jenkins Shared Libraries oder Workflow-Templates aus. Pipelines per Copy-Paste zu vervielfältigen rächt sich spätestens beim ersten Sicherheitsupdate, das in zwanzig Dateien nachgezogen werden muss.
- Welche Stages hat eine typische CI/CD-Pipeline?
- Der Kern sind fünf Stages: Build (kompilieren, paketieren), Test (Unit- und Integrationstests), Analyse (statische Code-Prüfung, Security-Scans), Staging-Deployment mit Abnahmetests und schließlich das Produktions-Deployment. Je nach Branche kommen SBOM-Generierung oder Compliance-Checks hinzu. Die Reihenfolge folgt einer einfachen Regel: billige, schnelle Prüfungen zuerst.
- Wie erstelle ich eine CI/CD-Pipeline?
- In fünf Schritten: Repository und Branch-Strategie festlegen, den Build automatisieren, Tests und statische Analyse als Stages ergänzen, ein Quality Gate als Abbruchkriterium definieren und zuletzt das Deployment in eine Testumgebung anbinden. Beginnen Sie mit der schnellen Build-Test-Schleife und erweitern Sie danach schrittweise. Wer mit dem Produktions-Deployment anfängt, automatisiert ungeprüften Code.
Wo steht Ihr Team bei CI/CD Pipeline?
Uns interessiert, wo Ihr Team bei diesem Thema steht. Auf Basis Ihrer Antwort schlagen wir Ihnen den sinnvollsten nächsten Schritt vor — ganz ohne Formular.
Wie unterscheidet sich Continuous Deployment von Continuous Delivery?
Was ist ein Deployment und was bedeutet es auf Deutsch?
Warum ist die Deployment Frequency wichtig?
Was ist ein Container in der Softwareentwicklung?
Weiterführende Primärquellen zu CI/CD Pipeline: Normtexte, Hersteller- und Projektdokumentation. Alle Ziele öffnen in einem neuen Tab.
- /01JenkinsJenkins Pipeline(externe Seite, öffnet in neuem Tab)
Aufbau einer Pipeline aus Stages und Steps, deklarativ und in Scripted Syntax.
- /02GitLab DocsGitLab CI/CD Pipelines(externe Seite, öffnet in neuem Tab)
Pipeline-Typen, Stages, Jobs und Abhängigkeiten in GitLab CI mit Beispielkonfigurationen.
- /03GitHub DocsAbout workflows(externe Seite, öffnet in neuem Tab)
Wie Workflows in GitHub Actions ausgelöst werden und wie Jobs und Runner zusammenspielen.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance