Wenn es um die Scrum-Bereitstellung geht, erwarten die Leute normalerweise eine Release-Ausführung nach dem Ende eines Sprints. Das heißt direkt nach erfolgreicher Demo-Präsentation beim Kunden.
Aber ich habe mich immer gefragt, wie das so eine automatische Erwartung sein konnte. Vor allem, wenn Sie die folgenden möglichen Aktivitäten berücksichtigen, die vor oder nebenher stattfinden müssen.
- Entwickeln und vervollständigen Sie alle Stories innerhalb des Sprints. Einige werden möglicherweise früher abgeschlossen, aber meistens werden die Stories kurz vor dem Ende des Sprints abgeschlossen. Vielleicht sogar nach der Demo-Präsentation, um hier offen zu sein.
- Führen Sie alle geplanten Tests über den Sprint-Inhalt durch, um sicherzustellen, dass der freizugebende Code produktionsbereit ist.
- Informieren Sie sich über entdeckte Fehler und beheben Sie diese rechtzeitig vor der Veröffentlichung.
- Stellen Sie sicher, dass die Bereitstellungspipeline mit den neuesten Inhalten aktualisiert wird und die Pipeline selbst zuverlässig ausgeführt werden kann.
- Führen Sie die Pipeline in allen relevanten Umgebungen aus, um sie sowohl aus der Code- als auch aus der Datenperspektive auf den neuesten Stand zu bringen.
- Bereiten Sie Versionshinweise vor und kommunizieren Sie mit dem Kunden die Auswirkungen der Version und was sich danach genau ändern wird.
- Synchronisieren Sie gegebenenfalls mit anderen parallelen Scrum-Teams, um sicherzustellen, dass die abhängigen Inhalte gleichzeitig veröffentlicht werden. Es sollte nichts fehlen, um sicherzustellen, dass Ihre Release-Inhalte wie erwartet funktionieren.
- Führen Sie darüber hinaus alle Scrum-Zeremonien durch. Nicht nur für den aktuellen Sprint, sondern auch für den nächsten Sprint (z. B. Sitzungen zur Verfeinerung von Geschichten).
Stellen Sie sich nun vor, der Sprint hat zwei Wochen.
Release-Aktivitäten allein erfordern Zeit und Personal, um sie abzuschließen. Aber es darf nicht zu viel sein. Gleich nach dem letzten Tag des Sprints kommt direkt der Tag eins des nächsten Sprints, und der Kreis soll von neuem beginnen.
Sieht die Erwartung der Freigabe nach jedem Sprint immer noch so automatisch aus?
Inhaltsverzeichnis
Inhaltsverarbeitung freigeben
Wenn alle Prozesse innerhalb des Sprints automatisiert sind, besteht die Möglichkeit, einfach „abzudrücken“ und am Ende jedes Sprints die neueste Codeversion in die Produktion zu installieren. Das Problem ist, dass ich noch nie einen so perfekten Zustand des Scrum-Teams erlebt habe.
Wenn es in einigen kleinen Privatunternehmen tatsächlich so ist, beneide ich sie wirklich. Aber die Realität in der Unternehmenswelt sieht so aus, dass ein Scrum-Team diesen Reifegrad nicht erreichen wird. Im Gegensatz dazu sind Release-Prozesse in der Regel mit zeitaufwändigen Aktivitäten verbunden, die den größten Teil des folgenden Sprints erreichen und diesen Sprint inhaltlich und aus allen Metrik-Perspektiven beeinflussen. Die Veröffentlichung ist nur ein stressiger Akt, den niemand im Team gerne durchmacht.
Also war ich, nachdem ich das nächstbeste Szenario für den Umgang mit Veröffentlichungen entdeckt hatte.
Die Schlussfolgerung war, jeden zweiten Sprint zum Release-Sprint zu machen. Hier ist, was es bedeutet.
Separate Code-Version für die nächste Version
Hier geht es um die Handhabung separater Branches im GIT-Repository. Es gibt viele Möglichkeiten, dasselbe Problem anzugehen, und alle können erfolgreich sein. Aber für die Zwecke dieses Artikels werde ich die Dinge einfach halten, um den Ansatz und seine Auswirkungen zu demonstrieren.
Um die laufenden Entwicklungsaktivitäten so gering wie möglich zu beeinflussen, ist es wichtig, die Inhalte für das nächste Release in einen eigenen Zweig zu trennen. Nennen wir es Release Branch. Damit wird folgendes gelöst:
- Das Entwicklungsteam kann seine Aktivitäten fortsetzen und ohne Unterbrechung in die neuen Geschichten des Hauptzweigs einfließen.
- Es besteht kein Risiko, dass der Release-Inhalt durch unerwartete Code-Änderungen des Scrum-Teams beeinträchtigt wird.
- Testaktivitäten können in einem isolierten Raum ausgeführt werden. Hier werden nur Änderungen eingeführt, die zum Lösen des Tests erforderlich sind.
- Da die Release-Pipeline nur die Inhalte aus dem Release-Zweig in der Produktion bereitstellt, haben wir einen klaren Prozess und volle Kontrolle über die zu veröffentlichenden Inhalte. Es kann nicht passieren, dass ein unerwarteter Commit in den Git-Zweig bereits getesteten Code beschädigt.
Halten Sie also einfach den Inhalt der nächsten Veröffentlichung beiseite und lassen Sie ihn zu einem stabilen Zustand abschließen, bereit für die Veröffentlichung.
Timen Sie die Releases so, dass sie wiederholt funktionieren
Ich habe den Ehrgeiz aufgegeben, die Veröffentlichung nach Abschluss jedes einzelnen Sprints durchzuführen. Es war absolut klar, dass dies keine Chance haben würde, zu funktionieren. Zumindest nicht mit Nebenwirkungen wie:
- Auswirkungen auf den nächsten Sprint-Entwicklungsinhalt,
- nicht in der Lage ist, den Release-Inhalt zu stabilisieren,
- Nachholen aller erforderlichen Testaktivitäten usw.
Das Ziel war also, das Release am Ende jedes zweiten Sprints durchzuführen. Das würde folgendes bedeuten:
- Ein Release wird immer Geschichten aus den letzten beiden bereits abgeschlossenen Sprints enthalten. Da das Release innerhalb des aktuellen (aktiven Sprints) durchgeführt wird, ist dieser Sprint-Content noch nicht im Release enthalten.
- Es gibt eine ganze Ein-Sprint-Zeit, um notwendige Testaktivitäten und Fehlerbehebungen abzuschließen.
- Mit dem Non-Release-Sprint hat der Release-Owner ausreichend Zeit, releaserelevante Informationen (Testfälle, Release Notes etc.) zu sammeln. Auf diese Weise können sie grundsätzlich eigenständig arbeiten und den Rest des Entwicklungsteams an neuen Geschichten arbeiten lassen.
- Im Falle einer Fehlerentdeckung kann sich der Release-Besitzer schnell mit dem konkreten Entwickler in Verbindung setzen, um das Problem zu beheben und zum aktuellen Sprint-Inhalt zurückzukehren. Es sollte also immer ein gewisser Prozentsatz der Zeit zur Verfügung stehen, die dem Team zur Verfügung steht, um diese Fehlerbehebung zu unterstützen. Wie viel genau kann im Laufe der Zeit entdeckt werden.
Es ist klar, dass die Benutzer nicht die neuesten Sprint-Inhalte in der neuesten Version erhalten. Aber mit der Zeit wird das irrelevant. Sie erhalten ohnehin zwei Inhaltssprints mit jedem nächsten Release, nach jedem zweiten Sprint.
Dies sieht nach einem guten Kompromiss zwischen schneller Lieferzufriedenheit und der Aufrechterhaltung der Scrum-Aktivitäten ohne nennenswerte Störungen aus.
Führen Sie die Release-Bereitstellung aus
Wenn die Aktivitäten zum Testen, Beheben von Fehlern und zur Vorbereitung der Pipeline erfolgreich abgeschlossen sind, ist es ein recht unkomplizierter Prozess, die Produktionspipeline auszuführen und die Freigabe für die Produktion abzuschließen.
Da es von einem eigenständigen Zweig aus bereitgestellt wird, kann dies im Grunde eine unbemerkte und unsichtbare Aktivität sein. Niemand muss es wissen. Wenn das der Fall ist, ist es die bestmögliche Umsetzung des Release-Deployments.
Voraussetzung dafür ist, eine solide automatisierte DevOps-Pipeline aufgebaut zu haben. Wird nicht nur für die Bereitstellung in der Produktionsumgebung verwendet, sondern auch in allen anderen untergeordneten Umgebungen. Dies kann Entwicklung, Sandbox, Test, Qualitätssicherung, Leistungsumgebung usw. umfassen. Mit einem Klick können alle Lösungen für jede einzelne Umgebung bereitgestellt werden.
Die Freigabe sollte kein Schmerzpunkt oder Stress sein. Oder ein Albtraum, vor dem sich alle fürchten und sich eine Woche lang auf diesen Tag vorbereiten. Nein – stattdessen ist das, wenn es überhaupt niemandem auffällt, das beste Zeichen für eine gelungene Veröffentlichung.
Merge den Release-Branch wieder in den Development-Branch zurück
Der Release-Zweig enthält jetzt einige spezielle Inhalte, die im regulären fortlaufenden Entwicklungszweig nicht vorhanden sind. Es bezieht sich auf alle Korrekturen, die während des Testzeitraums implementiert wurden. Dieser Inhalt muss in den Entwicklungszweig zurückgeführt werden, um sicherzustellen, dass die Korrekturen dort auch nach der nächsten Version verbleiben.
An diesem Punkt dient der neueste Release Branch als Notfall-Produktionscode, der bereit ist, erneut bereitgestellt zu werden. Wenn ein dringendes Problem mit hoher Priorität kurz nach der Produktionsbereitstellung gelöst werden muss, kann es diesen Zweig verwenden. Es ist einfach, diesen Code zu nehmen und den Fix darin zu implementieren. Dies ist immer noch die exakte Kopie des aktuellen Produktionscodes ohne neue unveröffentlichte Inhalte.
Zu Beginn des neuen Testzeitraums kann schließlich der vorherige Release-Zweig gelöscht und durch einen neuen ersetzt werden. Der neue wird wieder als Kopie aus dem aktuellen Entwicklungszweig erstellt.
Etablieren Sie regelmäßige Releases
Und jetzt haben wir es 😀 – einen soliden Prozess, um uns der Veröffentlichung zu nähern. Das einzige, was fehlt, ist die Verpflichtung, es regelmäßig zu halten. In diesem Fall nach jedem zweiten Sprint.
Indem wir es regelmäßig halten, haben wir tatsächlich den Grundstein dafür gelegt, dass es einfacher zu erreichen ist, hauptsächlich weil:
- Wenn die Veröffentlichung nach nicht allzu langer Zeit erfolgt, müssen nicht so viele neue Inhalte in der Produktion installiert werden. Das Inkrement ist klein und gilt als stabil.
- Jetzt bedeutet so viel neuer Inhalt nicht überwältigend viele Testaktivitäten und Testfallerstellung. Weniger Kommunikation, Vereinbarungsanrufe und Zusammenarbeit mit Stakeholdern darüber, was alles neu validiert werden muss. Sie werden auch zustimmen, dass die letzte Veröffentlichung noch nicht lange her ist. Daher wird dieser Aktion weniger Bedeutung beigemessen.
- Das Team wird sich an diesen Zyklus gewöhnen; Mit der Zeit wird es ein natürlicher Teil des Teams sein.
- Als Nebeneffekt werden in Entwicklungs- und Testumgebungen häufig Daten aktualisiert. Das wird sowieso für jeden neuen Prüfzyklus benötigt. Es wird also nicht nur eine weitere geplante Aktivität sein. Vielmehr eine Aktion, die bereits Teil des etablierten Prozesses ist. Dieser Perspektivwechsel hat so viel Einfluss auf die Atmosphäre im Team. Das würde man nicht glauben.
Abschluss
Dieses Kapitel schließt meine bisherigen Beiträge zum Thema Scrum Lifecycle ab. Es geht auch darum, was sich im wirklichen Leben bewährt hat.
Oft starten Teams agil und machen vieles falsch. Dann entwickeln sie sich schließlich und beginnen, die Dinge anders zu machen. Diese Serie könnte einigen von ihnen helfen, diese Änderung schneller zu vollziehen.
Weder ist dieser Release-Ansatz der einzig praktikable noch unproblematisch. Diese wird es weiterhin geben, und die Teams müssen sich damit auseinandersetzen. Dann das Mögliche verbessern und das Unsinnige vergessen.
Aber soweit ich weiß, hat dieser Ansatz, obwohl er einfach ist, bewiesen, dass Veränderungen möglich sind. Von chaotischen, unvorhersehbaren Sprints bis hin zu einer stabileren Bereitstellung mit regelmäßigen Releases, auf die man sich verlassen und mit denen man planen kann. Und es erfordert keine spezielle, hochkomplizierte Methodik – nur einfache Regeln und die Bereitschaft, dem Plan zu folgen.