CI/CD

CI/CD steht für Continuous Integration und Continuous Delivery und bezeichnet eine automatisierte Arbeitsweise, bei der Codeänderungen fortlaufend integriert, getestet und auslieferungsbereit gemacht werden. Continuous Integration zielt auf den Entwicklungsfluss: Jeder Commit wandert in einen gemeinsamen Branch, wird automatisch gebaut und getestet, sodass Integrationskonflikte innerhalb von Minuten statt erst Wochen vor einem Release auffallen. Continuous Delivery setzt darauf auf und sorgt dafür, dass jeder erfolgreich getestete Stand ein freigabefähiges Artefakt erzeugt, das jederzeit kontrolliert in Produktion gehen kann.

Wichtig ist die Abgrenzung zu Continuous Deployment: Bei Continuous Delivery bleibt der letzte Schritt in Produktion ein bewusster, manueller Knopfdruck. Erst Continuous Deployment automatisiert auch diesen Schritt vollständig. In regulierten Industrien ist diese Trennung relevant, weil Freigaben oft dokumentiert und an Wartungsfenster oder Audits gebunden sind.

Für Industrieunternehmen liegt der Wert nicht primär in der Geschwindigkeit, sondern in Reproduzierbarkeit und Nachweisbarkeit. Wenn ein SPS-Programm, ein Embedded-Firmware-Image oder ein Backend-Service immer über dieselbe automatisierte Strecke entsteht, ist jeder Build identisch nachvollziehbar — eine Voraussetzung für Standards wie ASPICE, ISO 26262 oder IEC 62443.

Typische Stolpersteine: CI/CD wird als reines Tooling-Projekt verstanden und nicht als Kulturwandel, Tests werden zu spät automatisiert, oder die Pipeline wird so langsam, dass Entwickler sie umgehen. Eine CI-Strecke, die länger als zehn Minuten Feedback braucht, verliert in der Praxis ihre Wirkung. Und ein Muster kennt fast jedes Team: Der eine Kollege, der als Einziger den Release-Build zusammenstecken kann, ist im Urlaub — und niemand weiß, welche Flags er lokal setzt.

Wo steht CI/CD 2026? Zwei Entwicklungen prägen die Praxis. Erstens ist die Lieferkette selbst zum Prüfgegenstand geworden: Signierte Artefakte, SBOM-Generierung und Provenance-Nachweise nach Frameworks wie SLSA wandern als feste Stages in die Pipeline — getrieben durch Cyber Resilience Act und NIS2. Zweitens übernehmen KI-Assistenten Routinearbeit an der Pipeline: Sie erklären fehlgeschlagene Builds, schlagen Fixes für Konfigurationsfehler vor und generieren Pipeline-Definitionen aus bestehenden Projekten. Der Leistungsabstand bleibt derweil groß: Elite-Teams liefern laut DORA-Report on demand aus, also mehrmals täglich, Low Performer zwischen einmal im Monat und einmal im Halbjahr — der Unterschied entsteht fast immer durch den Grad der Automatisierung, nicht durch die Tool-Wahl.