Die ideale CI/CD-Deployment-Pipeline

Bevor wir einsteigen, empfehle ich dir meinen Artikel über die fünf Arten von Softwaretests für zuverlässige Systeme. Auf diese Testkonzepte werde ich im Folgenden immer wieder zurückgreifen.

Beginnen wir mit einem kurzen Überblick: Was ist eine CI/CD-Pipeline, und was macht eine besser als eine andere?

Eine CI/CD-Pipeline automatisiert das Bauen, Testen und Ausliefern von Codeänderungen. Bei Continuous Deployment gelangen Änderungen, die alle erforderlichen Prüfungen bestehen, ohne manuellen Eingriff in die Produktion. Bei Continuous Delivery bleiben die Änderungen jederzeit auslieferbar, die Veröffentlichung in der Produktion kann aber weiterhin manuell angestoßen werden.

Früher wurden Anwendungen häufig von Hand anhand eines detaillierten Runbooks deployt. Das war zeitaufwendig und fehleranfällig. Heute wird Software in immer kürzeren Abständen ausgeliefert. Besonders durch den zunehmenden Einsatz von KI-Agenten beim Programmieren steigt die Zahl der Codeänderungen weiter.

Wenn sich diese Änderungen ansammeln, wird die Fehlersuche schwieriger. Führt ein Release zu einem Bug oder höheren Fehlerraten, kann es bei einem großen Paket an Änderungen Stunden oder sogar Tage dauern, die Ursache zu finden. Kleinere, automatisch geprüfte Deployments machen diese Suche überschaubarer.

Kommen wir also dazu, was eine gute Pipeline ausmacht. Die folgenden Bezeichnungen für die Stufen sind Konventionen, und nicht jede Anwendung braucht jede Umgebung. Jede Stufe sollte uns mehr Sicherheit geben, bevor wir zur nächsten übergehen.

Mit einer Replik ist in diesem Artikel eine laufende Kopie der Anwendung gemeint, egal ob auf einer virtuellen Maschine, in einem Container oder in einem Kubernetes-Pod.

Build und erste Tests

Zunächst brauchen wir einen Build-Prozess, der sicherstellt, dass die Software weiterhin kompiliert, sofern das für die verwendete Sprache zutrifft. Dazu kommen statische Prüfungen wie Linting oder Checkstyle sowie Unit-Tests.

Sind diese Prüfungen erfolgreich, können wir die anwendungsinternen Integrationstests ausführen. Sie prüfen das Zusammenspiel von Komponenten, ohne dass dafür ein Deployment in einer gemeinsam genutzten Umgebung nötig ist. Sie können in einer Testumgebung mit den erforderlichen Abhängigkeiten, Berechtigungen und Zugangsdaten laufen.

Diese Tests verhindern, dass wir etwas deployen, von dem wir bereits wissen könnten, dass es nicht funktioniert. Falls wir Docker verwenden, bauen wir hier auch das Image. Dasselbe Image sollte anschließend alle weiteren Stufen durchlaufen, damit wir genau das deployen, was wir getestet haben.

Alpha oder Pre-Devo

Das erste Deployment erfolgt in Alpha, auch Pre-Devo genannt. Für die ersten Deployment-Prüfungen kann eine einzelne Anwendungsreplik ausreichen.

Diese Stufe prüft, ob die Anwendung korrekt startet und ob Konfiguration, Zugangsdaten und Verbindungen zu ihren Abhängigkeiten in der Umgebung funktionieren. So fallen Einrichtungsprobleme früh auf. Das garantiert allerdings nicht, dass die Zugangsdaten einer anderen Umgebung ebenfalls korrekt eingerichtet sind.

Nach dem Deployment führen wir Integrationstests gegen den Endpunkt oder einen anderen Einstiegspunkt der Anwendung aus. Sind sie erfolgreich, können anschließend Lasttests laufen, sofern vorhanden.

Eine einzelne Replik liefert uns einen Ausgangswert dafür, wie viele Transaktionen pro Sekunde sie unter den getesteten Bedingungen verarbeiten kann. Das Ergebnis hängt von den verfügbaren Ressourcen, den Anfragemustern und den nachgelagerten Abhängigkeiten ab. Es ist deshalb keine vollständige Aussage über die Kapazität in der Produktion.

Hier können wir auch Fault-Injection-Tests durchführen, etwa mit einem Tool wie Gremlin. Mit nur einer Replik lässt sich allerdings nicht prüfen, wie mehrere Repliken reagieren, wenn eine davon ausfällt.

Warum brauchen wir diese Umgebung? Können wir nicht einfach direkt nach Devo deployen?

Devo wird oft gemeinsam von UI/UX-Designern, Produktmanagern und anderen Softwareentwicklern genutzt. Wenn wir ein fehlerhaftes Deployment vorher abfangen, können sie ungestört weiterarbeiten.

Beta oder Devo

Als Nächstes kommt Beta, auch Devo genannt: die gemeinsam genutzte Entwicklungs- und Testumgebung dieser Pipeline.

Diese Stufe sollte mindestens zwei, gegebenenfalls drei Anwendungsrepliken haben. So können wir Deployments testen, während die Anwendung weiterhin Anfragen verarbeitet. Zwei Repliken allein garantieren aber keine hundertprozentige Verfügbarkeit. Während des Deployments muss ausreichend Kapazität verfügbar bleiben. Neue Repliken müssen einsatzbereit sein, und laufende Anfragen müssen abgeschlossen werden können, bevor alte Repliken herunterfahren.

Devo sollte eigene, von der Produktion getrennte Abhängigkeiten haben, beispielsweise Datenbanken.

Nach einem erfolgreichen Deployment führen wir die Integrationstests erneut gegen den Devo-Endpunkt aus. Falls kontinuierliche Canary-Tests vorhanden sind, sollte die Pipeline auch deren erfolgreiche Ergebnisse abwarten. Mit Canary-Tests sind hier regelmäßig ausgeführte synthetische Anfragen gemeint, die wichtige Abläufe der Anwendung prüfen.

Manche Teams ergänzen eine Mindestbeobachtungszeit, die sogenannte Bake Time. Währenddessen bleibt die neue Version in der Umgebung, und ein zusammengefasster Alarm überwacht mehrere Fehlersignale. Wird der Alarm ausgelöst, hält die Pipeline an und führt gegebenenfalls automatisch einen Rollback durch.

Dadurch können Probleme auffallen, die erst mit der Zeit sichtbar werden, etwa steigende Fehlerraten oder zunehmende Ressourcenengpässe. Eine kaum genutzte Umgebung liefert allerdings nur begrenzte Erkenntnisse. Neben der verstrichenen Zeit sind deshalb erfolgreiche Prüfungen und ausreichend Aktivität wichtig.

Teams sollten weiterhin Tests für bisher nicht abgedeckte Anwendungsfälle ergänzen, statt darauf zu vertrauen, dass jemand zufällig ein Problem bemerkt. Die Bake Time ergänzt diese Tests, indem sie auch verzögert auftretenden Fehlern Zeit gibt, sichtbar zu werden.

Gamma oder Pre-Prod

Die nächste Stufe ist Gamma, auch Pre-Prod genannt. Hier testen wir die Anwendung mit Abhängigkeiten, Konfigurationen und Datenstrukturen, die der Produktion möglichst nahekommen.

Das bedeutet nicht zwangsläufig, dass wir die Anwendung mit der tatsächlichen Produktionsdatenbank, dem produktiven Elasticsearch-Cluster oder den produktiven Speicherressourcen verbinden. Gemeinsam genutzte Ressourcen würden es ermöglichen, dass Code und Tests aus der Vorproduktionsumgebung die Produktion beeinträchtigen. Meist sind getrennte Ressourcen mit repräsentativen Daten und passenden Schemata die bessere Wahl.

Warum ist das wichtig? Wir wollen wissen, ob der neue Code mit den Datenstrukturen kompatibel ist, auf die er in der Produktion trifft. Das gilt auch für die Phase, in der alte und neue Versionen gleichzeitig laufen.

Die Kompatibilität muss außerdem einen Rollback ermöglichen: Die vorherige Version muss weiterhin mit Daten umgehen können, die von der neuen Version geschrieben wurden. Erfolgreiche Tests gegen ein bestehendes Schema allein weisen das noch nicht nach.

Integrationstests, kontinuierliche Canary-Tests und eine Bake Time gehören auch in diese Stufe. Finden wir ein Kompatibilitätsproblem, stoppen wir, bevor Kunden mit der neuen Version in Berührung kommen.

OneBox oder One-Pod in der Produktion

Als Nächstes kommt OneBox beziehungsweise One-Pod: Ein kleiner Teil der Produktionsumgebung läuft bereits mit der neuen Version.

Während des Updates nehmen wir die ausgewählte Replik aus der Anfrageverteilung oder ersetzen sie durch eine neue. Sobald sie einsatzbereit ist, nehmen wir sie wieder auf, sodass sie einen begrenzten Anteil echter Kundenanfragen erhält.

Das begrenzt die Auswirkungen von Problemen, die erst unter Produktionsbedingungen auftreten.

Die Metriken dieser Replik sollten gekennzeichnet oder separat erfasst werden, damit wir ihr Verhalten vom Rest der Produktion unterscheiden können. Andernfalls können Fehler einer einzelnen Replik in unauffälligen Durchschnittswerten der gesamten Umgebung untergehen.

Gegen ihren eigenen Endpunkt können wir Integrationstests ausführen, die für den Produktionsbetrieb geeignet sind. Mindestens müssen die Canary-Tests tatsächlich die neue Version prüfen. Außerdem sollten wir sie während einer Bake Time beobachten, mit einem zusammengefassten Alarm auf Basis ihrer Metriken. Erfolgreiche Prüfungen ausschließlich gegen alte Repliken sagen uns nichts über das neue Deployment.

Tritt ein Problem auf, stoppen wir den Rollout und führen zügig einen Rollback durch, sofern das sicher möglich ist. Das Zurücksetzen des Codes macht Änderungen, die er bereits an Daten vorgenommen hat, nicht automatisch rückgängig.

Produktion

Zum Schluss rollen wir die Änderung auf die übrigen Produktionsrepliken aus. Dabei muss während des gesamten Deployments ausreichend funktionierende Kapazität verfügbar bleiben.

Canary-Tests und Alarmüberwachung laufen während des Rollouts und der anschließenden Bake Time weiter. Tritt ein Problem auf, sollte der weitere Rollout gestoppt und zeitnah ein sicherer Rollback eingeleitet werden.

Diese Pipeline soll auf jeder Stufe mehr Sicherheit schaffen und gleichzeitig die Auswirkungen fehlerhafter Änderungen begrenzen. Jede Stufe sollte helfen, dieselbe Frage zu beantworten: Haben wir genügend Anhaltspunkte dafür, dass wir diese Änderung sicher weiter ausrollen können?

Deployment-Zeitfenster für OneBox und Produktion

Für die Freigabe nach OneBox und in die übrige Produktion sollte eine zeitliche Sperre gelten. Deployments dürfen nur während der Arbeitszeiten des zuständigen Teams stattfinden und niemals am Freitag beziehungsweise am letzten Arbeitstag der jeweiligen Arbeitswoche.

Das Zeitfenster sollte genug Zeit lassen, um das Deployment zu beobachten und bei Problemen zu reagieren, bevor das Team Feierabend macht. Erreicht eine Änderung eine dieser Stufen außerhalb des Zeitfensters, wartet sie bis zum nächsten zulässigen Zeitraum. Eine erfolgreich durchlaufene OneBox-Stufe hebt die zeitliche Sperre für den weiteren Produktionsrollout nicht auf.

Diese Sperre gilt für das weitere Ausrollen, nicht für automatische Rollbacks. Verursacht ein Deployment Probleme, sollte die Wiederherstellung sofort beginnen, auch außerhalb der Arbeitszeiten.

Alles zusammenführen

Jede Stufe gibt uns mehr Sicherheit, bevor wir die Änderung auf weitere Teile des Systems ausrollen. Wir beginnen mit Build-Prüfungen und Tests, prüfen die deployte Anwendung in zunehmend realistischen Umgebungen und lassen sie dann über OneBox echte Kundenanfragen verarbeiten. Erst danach folgt die übrige Produktion.

Das folgende Diagramm zeigt diesen Ablauf einschließlich der Deployment-Zeitfenster vor OneBox und Produktion.

Nicht jede Anwendung braucht jede Stufe. Aber jede Stufe sollte ihren Platz dadurch rechtfertigen, dass sie Probleme erkennt, bevor diese größere Auswirkungen haben. Eine gute Pipeline erleichtert das Ausliefern von Änderungen, begrenzt Fehlerfolgen und macht die Wiederherstellung verlässlicher.

Ich habe fast ein Jahrzehnt bei Amazon damit verbracht, solche Tests zu entwerfen und umzusetzen. Wenn du Unterstützung beim Aufbau zuverlässiger Software und eines Release-Prozesses suchst, auf den du dich verlassen kannst, helfe ich dir gerne. Melde dich bei mir.

Hinweis: Dieser Artikel wurde mithilfe von KI aus dem englischen Original ins Deutsche übersetzt.