Operate · Einsatz

CI/CD & Canary Releases: Software sicher in Produktion bringen

Für mich ist Software nicht mit dem Commit fertig. Erst wenn eine Änderung zuverlässig in Produktion läuft, entsteht Nutzen. CI/CD ist der Weg dorthin, Canary Releases sind die Technik, mit der sich das Risiko jeder Auslieferung weiter senken lässt.

DevOps: gemeinsame Verantwortung für die Auslieferung

Von 2017 bis 2018 war ich als Lead DevOps Engineer bei der Audi AG tätig. DevOps bedeutet für mich vor allem eines: Entwicklung und Betrieb tragen gemeinsam die Verantwortung dafür, dass Software beim Nutzer ankommt. Es reicht nicht, Code an ein anderes Team zu übergeben und auf das Beste zu hoffen. Wer eine Änderung schreibt, sollte auch verstehen, wie sie gebaut, getestet, ausgeliefert und betrieben wird.

Diese gemeinsame Verantwortung braucht eine technische Grundlage. Ohne automatisierte, wiederholbare Abläufe bleibt die Zusammenarbeit zwischen Entwicklung und Betrieb ein Lippenbekenntnis. Genau hier setzen Continuous Integration und Continuous Delivery an.

Die CI/CD-Pipeline ist ein eigenes System

Eine CI/CD-Pipeline wird oft als Nebensache behandelt, als ein paar Skripte, die irgendwann einmal jemand geschrieben hat. Ich sehe das anders: Die Pipeline ist ein eigenständiges technisches System, das genauso gepflegt werden muss wie die Anwendung selbst. Sie hat eigene Anforderungen, sie altert und sie braucht Verantwortliche.

Drei Eigenschaften machen eine gute Pipeline aus. Sie ist schnell, damit Entwicklerinnen und Entwickler zeitnah Rückmeldung bekommen und nicht lange auf ein Ergebnis warten. Sie ist nachvollziehbar, sodass jederzeit klar ist, welcher Stand mit welchen Schritten gebaut und ausgeliefert wurde. Und sie bricht sichtbar ab, wenn etwas nicht stimmt. Ein Fehler, der still durchrutscht, ist gefährlicher als ein roter Build, den alle sehen.

Wird die Pipeline so verstanden, verändert sich auch der Umgang mit Releases. Statt seltener, großer Auslieferungen mit vielen Änderungen auf einmal werden kleine Schritte häufig ausgeliefert. Jede einzelne Änderung ist überschaubar, lässt sich leichter prüfen und im Fehlerfall schneller zurücknehmen. Kleine, häufige Releases senken das Risiko – weil jeder mögliche Fehler kleiner und leichter zu finden ist.

Canary Releases: das Prinzip

Der Name stammt aus dem Bergbau. Kanarienvögel reagierten dort früher empfindlicher auf giftige Gase als Menschen und dienten so als Frühwarnsystem. Bei einem Canary Release übernimmt ein kleiner Teil des Nutzer-Traffics diese Rolle.

Das Prinzip ist einfach: Die neue Version einer Anwendung läuft parallel zur alten. Über das Routing wird zunächst nur ein kleiner Anteil der Anfragen an die neue Version geschickt. Verhält sie sich wie erwartet, steigt dieser Anteil schrittweise, bis die neue Version den gesamten Traffic übernimmt. Zeigen sich Probleme, wird zurückgerollt und der Traffic wieder vollständig auf die alte Version gelenkt. Der Fehler bleibt so auf wenige Nutzer begrenzt, statt alle gleichzeitig zu treffen.

Canary Releases ergänzen damit CI/CD: Die Pipeline sorgt dafür, dass eine Änderung zuverlässig gebaut und geprüft wird. Der Canary Release sorgt dafür, dass auch das verbleibende Risiko in Produktion kontrolliert bleibt.

Warum Canary Releases Microservices voraussetzen

Ein Canary Release funktioniert nur, wenn sich einzelne Teile eines Systems unabhängig voneinander ausliefern lassen. Bei einem großen Monolithen müsste immer die gesamte Anwendung in neuer Version parallel betrieben werden – jede noch so kleine Änderung zieht dann das komplette System mit. Microservices mit klar geschnittenen Domänengrenzen erlauben dagegen, genau den Service in neuer Version neben der alten zu starten, der sich tatsächlich geändert hat.

Damit hängen Architektur und Auslieferung eng zusammen. Wer Services so schneidet, dass sie unabhängig voneinander gebaut, getestet und deployt werden können, schafft die Voraussetzung für eine eigene Pipeline pro Service – und für risikoarme Releases über Canary-Routing. Ein gut geschnittener Service ist damit nicht nur fachlich sinnvoll, sondern auch eine Bedingung für sichere Auslieferung.

Von der Theorie zur Praxis: Artikel, Vorträge, Demo-Plattform

2016 veröffentlichte ich einen Fachartikel über Canary Releases in der Zeitschrift Java Aktuell. Das Thema stellte ich außerdem auf Konferenzen vor, darunter JavaOne, Devoxx Poland, W-JAX und Javaland.

Wichtig war mir dabei, das Konzept nicht nur auf Folien zu erklären. Mit der „Very Awesome Microservices Platform“ baute ich eine Plattform, die das Zusammenspiel von Microservices, Pipeline und Canary Release praktisch demonstriert. So lässt sich nachvollziehen, wie eine neue Version neben der alten läuft, wie der Traffic verschoben wird und wie ein Rollback aussieht.

Die Denkweise wirkt bis heute weiter

Das Prinzip hinter Canary Releases ist mehr als eine Deployment-Technik. Es ist eine Haltung: Änderungen in kleinen, überprüfbaren Schritten einführen, früh beobachten und jederzeit zurückkehren können. Diese Denkweise prägt auch meine Arbeit an eigenen Websites wie bernd-zuther.de und ketovavaria.de. Auch dort gilt: lieber viele kleine, risikoarme Anpassungen, die sich einzeln prüfen lassen, als eine große Umstellung, bei der im Fehlerfall unklar bleibt, woran es liegt. Die Infrastruktur dafür baue ich mit Docker und AWS.

Ob Konzernplattform oder eigene Website – zuverlässige Software entsteht dort, wo die Auslieferung als Teil der Entwicklung verstanden wird und nicht als letzter, lästiger Schritt.