CI/CD-Pipeline
Eine CI/CD-Pipeline ist eine automatische Kette von Arbeitsschritten, die neuen Programmcode prüft, zusammenbaut und bis zum fertigen Produkt ausliefert. Sie sorgt dafür, dass Software-Teams täglich Änderungen veröffentlichen können, ohne dass jemand die Prüfungen von Hand durchführt.
An einem größeren Programm arbeiten oft dutzende Menschen gleichzeitig. Jede und jeder ändert kleine Teile des Textes, aus dem das Programm besteht. Diese Änderungen müssen zusammengefügt, geprüft und schließlich auf die Server gebracht werden, auf denen das Programm für Nutzer läuft. Eine CI/CD-Pipeline erledigt genau diese Schritte automatisch, in einer festen Reihenfolge. Die Buchstaben stehen für Continuous Integration, also fortlaufendes Zusammenführen, und Continuous Delivery oder Deployment, also fortlaufendes Ausliefern. Man kann sich das Ganze als Fließband vorstellen: vorne kommt eine Änderung hinein, hinten kommt eine geprüfte, lauffähige Version heraus.
Warum Teams täglich statt halbjährlich veröffentlichen
Früher sammelten Firmen Änderungen monatelang und veröffentlichten dann eine große neue Version. Das war riskant. Wenn nach dem Start etwas kaputt war, musste man tausende Änderungen gleichzeitig durchsuchen, um den Fehler zu finden. Bei kleinen, häufigen Auslieferungen ist die Ursache dagegen fast immer die letzte Änderung.
Der zweite Grund ist Verlässlichkeit. Menschen vergessen Schritte, besonders freitagabends. Eine Pipeline führt jedes Mal exakt dieselben Prüfungen aus, in derselben Reihenfolge, ohne Ausnahme. Damit wird das Veröffentlichen von einem nervösen Sonderereignis zu einer Routine. Große Anbieter wie Amazon oder Google bringen auf diese Weise mehrere tausend Änderungen pro Tag in den Betrieb.
Für KI-Systeme gilt das Prinzip inzwischen ebenfalls. Dort spricht man von MLOps, also von Pipelines, die nicht nur Programmcode, sondern auch Trainingsdaten und fertige Modelle prüfen und ausliefern. Ein Modell kann formal fehlerfrei sein und trotzdem schlechtere Antworten geben als sein Vorgänger. Deshalb enthalten solche Pipelines zusätzliche Qualitätsmessungen.
Die Stufen des Fließbands
Alles beginnt in einem gemeinsamen Speicher für den Programmcode, meist verwaltet mit dem Werkzeug Git. Lädt jemand eine Änderung dorthin hoch, startet die Pipeline automatisch. Der erste Schritt ist der Build: aus dem geschriebenen Text wird ein ausführbares Programm gebaut. Scheitert schon das, bricht alles sofort ab und die Person bekommt eine Nachricht.
Danach folgen die Tests. Das sind kleine Zusatzprogramme, die prüfen, ob einzelne Funktionen noch das Richtige tun. Ein Test könnte etwa fragen, ob die Warenkorb-Summe bei drei Artikeln stimmt. Zusätzlich laufen oft Sicherheitsprüfungen, die nach bekannten Schwachstellen suchen. Erst wenn alle Prüfungen grün sind, geht es weiter.
Im letzten Abschnitt wird die geprüfte Version ausgeliefert. Bei Continuous Delivery ist sie bereit, ein Mensch drückt aber noch den letzten Knopf. Bei Continuous Deployment entfällt auch dieser Knopf. Häufig bekommt zuerst nur ein Prozent der Nutzer die neue Version, damit Probleme früh auffallen. Zeigen die Messwerte Fehler, schaltet das System automatisch zurück auf die alte Version.
Grüne und rote Häkchen im Entwickleralltag
Wer auf der Plattform GitHub ein Softwareprojekt anschaut, sieht neben jeder Änderung ein grünes Häkchen oder ein rotes Kreuz. Das ist das Ergebnis einer CI/CD-Pipeline. Der zugehörige Dienst heißt dort GitHub Actions, bei anderen Anbietern GitLab CI, Jenkins oder CircleCI. Konfiguriert werden diese Pipelines über eine Textdatei im Projekt, in der die Schritte aufgelistet sind.
In Wirtschaftsnachrichten taucht der Begriff meist im Umfeld von DevOps und Cloud-Diensten auf. Firmen begründen Investitionen gern mit kürzerer Zeit bis zur Marktreife. Auch nach großen Ausfällen ist die Pipeline ein Thema, etwa wenn eine fehlerhafte Aktualisierung weltweit Rechner lahmlegt. Die Frage lautet dann, warum die Prüfstufen das nicht abgefangen haben.
Ein verbreiteter Irrtum ist, eine Pipeline garantiere fehlerfreie Software. Sie prüft nur das, was jemand als Test hineingeschrieben hat. Schlechte Tests bedeuten grüne Häkchen bei kaputtem Programm. Die Automatisierung verschiebt die Verantwortung also, sie hebt sie nicht auf.
