Die Herausforderungen der Sprint-basierten Releases
Oftmals wird im Kontext von Scrum erwartet, dass ein Release unmittelbar nach dem Ende eines Sprints erfolgt, typischerweise im Anschluss an eine erfolgreiche Präsentation vor dem Kunden. Diese Erwartung wirft jedoch Fragen auf, insbesondere wenn man die zahlreichen Aktivitäten berücksichtigt, die vor oder parallel zu einem Release anfallen.
Es gilt nämlich zu bedenken:
- Die Entwicklung und Fertigstellung aller User Stories innerhalb des Sprints. Zwar werden einige frühzeitig abgeschlossen, viele jedoch erst kurz vor dem Sprintende oder gar nach der Demo.
- Die Durchführung aller erforderlichen Tests, um sicherzustellen, dass der Code produktionsreif ist.
- Die Identifizierung und Behebung von Fehlern innerhalb eines angemessenen Zeitrahmens.
- Die Aktualisierung der Deployment-Pipeline und die Gewährleistung deren zuverlässiger Ausführung.
- Die Durchführung der Pipeline in allen relevanten Umgebungen, um Code und Daten auf den neuesten Stand zu bringen.
- Die Erstellung von Release-Notes sowie die Kommunikation von Auswirkungen und Änderungen an den Kunden.
- Die Synchronisation mit anderen Scrum-Teams, um die gleichzeitige Veröffentlichung von Abhängigkeiten zu garantieren.
- Die Durchführung sämtlicher Scrum-Zeremonien, nicht nur für den aktuellen, sondern auch den folgenden Sprint.
Wenn man nun die übliche Sprintdauer von zwei Wochen betrachtet, wird deutlich, dass die Release-Aktivitäten selbst Zeit und Personal beanspruchen. Dies kollidiert mit dem unmittelbar anschließenden Start des nächsten Sprints. Ist die Erwartung eines Releases nach jedem Sprint unter diesen Umständen wirklich noch so automatisch?
Die Verarbeitung von Release-Inhalten
Theoretisch wäre es möglich, die neueste Codeversion am Ende jedes Sprints per Knopfdruck in die Produktion zu befördern, vorausgesetzt, alle Prozesse sind automatisiert. In der Praxis ist ein solcher Idealzustand jedoch selten anzutreffen. Vor allem in größeren Unternehmen erweist sich der Release-Prozess oft als zeitintensiv und kann sogar den darauffolgenden Sprint beeinflussen. Die Veröffentlichung wird somit oft als stressige Belastung wahrgenommen.
Ausgehend von dieser Realität wurde ein alternatives Szenario für den Umgang mit Releases erarbeitet: die Definition jedes zweiten Sprints als Release-Sprint.
Separate Code-Version für das nächste Release
Dabei geht es um die separate Handhabung von Branches im GIT-Repository. Es gibt unterschiedliche Ansätze für diese Vorgehensweise, die alle ihre Berechtigung haben. Hier soll ein einfacher Weg aufgezeigt werden, um das Prinzip zu verdeutlichen.
Um die laufenden Entwicklungsaktivitäten möglichst wenig zu beeinträchtigen, werden die Inhalte für das nächste Release in einen eigenen Branch, dem sogenannten Release-Branch, ausgelagert. Dies hat folgende Vorteile:
- Das Entwicklungsteam kann ohne Unterbrechung am Haupt-Branch weiterarbeiten.
- Es besteht kein Risiko, dass Release-Inhalte durch unerwartete Code-Änderungen beeinträchtigt werden.
- Testaktivitäten können in einem isolierten Bereich durchgeführt werden, in dem nur Änderungen zur Behebung von Testproblemen vorgenommen werden.
- Die Release-Pipeline stellt nur Inhalte aus dem Release-Branch bereit, was einen klaren und kontrollierbaren Prozess ermöglicht.
Durch die separate Behandlung der Release-Inhalte können diese in Ruhe stabilisiert werden, bevor sie veröffentlicht werden.
Regelmäßige Releases planen
Die Idee, nach jedem Sprint ein Release zu veröffentlichen, wurde verworfen. Es wurde deutlich, dass dieser Ansatz nicht praktikabel ist, da er zu Problemen wie der Beeinträchtigung des nächsten Sprints, fehlender Stabilisierung der Inhalte und dem Aufholen von Testaktivitäten führte.
Das neue Ziel war es, das Release am Ende jedes zweiten Sprints durchzuführen. Die Vorteile dieses Ansatzes:
- Jedes Release enthält Inhalte der letzten beiden Sprints. Da die Veröffentlichung innerhalb des aktuellen Sprints stattfindet, sind dessen Inhalte nicht enthalten.
- Es steht ein ganzer Sprint für Tests und Fehlerbehebungen zur Verfügung.
- Der Release-Owner hat genügend Zeit, um Informationen zu sammeln (Testfälle, Release Notes). Er kann weitestgehend selbstständig arbeiten und das Entwicklerteam an neuen Inhalten arbeiten lassen.
- Bei Fehlern kann sich der Release-Owner direkt an den verantwortlichen Entwickler wenden, um das Problem zu beheben.
Zwar erhalten die Benutzer nicht die aktuellsten Inhalte jedes Sprints, aber im Laufe der Zeit wird dies irrelevant, da sie ohnehin zwei Sprintinhalte mit jedem Release bekommen.
Dieser Ansatz stellt einen guten Kompromiss zwischen schneller Lieferung und der Aufrechterhaltung der Scrum-Aktivitäten ohne wesentliche Störungen dar.
Release-Bereitstellung durchführen
Nach erfolgreichem Abschluss der Test-, Fehlerbehebungs- und Pipeline-Vorbereitungsaktivitäten ist die Ausführung der Produktionspipeline und die Freigabe für die Produktion ein relativ einfacher Prozess.
Da die Bereitstellung über einen separaten Branch erfolgt, kann sie unbemerkt im Hintergrund stattfinden. Wenn dies der Fall ist, wird die Release-Bereitstellung bestmöglich umgesetzt.
Voraussetzung dafür ist eine solide automatisierte DevOps-Pipeline. Diese sollte nicht nur für die Produktionsumgebung, sondern auch für alle untergeordneten Umgebungen (Entwicklung, Sandbox, Test, QA etc.) genutzt werden. Mit einem Klick sollte es möglich sein, Lösungen in allen Umgebungen bereitzustellen.
Das Release sollte weder schmerzhaft noch stressig sein. Wenn die Veröffentlichung reibungslos und unbemerkt erfolgt, ist dies das beste Zeichen für eine erfolgreiche Umsetzung.
Release-Branch zurück in den Development-Branch mergen
Der Release-Branch enthält nach der Testphase spezielle Inhalte (Fehlerbehebungen), die im regulären Entwicklungsbranch nicht vorhanden sind. Diese Inhalte müssen zurückgeführt werden, um sicherzustellen, dass die Korrekturen auch in zukünftigen Versionen erhalten bleiben.
Der Release-Branch dient nun als Notfall-Produktionscode, der im Bedarfsfall erneut bereitgestellt werden kann, insbesondere bei dringenden Problemen nach der Produktion. Es ist die exakte Kopie des aktuellen Produktionscodes ohne neue, unveröffentlichte Inhalte.
Zu Beginn der nächsten Testphase kann der alte Release-Branch gelöscht und durch eine neue Kopie des Entwicklungsbranch ersetzt werden.
Regelmäßige Releases etablieren
So ist ein stabiler Prozess für die Veröffentlichung entstanden. Das einzige, was noch fehlt, ist die regelmäßige Umsetzung, im Idealfall nach jedem zweiten Sprint.
Die Regelmäßigkeit vereinfacht den Prozess erheblich, da:
- Bei häufigen Releases sind weniger neue Inhalte zu installieren, was die Stabilität erhöht.
- Weniger neue Inhalte bedeuten weniger Testaufwand und weniger Kommunikationsbedarf mit Stakeholdern.
- Das Team gewöhnt sich an den Zyklus, der im Laufe der Zeit zu einem natürlichen Bestandteil der Arbeit wird.
- Die Daten in den Entwicklungs- und Testumgebungen werden regelmäßig aktualisiert. Das ist sowieso für jeden Testzyklus notwendig.
Zusammenfassung
Dieser Ansatz schließt bisherige Ausführungen zum Thema Scrum-Lifecycle ab und basiert auf realen Erfahrungen.
Agile Teams starten oft mit Fehlern, entwickeln sich aber weiter und optimieren ihre Prozesse. Diese Ausführungen könnten einigen Teams helfen, diese Entwicklung schneller zu vollziehen.
Dieser Release-Ansatz ist weder der einzig praktikable noch fehlerfrei. Es wird immer Herausforderungen geben, mit denen sich Teams auseinandersetzen und die sie verbessern müssen.
Dieser einfache Ansatz hat jedoch gezeigt, dass Veränderungen möglich sind, von chaotischen Sprints hin zu einer stabileren Bereitstellung mit regelmäßigen Releases. Dies erfordert keine komplizierte Methodik, sondern einfache Regeln und die Bereitschaft, dem Plan zu folgen.