Continuous Deployment und Release Management – ein Widerspruch?

Keine Kommentare

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.

  • Seite
  • 1
  • 2

Weitere Inhalte zu Agile Management

Agile Management

Planlos agil

Agile Management

legacy.org => agile.org (Teil 3)

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.