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.
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 CI/CD Pipeline ist die konkrete technische Umsetzung des CI/CD-Prinzips: eine definierte, automatisierte Kette von Stages, die ein Code-Artefakt von einem Auslöser bis zur Zielumgebung führt. Typische Stages sind Checkout, Build, Unit-Test, statische Codeanalyse, Quality Gate, Packaging, Integrationstest und Deploy — je nach Reifegrad ergänzt um Security-Scans, SBOM-Generierung und Approval-Schritte.
Der Auslöser ist meist ein Git-Ereignis: ein Push, ein Merge in den Hauptbranch oder ein Tag. Moderne Pipelines liegen als Pipeline as Code direkt im Repository, etwa als Jenkinsfile, .gitlab-ci.yml oder GitHub-Workflow. Damit unterliegt die Pipeline selbst der Versionskontrolle und dem Code-Review.
Im Industrial-DevOps-Kontext erweitern sich die Stages um Besonderheiten: Cross-Compilation für Embedded-Targets, Hardware-in-the-Loop-Tests, OT-Proxy-Agents für das Deployment in segmentierte Netze und Wartungsfenster-Logik, die ein Deployment nur in freigegebenen Zeiträumen erlaubt. Eine Pipeline für eine SPS-Steuerung sieht deutlich anders aus als eine reine Web-Backend-Pipeline.
Häufige Stolpersteine sind flaky Tests, die Pipelines unzuverlässig machen, fehlende Parallelisierung mit dadurch langen Laufzeiten und monolithische Pipelines ohne klare Stage-Trennung. Eine gute Pipeline scheitert früh und gibt verständliches Feedback. Das Gegenbeispiel kennt jeder, der es erlebt hat: Feierabend, der Build bricht in Minute 38 am letzten Schritt ab — und der Fehler lag im ersten Commit des Tages.
Stand 2026 hat sich der typische Aufbau um zwei Elemente erweitert. Supply-Chain-Security-Stages — Artefakt-Signierung, SBOM-Generierung, Provenance-Nachweise — sind durch Cyber Resilience Act und NIS2 vom Nice-to-have zum Standard geworden. Und die Pipeline-Definition selbst entsteht immer öfter KI-gestützt: Assistenten wie Claude Code generieren aus einem bestehenden Projekt ein lauffähiges Jenkinsfile oder eine .gitlab-ci.yml und erklären fehlgeschlagene Stages direkt aus dem Build-Log. Das Review durch einen Menschen, der die Zielumgebung kennt, ersetzt das nicht — es verschiebt nur den Startpunkt von der leeren Datei zum prüfbaren Entwurf.
Embedded-Pipeline mit HiL-Stage
Eine Firmware-Pipeline cross-compiliert für den Zielcontroller, flasht das Image auf eine HiL-Bank und prüft Echtzeitverhalten gegen simulierte Sensorsignale, bevor das Artefakt für ein OTA-Rollout freigegeben wird.
Pipeline mit vorgelagertem Security-Gate
Bei einem Fertigungsbetrieb bricht die Pipeline ab, sobald ein Dependency-Scan eine kritische CVE meldet oder die SBOM nicht erzeugt werden kann — so wird keine ungeprüfte Komponente Richtung Produktion ausgeliefert.
- Was ist der Unterschied zwischen einer Pipeline und einem einzelnen Build-Job?
- Ein Build-Job erledigt genau eine Aufgabe, etwa das Kompilieren. Eine Pipeline orchestriert mehrere solcher Schritte als zusammenhängende Kette mit Abhängigkeiten, Bedingungen und Fehlerbehandlung. Die Pipeline kennt den Zustand über alle Stages hinweg.
- Wie lange darf eine CI/CD Pipeline laufen?
- Für die schnelle CI-Schleife gilt unter zehn Minuten als Richtwert, damit Entwickler zeitnah Feedback bekommen. Langlaufende Integrations- oder HiL-Tests werden sinnvollerweise in einen separaten, nachgelagerten Strang verlagert, der die schnelle Schleife nicht blockiert.
- Sollte jede Anwendung eine eigene Pipeline haben?
- In der Regel ja, pro deploybarer Einheit eine Pipeline. Gemeinsame Logik wird über wiederverwendbare Bausteine wie Jenkins Shared Libraries oder Workflow-Templates ausgelagert, statt Pipelines per Copy-Paste zu duplizieren.
- 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 Stages wie SBOM-Generierung oder Compliance-Checks hinzu — die Reihenfolge folgt dem Prinzip: billige, schnelle Prüfungen zuerst.
- Wie erstelle ich eine CI/CD-Pipeline?
- In fünf Schritten: Repository und Branch-Strategie festlegen, den Build-Schritt 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 schrittweise — nicht umgekehrt.
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?
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