Release ist einer der letzten Schritte im SAFe for DevOps Health Radar. Zu diesem Zeitpunkt ist die neue Funktionalität bereits in der Produktion deployed und verifiziert. Jetzt ist es an der Zeit, die neue Funktionalität einer kleinen Gruppe von Nutzern oder allen Nutzern zugänglich zu machen. In diesem Video erkläre ich, was der Release-Schritt umfasst und warum er eine entscheidende Geschäftsentscheidung ist.
Der Weg zum Release#
Bevor wir zum Release-Schritt gelangen, haben wir die gesamte Continuous Delivery Pipeline durchlaufen. Alles beginnt mit guten Ideen vom Kunden oder Business. Wir extrahieren die Hypothese hinter diesen Ideen und erfassen sie in Epics. Wir forschen gemeinsam, um das echte Kunden- oder Marktbedürfnis zu identifizieren. Wir entwerfen die minimale Architektur, die nötig ist, um die Hypothese zu beweisen. Dann brechen wir das Epic in Features herunter, priorisieren sie und legen sie auf ein Backlog.
Von dort aus entwickeln wir User Stories, committen Quellcode, reintegrieren unsere Änderungen und bauen ein deploybare Artefakt. Dieses Artefakt wird End-to-End getestet, in eine Staging-Umgebung für die finale Verifikation deployed und dann in die Produktion deployed. Wir verifizieren in der Produktion, richten das Monitoring ein und reagieren auf allfällige Probleme. Jetzt sind wir bereit für das Release.
Warum Release eine Geschäftsentscheidung ist#
Die Freigabe neuer Funktionalität ist eine entscheidende Geschäftsentscheidung. Ein zu frühes Release kann grosse Auswirkungen haben, und ein zu spätes Release ebenso. Deshalb gehört die Entscheidung, wann released wird, dem Business und nicht dem Entwicklungsteam.
Genau deshalb trennen wir Deployment von Release. Deployment bringt den kompilierten Code in die Produktion mit dem Feature Toggle ausgeschaltet. Release schaltet den Feature Toggle ein. Durch die Trennung dieser beiden Aspekte geben wir dem Business die Möglichkeit zu entscheiden, wann der richtige Zeitpunkt für das Release neuer Funktionalität ist.
Feature Toggles und Dark Launches#
Ein Feature Toggle ist im Kern nichts anderes als eine If-Anweisung. Wenn das Feature Flag eingeschaltet ist, ist die neue Funktionalität aktiv. Wenn das Feature Flag ausgeschaltet ist, bleibt das bisherige Verhalten bestehen. Dieser einfache Mechanismus ermöglicht es uns, kontinuierlich in die Produktion zu deployen, ohne die Funktionalität für die Nutzer freizugeben.
Dieses Muster wird als Dark Launch bezeichnet. Wir deployen neue Funktionalität in die Produktion, ohne sie für die Nutzer sichtbar zu machen. Das erlaubt uns, das gesamte Monitoring und Alerting einzurichten und zu beobachten, wie sich der neue Code in der Produktion verhält, bevor ihn jemand nutzt. Feature Toggles habe ich im Detail in meinem Video zum Deploy-Schritt behandelt und das Konzept der Architektur für Releasability in meinem Video zum Architect-Schritt.
Architektur für Releasability#
Wenn wir für Releasability architekturieren, betrachten wir unsere Lösung als ein grosses System und zerlegen es in kleinere Teile. Das können Microservices, Komponenten oder jede andere sinnvolle Zerlegung sein. Für jede dieser Komponenten definieren wir eine eigene Deployment- und Release-Strategie.
Zum Beispiel kann eine Komponente mit intensiver Entwicklung alle zwei Wochen neue Funktionalität für die Endbenutzer freigeben. Eine andere Komponente mit weniger Entwicklungsaktivität released nur bei Bedarf, wenn es etwas Sinnvolles zum Releasen gibt. Eine dritte Komponente folgt vielleicht einem monatlichen Release-Rhythmus. Die Gesamtlösung wird möglicherweise vierteljährlich released.
So architekturieren wir für Releasability. Es erfordert die Trennung von Deployment und Release und den Einsatz von Feature Toggles und Dark Launches.
Canary Releases#
Durch die Trennung von Deployment und Release und durch den Einsatz von Feature Toggles und Dark Launches sind wir in der Lage, Canary Releases durchzuführen. Bei einem Canary Release machen wir ein neues Feature nur für eine Teilmenge der Nutzer verfügbar. Diese können die neue Funktionalität in der Produktion testen und uns Feedback geben. Wir können dann schrittweise die Anzahl der Nutzer erhöhen, die Zugang zur neuen Funktionalität haben.
Dieser Ansatz ermöglicht es uns, Probleme sehr früh zu erkennen, und diese Probleme betreffen nur eine kleine Anzahl von Nutzern. Der Begriff “Canary Release” stammt von den Kanarienvögeln, die Bergleute in früheren Zeiten verwendeten. Sie nahmen einen Kanarienvogel mit in die Mine, und wenn der Vogel starb, wussten sie, dass es Zeit war, herauszukommen.
Canary Releases sind weit verbreitet. Vielleicht kennen Sie sie auch unter den Begriffen Alpha-Testing, Beta-Testing oder Friends-and-Family-Release.
Die Reifegrade#
Der SAFe DevOps Health Radar bietet ein Reifegradmodell für den Release-Schritt:
- Sit: Releases sind eng an Deployments gekoppelt und Kunden sind extrem unzufrieden mit der Häufigkeit der Releases.
- Crawl: Releases sind eng an Deployments gekoppelt, aber Kunden sind etwas unzufrieden mit der Häufigkeit der Releases.
- Walk: Release und Deployment sind gekoppelt, aber beide erfolgen kontinuierlich oder bei Bedarf.
- Run: Release ist vom Deployment entkoppelt. Deployed Features werden basierend auf der Geschäftsbereitschaft für die Endbenutzer freigegeben.
- Fly: Deployed Features können für einzelne Segmente der Nutzerpopulation freigegeben werden. Feature Toggles werden refactored, wenn sie nicht mehr benötigt werden.
Kernaussagen#
- Releasing ist eine Geschäftsentscheidung. Nur das Business weiss, wann der richtige Zeitpunkt ist, eine bestimmte Funktionalität für Endbenutzer freizugeben.
- Deployment von Release trennen. Deployment bringt Code in die Produktion mit dem Feature Toggle ausgeschaltet. Release schaltet den Feature Toggle ein.
- Feature Toggles nutzen. Ein Feature Toggle ist einfach eine If-Anweisung, die steuert, ob ein Feature für Nutzer aktiv ist.
- Dark Launches einsetzen. In die Produktion deployen, ohne für Nutzer freizugeben. So können Sie den neuen Code in der Produktion überwachen und validieren, bevor ihn jemand sieht.
- Für Releasability architekturieren. Die Lösung in kleinere Komponenten aufteilen, jede mit ihrer eigenen Deployment- und Release-Strategie.
- Canary Releases nutzen. Features zuerst für eine kleine Teilmenge der Nutzer verfügbar machen, Feedback sammeln und schrittweise an alle ausrollen.