Continuous Deployment und Release Management – ein Widerspruch?

Von Continuous Integration kommen wir über Continuous Delivery zu Continuous Deployment. Codeänderungen und neue Features werden quasi sofort und automatisch in Produktion gebracht. Release Management und Continuous Deployment scheint sich auf den ersten Blick zu widersprechen.

Anders gefragt: Was hat Release Management mit Continuous Deployment zu tun? Kommt das eine aus der alten Welt, das andere aus der Neuen? Ist Release Management etwas für Manager und Continuous Deployment für Techniker? Wachsen beide Begriff im Zuge von DevOps zusammen? Oder wird Release Management mit Continuous Deployment überflüssig?

Die Einführung von Continuous Integration (CI) dient vor allem dazu, den Entwicklern schnelleres Feedback zu ihren Änderungen zu liefern. CI ist die Voraussetzung für Continuous Delivery , bei dem jede Änderung zu einer auslieferungsfähigen Software führt. Wird jeder Build automatisch bis zur Produktion ausgeliefert sprechen wir von Continuous Deployment .

Was ist Release Management?

Fangen wir mit einer Definition von Release Management an.

Release management is the process of managing, planning, scheduling and controlling a software build through different stages and environments; including testing and deploying software releases.

Im klassischen Sinn besteht Release Management aus allem, was für den Lebenszyklus eines Release notwendig ist. Es fängt also an bei der Definition und Planung, geht über die Entwicklung und Qualitätssicherung und endet nach dem Deployment bei der Wartung. Deployment und Release treten in etwa gleich häufig auf, und das ist kein Zufall. Denn „Release“ bedeutet Freigabe, Freigabe in Produktion. Und wenn nicht ohnehin gleich auf Produktion gefixt wird, unterliegen in der klassischen Welt die Releases (auch von Bugfixes) einer z.T. aufwendigen Freigabeprozedur, inklusive der Sammlung von Unterschriften von Abnahmeberechtigten.

Womit wir beim Ziel vom Release Management wären: Im Weitesten Sinne sollen die Schritte für die Erstellung eines Release formalisiert werden, so dass ein Release planbar und kontrollierbar wird und auf der Zielumgebung ein klar definierter Stand vorhanden ist. ITIL sagt dazu:

ITIL Release & Deployment Management ist verantwortlich dafür, zu planen, festzulegen und zu kontrollieren, wie ein Release getestet und in die Live-Umgebung ausgerollt wird. Das primäre Ziel von Release Management und Deployment Management besteht darin, sicherzustellen, dass die Integrität der Live-Umgebung geschützt wird und dass nur zuvor geprüfte Komponenten ausgerollt werden.

Das Erzeugen eines Release ist mit einem gewissen Aufwand verbunden und kostet Zeit. Je agiler man wird, desto häufiger versucht man, neue Versionen freizugeben. Die Frequenz für neue Features wird erhöht. Während früher neue Versionen oder Features beispielsweise quartalsweise released wurden, dauern Sprints nun nur noch ein bis zwei Wochen. Daher benötigt man in agilen Projekten eine andere Planung von Releases, die weniger zeitaufwendig ist.

Scrum Release Planing: A very high-level plan for multiple Sprints (e.g. three to twelve iteration) is created during the Release planning. It is a guideline that reflects expectations about which features will be implemented and when they are completed. It also serves as a base to monitor progress within the project. Releases can be intermediate deliveries done during the project or the final delivery at the end.

Während z.B. in Scrum jeder Sprint eine lauffähige Software abliefert, markieren Releases jetzt eher eine logische (oder eine aus Sicht des Marketing oder Projektmanagements sinnvolle) Aggregation von Features.

Einfluss von Continuous Delivery und Continuous Deployment

Über den Zwischenschritt Continuous Integration, bei dem über schnelle Build- und Testzyklen den Entwicklern schnelles Feedback geliefert werden soll, kommen wir über Continuous Delivery zu Continuous Deployment. Durch das schnellere Ausliefern wird nicht nur die Liegezeit der eigentlich fertig entwickelten Features reduziert und damit der eigentliche Geschäftswert der Features genutzt. Auch ermöglicht Continuous Delivery und Continuous Deployment einen effizienteren Build-Measure-Learn-Zyklus , weil viel schneller und zielgerichteter der Wert einzelner Änderungen getestet und bewertet werden kann.

Redet man über Continuous Deployment können im Extremfall die Begriffe „Release“ und „Deployment“ verschwimmen, weil bis zu mehrfach täglich auf die Produktionsumgebung deployed wird (z.B. how-we-release-so-frequently ). Differenziert man ein Deployment von einem Release, macht es beispielsweise Sinn ein Deployment als einen technischen Vorgang zu betrachten, der regelmäßig auftritt (ein „non-event“); ein Release hingegen ist ein logisches Konstrukt, nämlich eine Sammlung an Features, und sollte geplant sein. Zum Release gehört u.U. ein Wechsel einer Versionsnummer und eine Definition der enthaltenen Funktionalitäten. Um trotz der vielen Codeänderungen auch unvollständige Features deployen zu können oder gleichzeitig verschiedene Features unabhängig voneinander A/B-Testen zu können, bieten sich Feature Toggles an – aber das ist ein anderes Thema.

Wie ändert sich demnach Release Management beim Übergang zu Agilität und Continuous Deployment?

In klassischen Release-Zyklen mit eher seltenen Releases können in den verschiedenen Phasen folgende Aufgaben anfallen (natürlich dient die Tabelle nur als vereinfachtes Beispiel, insbesondere verdient ein ausführlicher Rollout-Plan eine intensivere Betrachtung):

Tatsächlich besteht ein großer Teil der Arbeit darin, die Unterschiede zwischen der alten und neuen Version festzustellen, die Migration vorzubereiten, das Rollout durchzuführen und den späteren Betrieb sicher zu stellen. Je nach Unternehmen, Produkt und Aufwand kann alleine die Planung und Durchführung für den Releasewechsel Wochen voller Arbeit und seitenweise Planungsdokumente ergeben. Während des Releasewechsels (häufig auch Rollout-Wochenende genannt) sind alle Beteiligten auf Bereitschaft, um auf Benachrichtigung ihre Schritte des Rollouts durchzuführen. Schließlich sind unterschiedliche Teams für z.B. Datenbank, Applicationserver, Konfiguration oder Infrastruktur verantwortlich. Die anschließenden Tage oder Wochen sind vorgesehen, um das neue Release zu stabilisieren, häufig mit einem enormen Aufwand an Überstunden (The Manager’s Guide to Continuous Delivery, Andrew Philips et al, 2014 Xebia B.V.).

Beim Wechsel zu agilen Methoden und Continuous Deployment werden die Inkremente kleiner, so dass dieser Aufwand für jedes Release nicht mehr betrieben werden kann und soll. Vermieden wird das zum einen durch Automation im Deploymentprozess, wodurch auch das Risiko für Fehlschläge minimiert wird, als auch durch die laufenden Anpassungen an Operating (Stichwort DevOps) und Support. Die folgende Tabelle zeigt, in welcher Form bzw. welchen Phasen der agilen Softwareentwicklung dieselben Aufgaben ausgeführt werden:

Aus dieser Darstellung der anfallenden Aufgaben lassen sich positive Ergebnisse herauslesen: Da viele formale Schritte komplett entfallen, können sich die Beteiligten auf ihre eigentlichen, Mehrwert-schaffenden Aufgaben konzentrieren. Management bzw. Product Owner plant und überprüft die zu entwickelnden Features, die Entwicklungsteams und Operating sorgen für die Implementierung, Bereitstellung und Funktionsfähigkeit.

Während die zu entwickelnden Features in der Sprint-Planung durch den Product Owner (Scrum) vorgegeben werden und dieser ebenso verantwortlich ist, die zu messenden geschäftsrelevanten Erfolgskriterien festzulegen und im Nachhinein zu überprüfen, liegen alle anderen Schritte in der Verantwortung der Entwickler: Zur Entwicklung eines Features und der „Definition of Done“ gehört eben nicht nur der getestete Code, sondern auch die Ressourcen, um das Feature automatisch deployen zu können. Dazu können Datenbankscripte, Shellscripte, Dockerimages oder Einstellungen im Build- oder Deploymenttool gehören (wie z.B. in Jenkins oder XL Deploy ).

Zusammenfassung

Das Einführen von agilen Methoden mit kürzen Release-Zyklen ist nicht nur vorteilhaft ist, um die Qualität der Software zu erhöhen indem Entwickler schnelleres Feedback bekommen. Durch häufigere Releases wird zwangsläufig die Automation und dadurch die Qualität erhöht, Aufwand und Risiko dafür gesenkt. Dadurch wird Release Management nicht unnötig, sondern konzentriert sich auf die Mehrwert-liefernden Aufgaben: Die benötigten Features zu planen und über den Build-Measure-Learn-Zyklus auszuwerten. Zudem kann man sehen, dass Continuous Deployment nicht nur auf technischer Ebene stattfindet, sondern den gesamten Software-Lifecycle und die Unternehmenskultur beeinflusst, in dem es die verschiedenen Rollen enger zusammenarbeiten lässt.