Release on Demand ist der letzte Schritt in der SAFe for DevOps Continuous Delivery Pipeline, und es ist der Schritt, der alles zusammenführt. In diesem Video erkläre ich, wie Release on Demand funktioniert, warum die Trennung von Deployment und Release so wirkungsvoll ist und wie die gesamte Pipeline Organisationen befähigt, das Richtige richtig zu bauen.
Die Continuous Delivery Pipeline#
Bevor wir zu Release on Demand kommen, möchte ich den Kontext setzen. Die Continuous Delivery Pipeline besteht aus vier grossen Phasen: Continuous Exploration, Continuous Integration, Continuous Deployment und Release on Demand.
Alles beginnt mit guten Ideen vom Business oder vom Kunden. Wir extrahieren die Hypothese hinter jeder Idee und erfassen sie in einem Epic Hypothesis Statement. In der Continuous Exploration arbeiten wir zusammen, um das echte Kundenbedürfnis zu identifizieren, die minimale Architektur zu entwerfen und das Epic in Features für das Backlog herunterzubrechen.
In der Continuous Integration werden Features in User Stories zerlegt, entwickelt, in die Versionskontrolle committed, gebaut, mit statischer Analyse und Unit Tests getestet. Das resultierende deploybare Artefakt wird End-to-End getestet und in eine Staging-Umgebung für die finale Validierung deployed.
Im Continuous Deployment deployen wir unsere Änderungen kontinuierlich in die Produktion, mit dem Feature Toggle ausgeschaltet. Wir überprüfen, dass alles funktioniert, und bauen Monitoring und Alerting auf, um auf alles reagieren zu können.
Was Release on Demand besonders macht#
Hier wird es spannend. Zu diesem Zeitpunkt haben wir neue Funktionalität kontinuierlich in die Produktion deployed, aber mit dem Feature Toggle ausgeschaltet. Kein Kunde sieht sie noch. Jetzt liegt es am Business zu entscheiden, wann der richtige Zeitpunkt ist, die neue Funktionalität freizugeben.
Neue Funktionalität freizugeben ist eine Geschäftsentscheidung. Das Business entscheidet, wann, für welche Nutzer und für wie viele Nutzer released wird.
Das ist das grundlegende Prinzip: Deployment und Release sind getrennte Aktivitäten. Deployment bringt kompilierten Code in die Produktion mit dem Feature Toggle ausgeschaltet. Release schaltet den Feature Toggle ein. Diese Trennung macht Release on Demand möglich.
Die vier Aktivitäten von Release on Demand#
Release on Demand besteht aus vier Aktivitäten:
Release: Wenn das Business sagt, der Zeitpunkt ist richtig, schalten wir den Feature Toggle ein. Das kann innerhalb von Sekunden geschehen. Die neue Funktionalität wird für eine Teilmenge der Nutzer oder für alle Nutzer verfügbar.
Stabilize: Nach dem Release überwachen wir das System genau und reagieren auf alle Alerts. Wir betreiben und stabilisieren die Produktionsumgebung, um sicherzustellen, dass wir unsere SLAs erfüllen.
Measure: Wir gehen zurück zur Hypothese, die wir in der Explorationsphase identifiziert haben. Wir hatten auch Leading Indicators definiert, die uns zeigen, ob die Hypothese wahr oder falsch ist. Jetzt messen wir den tatsächlichen Geschäftswert und alle Daten, die zeigen, ob unsere Hypothese standhält.
Learn: Mit den Messdaten entscheiden wir, ob wir mehr oder weniger in dieses Epic investieren. Sollen wir weitermachen? Sollen wir stoppen? Sollen wir mehr Features umsetzen oder aufhören? Diese Informationen fliessen zurück in die Continuous Exploration, wo wir neue Hypothesen oder neue Features basierend auf dem Gelernten erstellen.
Wie schnell kann dieser Zyklus sein?#
Diese Frage bekomme ich oft gestellt: Wie gross ist die Lead Time für den gesamten Zyklus? Die Antwort hängt von der Grösse der Idee ab.
Ein konkretes Beispiel: Stellen wir uns vor, wir haben eine Website, und Kunden geben das Feedback, dass der Workflow zu lang ist. Sie wünschen sich einen schnelleren Workflow. Wir erstellen eine Hypothese, identifizieren das Kundenbedürfnis, entwerfen die minimale Architektur, brechen es in Features und User Stories herunter, entwickeln den Code, committen, bauen, testen, deployen in die Staging-Umgebung und deployen kontinuierlich in die Produktion mit dem Feature Toggle ausgeschaltet.
Bis zu diesem Punkt wurde keine neue Funktionalität an Kunden geliefert. Wir sind nur durch die Pipeline gegangen. Dieser gesamte Zyklus von der Exploration bis zum Deployment kann an einem einzigen Tag geschafft werden, wenn man sehr schnell ist. Üblicherweise dauert es aber einen Sprint (zwei Wochen) oder zwei Sprints (etwa vier Wochen).
Nun ist die Funktionalität bereits in der Produktion. Wenn das Business “los” sagt, schalten wir den Feature Toggle ein. Das dauert Sekunden. Die Lead Time für kleine Ideen kann also nur eine Stunde betragen. Für grössere Ideen vielleicht einen Tag. Für noch grössere einen Zwei-Wochen-Sprint. Und für Ideen mit mehreren Features kann man inkrementell deployen und Features einzeln mit Feature Toggles aktivieren.
Der Geschäftswert von Release on Demand#
Das Ergebnis von Release on Demand ist klar: Sie haben Funktionalität released und Geschäftswert an Ihre Kunden geliefert. Was Sie sicherstellen müssen, ist, dass Ihre Produktionsumgebung stabil, zuverlässig, verfügbar, wartbar und sicher bleibt. Sie müssen Ihre SLOs und SLAs erfüllen.
Während Release on Demand sammeln Sie sowohl qualitatives als auch quantitatives Feedback von Kunden und von Ihrem Monitoring-System. Dieses Feedback sagt Ihnen, ob die Hypothese hinter der Idee gültig ist. Es befähigt Sie, fundierte Entscheidungen zu treffen, ob Sie mehr oder weniger in Epics und Features investieren.
Durch das Deployment kleiner Mengen neuer Funktionalität mit ausgeschaltetem Feature Toggle bleibt das Risiko gering. Und das Business bekommt die Möglichkeit zu entscheiden, wann der Zeitpunkt richtig ist, um den Impact neuer Funktionalität und den Wert für Nutzer zu maximieren.
Kernaussagen#
- Deployment und Release trennen. Deployment bringt Code in die Produktion mit ausgeschaltetem Feature Toggle. Release schaltet den Toggle ein. Diese Trennung gibt dem Business die Kontrolle über den Zeitpunkt.
- Release ist eine Geschäftsentscheidung. Das Business entscheidet wann, für wen und wie breit neue Funktionalität released wird.
- Feature Toggles sind der Enabler. Sie ermöglichen Canary Releases, Dark Launches und inkrementelle Rollouts bei niedrigem Risiko.
- Hypothesen messen. Leading Indicators nutzen, um die ursprüngliche Hypothese basierend auf echten Kundendaten zu validieren oder zu widerlegen, nicht auf Annahmen.
- Die gesamte Pipeline ist ein Lernkreislauf. Von der Hypothese über Release, Messung bis zum Lernen: alles fliesst zurück in die Exploration und befähigt, das Richtige richtig zu bauen.
- Lead Time hängt vom Umfang ab. Kleine Änderungen können in einer Stunde durch die Pipeline fliessen. Grössere Features brauchen einen Sprint. Die Pipeline unterstützt beides.