Der Weg zum kontinuierlichen Release In 5 Schritten zum Continuous Deployment

Anbieter zum Thema

OutSystems

Continuous Deployment ist der Königsweg des Software-Release. Doch viele sehen den Prozess kritisch oder haben Vorbehalte. Fünf Schritte führen allerdings zum kontinuierlichen Release.

Agilität setzt voraus, schnell reagieren zu können. Der Entwicklungsprozess eines Produktes läuft schließlich nie schnurgerade – das Marktumfeld kann sich beispielsweise jederzeit ändern oder Gesetze können neue Rahmenbedingungen schaffen.

Um in der Softwareentwicklung hier schnell Veränderungen begegnen zu können, empfiehlt es sich so professionell einzurichten, dass alle Kapazität sich auf wirklich wertschöpfende Tätigkeiten konzentrieren können. Alles andere sollte vollständig automatisiert ablaufen.

Continuous Deployment ist genau für die Verschlankung der Prozesse entscheidend und hält die Feedbackzyklen so kurz wie möglich. Denn es ist klar: Wenn eine neu entwickelte Funktion beim Nutzer möglichst schnell ankommt, bekommt man auch direktes Feedback – und die Gefahr ein Produkt am Nutzer vorbei zu entwickeln sinkt.

Kurze Begriffsklärung

Continuous Deployment ist die Spitze mehrerer aufeinander aufbauender kontinuierlicher Prozesse. Der erste davon ist Continuous Integration, also die Idee, den Code mehrerer Entwicklerinnen und Entwickler regelmäßig zu mergen und zu kompilieren. So erspart man sich später im Prozess die sprichwörtliche „Merge-Hell”, den großen Integrationsaufwand, wenn sich die Code-Kopien in den Branches zu weit voneinander entfernt haben.

Das Ergebnis ist ein Hauptzweig der Code-Basis, der sowohl kompilierbar ist als auch alle neuesten Entwicklungen beinhaltet. Eine dedizierte Maschine wie Jenkins, Bamboo, TravisCI, oder GitLab CI, die auf Codeänderungen im Hauptzweig achtet und bei Änderungen Kompilier- und Testprozesse ausführt, ist empfehlenswert.

Einen Schritt weiter geht Continuous Delivery. Dabei wird die Software nicht nur kompiliert, sondern direkt in einen auslieferungsfähigen Zustand gebracht. Nach Kompilierung und Test übernimmt eine Deployment-Pipeline, die die Software in einer produktionsähnlichen Umgebung installiert. Dennoch ist weiterhin ein Mensch notwendig, um das Deployment auszulösen.

Continuous Deployment kombiniert alle Prozessschritte aus Continuous Integration und Continuous Delivery und macht Software ohne den Eingriff einer Person direkt für den Kunden verfügbar. Am Ende steht ein Prozess, der die Arbeit für Developer vereinfacht und das Ausrollen neuer Software auch für die Anwender ebenso angenehm macht. Studien haben gezeigt, dass im Idealfall der Prozess so optimiert ist, dass alle Beteiligten mehr Zeit für wertschöpfende Arbeit haben.

Schritt 1 – Automatisierung aller Prozesse

Automatisierte Deployments sind sicherer und schneller als manuelle Handgriffe. Deshalb ist der erste Schritt zum kontinuierlichen Deployment gleichwohl eine gute Investition: Die vollständige Automatisierung aller Deployments. Das lohnt sich selbst für jeden, der sich noch nicht an Continuous Deployment herantraut.

Ziel ist es, einen sicheren Prozess zu entwickeln, sodass auch kurz vor Feierabend noch ein Bugfix vorgenommen werden kann, ohne sich Sorgen zu machen, einen größeren Schaden anzurichten. Natürlich ist es empfehlenswert, der Continuous-Integration-Umgebung nicht von Anfang an blind zu vertrauen. Um auf Nummer sicher zu gehen, kann auch jederzeit von einer lokalen Maschine deployed werden. Nur sollte es sich auch wirklich nur noch um ein ./deploy-Kommando handeln.

Schritt 2 – Tests prüfen und optimieren

Trauen Sie Ihren Tests? Inzwischen kann man bei fast jedem Softwareprojekt davon ausgehen, dass Tests vorhanden sind. Die Qualität der Tests ist lediglich die Krux: Ist ein fehlerfreier Lauf eines Testrunners wirklich so vertrauenswürdig, dass man sich darauf verlassen kann, dass die Software funktioniert?

Zwar ist das Ziel, eine Testabdeckung von 100 Prozent zu erreichen, nicht dogmatisch. Es sollte aber mehr als ein Happy Path überprüft werden, sondern auch gängige Szenarien, die Fehler hervorrufen können. Darüber hinaus sollte die Testlaufzeit kein limitierender Faktor für die Frequenz sein, in der deployed werden kann. Dauert ein Test drei Stunden, dann ist die Gefahr groß, ihn letztlich doch zu überspringen. Dieses nur menschliche Risiko sollte von Beginn an vermieden werden.

Schritt 3 – Review-Prozess

Um frühzeitig zu erkennen, ob ein Feature korrekt umgesetzt wurde, sind schnelle Feedback-Cyclen unerlässlich. Denn die Problematik eines inkorrekt kreierten Features tritt deutlich häufiger auf, als dass es wegen eines Bugs nicht ordentlich funktioniert. Ich persönlich plädiere dafür, regelmäßig gemeinsam im Team mit anderen Entwicklerinnen und Entwicklern auf das funktionierende Produkt zu blicken. Alternativ ist es eine gute Lösung, jedes neue Release hinter einem Feature-Toggle zu veröffentlichen, wenn die entsprechende Infrastruktur vorhanden ist.

Schitt 4 – Observability

Die Kernidee von Observability ist, zu jedem Zeitpunkt zu wissen, ob das System in Ordnung ist und bei Problemen sofort Alarm geschlagen wird – und wenn dies der Fall ist auch die Werkzeuge zur Hand zu haben, um reagieren zu können. Hintergrund ist, dass es bei einer hohen Geschwindigkeit neuer Releases dennoch einen Kontrollmechanismus geben muss, ohne das System manuell prüfen zu müssen.

Üblicherweise werden dafür Tools eingesetzt, die Logs, Metriken und Traces prüfen. Entscheidend ist, dass die dabei entstehenden Daten auch ihren Weg zu den Entwicklerteams finden und berücksichtigt werden. Die Praxiserfahrung hat gezeigt, dass es sich lohnt zwei Personen jeden Tag zufällig auszuwählen, um anhand einer Checkliste zu prüfen, ob das Programm in den letzten 24 Stunden brav getan hat, was es soll.

Schritt 5 – Release Prozess verbessern

Im Mittelpunkt der Continuous Deployment Strategie steht selbstverständlich der Release-Prozess. Bei mehr als 20 Auslieferungen am Tag sind Schwächen im Prozess kaum mehr akzeptabel. Es gibt einige Konzepte, die dabei unterstützen können und gemeinsam den Release-Prozess widerstandsfähig genug macht:

Rolling Update: Es ist notwendig, die Anwendung in mehreren Instanzen gleichzeitig laufen zu lassen. Wäre dies nicht der Fall, ginge jeder Deploy mit einer kurzen Downtime einher, was keinem Nutzer zuzumuten wäre. Bei einem rollenden Update kann die alte Instanz weiterlaufen und Anfragen beantworten, während die neue Version startet. Nach dem erfolgreichen Start wird der Traffic umgeleitet. Es ist nur zu beachten, dass eventuell beide Versionen für einen gewissen Zeitraum auf die gleichen Datenbanken zugreifen. Eine Datenbankmigration und eine Software-Änderung sollte daher auf zwei Releases aufgeteilt werden.

Rights-Based Releases/Feature Toggles: Ein Werkzeug, um zwei parallele Code-Pfade in der Anwendung zu haben, sind Feature Toggles. Sie erlauben es, über einen „Schalter” zwischen zwei Pfaden hin- und her zu schalten. So können Releases vom Deployment entkoppelt von der Konfigurationsoberfläche aus erfolgen und im Falle eines Fehlers, oder wenn die Änderung nicht gefällt, sehr einfach zur vorherigen Version zurückgekehrt werden. Bei „Rights-Based Releases” wird dies genutzt, um immer mehr Nutzergruppen für ein Feature freizuschalten. Es sollte nur darauf geachtet werden, die Pfade später wieder zu bereinigen.

Canary Deployments: Bugs können immer entstehen – ganz egal wie gut die Testverfahren auch sind. Ein Canary Deployment dient dazu Fehler, die in der Produktion entstehen können, in ihrer Wirkung einzugrenzen. Dazu wird ein Rolling Update in mehreren Instanzen dazu genutzt, ein Teil des Traffics durch eine Engine zu überwachen. Treten bei der neuen Version Warnungen wie HTTP-500-Statuscodes auf, dann wird das Deployment abgebrochen. Das Entwicklerteam wird entsprechend informiert und kann sich der Problematik annehmen. Der Vorteil: Alles was schief gehen kann, findet zunächst nur isoliert statt.

Fazit: Ein Aufwand, der sich lohnt

Wer einmal die Schritte zum Continuous Deployment gewagt hat, wird nicht mehr zurückwollen. Zwar sind die Schritte mit Aufwand in allen Prozessen verbunden, aber es ergibt schließlich eine große Arbeitserleichterung für die Software-Entwicklung.

Wer alle Schritte hinter sich hat und dennoch skeptisch ist, sollte sich nach der Einführung die Zeit nehmen, jedes Mal den Knopf zu drücken, um alle automatisierten Prozesse zu starten. So wird es nach und nach zur Normalität und man kann auch die letzte Hürde zum Continuous Deployment nehmen und alle manuellen Eingriffe entfernen.

* Christian Uhl ist Engineering Manager bei Personio, zuvor war er einige Jahre lang als Senior Software Consultant bei der codecentric AG und als Head of Engineering bei Matmatch GmbH tätig. Mittlerweile hat er eine große Vielfalt an verteilten Systemen gesehen und eine Vielzahl von Fehlern gemacht, die er jetzt teilen kann. Er interessiert sich besonders für verteilte Systeme und Microservices-Architekturen und ist immer neugierig, wie all diese Teile zusammenpassen.

(ID:47371952)