CI/CD

Alles beginnt mit einem Commit. Entwickler führen ihre Änderungen mindestens einmal täglich in einen gemeinsamen Hauptbranch zusammen, und ein CI-Server wie Jenkins oder GitLab CI baut daraufhin den Code und startet die automatisierten Tests. Schlägt ein Test fehl, erfährt es der Verursacher nach wenigen Minuten, solange er die Änderung noch im Kopf hat. Hier setzt Continuous Delivery an. Aus jedem grünen Build entsteht ein versioniertes Artefakt, das unverändert bis in die Staging-Umgebung wandert und von dort jederzeit in Produktion gehen kann.

Das D in CI/CD steht meist für Delivery, gelegentlich für Deployment, und der Unterschied steckt im letzten Schritt. Bei Continuous Delivery gibt ein Mensch die Produktion frei. Bei Continuous Deployment übernimmt die Pipeline auch diesen Schritt. In regulierten Industrien ist das keine Wortklauberei. Freigaben müssen dort dokumentiert und oft an Wartungsfenster oder Audits gebunden sein, deshalb bleibt der letzte Knopfdruck bewusst beim Menschen.

In der Industrie zählt die Wiederholbarkeit mehr als das Tempo. Entsteht ein SPS-Programm, ein Firmware-Image oder ein Backend-Service immer über dieselbe automatisierte Strecke, lässt sich jeder Build auf Commit, Compiler-Version und Testergebnis zurückführen. Genau diese Nachweise fragen Assessments nach ASPICE (Automotive SPICE), Sicherheitsnachweise nach ISO 26262 und Audits nach der Security-Norm IEC 62443 ab.

Einführungen scheitern typischerweise an drei Stellen. CI/CD wird als Tooling-Projekt gestartet, die Arbeitsweise im Team bleibt dieselbe. Tests werden erst automatisiert, wenn die Pipeline schon steht. Oder die Strecke wird so langsam, dass Entwickler sie umgehen. Eine CI-Schleife, die länger als zehn Minuten bis zum Feedback braucht, wartet in der Praxis niemand mehr ab. Wie teuer der manuelle Weg ist, zeigt sich meist an einem Freitag. Der Release-Build soll raus, der einzige Kollege, der ihn zusammenbauen kann, ist im Urlaub, und niemand weiß, welche Umgebungsvariablen er lokal gesetzt hat.

Zwei Entwicklungen prägen CI/CD im Jahr 2026. Die Lieferkette ist selbst zum Prüfgegenstand geworden: Signierte Artefakte, eine SBOM (Software Bill of Materials, die Stückliste aller Komponenten) und Provenance-Nachweise nach dem Framework SLSA laufen als feste Stages mit, getrieben durch Cyber Resilience Act und NIS2. Außerdem übernehmen KI-Assistenten Routinearbeit an der Pipeline, erklären fehlgeschlagene Builds aus dem Log und schreiben Pipeline-Definitionen für bestehende Projekte vor. Der Abstand zwischen den Teams bleibt groß. Laut DORA-Report 2024 liefern Elite-Teams bei Bedarf mehrmals täglich aus, Low Performer zwischen einmal im Monat und einmal im Halbjahr. In unseren Projekten liegt dieser Abstand selten am Tool, meist an den manuellen Schritten zwischen Build und Produktion.