Ausführen des Scrum-Release – Von der Vorbereitung der Inhalte bis zur Bereitstellung

Wenn es um Scrum geht, erwartet man in der Regel eine Release-Ausführung nach dem Ende eines Sprints. Das heißt, direkt nach einer erfolgreichen Demo-Präsentation für den Kunden.

Aber ich habe mich immer gefragt, wie dies eine so automatische Erwartung sein kann. Vor allem, wenn Sie die folgenden möglichen Aktivitäten berücksichtigen, die vorher oder parallel dazu stattfinden müssen.

• Entwickeln und schließen Sie alle Stories innerhalb des Sprints ab. Einige werden vielleicht schon früher fertig, aber meistens werden die Stories erst kurz vor Ende des Sprints fertiggestellt. Vielleicht sogar nach der Demo-Präsentation, um hier offen zu sein.
• Führen Sie alle geplanten Tests über den Inhalt des Sprints durch, um sicherzustellen, dass der zu veröffentlichende Code produktionsreif ist.
• Kümmern Sie sich um entdeckte Fehler und beheben Sie sie rechtzeitig vor der Veröffentlichung.
• Stellen Sie sicher, dass die Deployment-Pipeline 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 Code- als auch aus Datensicht auf den neuesten Stand zu bringen.
• Bereiten Sie Versionshinweise vor und kommunizieren Sie mit dem Kunden über die Auswirkungen der Version und was sich danach genau ändern wird.
• Stimmen Sie sich gegebenenfalls mit anderen parallel arbeitenden Scrum-Teams ab, um sicherzustellen, dass die abhängigen Inhalte gleichzeitig freigegeben werden. Es sollte nichts fehlen, um sicherzustellen, dass Ihr Release-Inhalt wie erwartet funktionieren wird.
• Darüber hinaus sollten Sie alle Scrum-Zeremonien durchgehen. Nicht nur die, die sich auf den aktuellen Sprint beziehen, sondern auch die, die für den nächsten Sprint vorgesehen sind (z.B. die Sitzungen zur Verfeinerung der Stories).

Stellen Sie sich nun vor, der Sprint hat zwei Wochen.

Release-Aktivitäten an sich benötigen Zeit und Menschen, um abgeschlossen zu werden. Aber es darf nicht zu viel Zeit in Anspruch nehmen. Gleich nach dem letzten Tag des Sprints kommt direkt der erste Tag des nächsten Sprints, und der Kreislauf beginnt von neuem.

Sieht die Erwartung einer Veröffentlichung nach jedem Sprint immer noch so automatisch aus?

Inhaltliche Bearbeitung der Freigabe

Wenn alle Prozesse innerhalb des Sprints automatisiert sind, besteht die Möglichkeit, am Ende eines jeden Sprints einfach “den Abzug zu drücken” und die neueste Codeversion in die Produktion zu übernehmen. Das Problem ist, dass ich einen solchen perfekten Zustand des Scrum-Teams noch nie erlebt habe.

Wenn dies in einigen kleinen Privatunternehmen tatsächlich der Fall ist, dann beneide ich sie wirklich. Aber die Realität in der Unternehmenswelt ist, dass ein Scrum-Team diesen Reifegrad nicht erreichen wird. Im Gegenteil, Release-Prozesse sind in der Regel mit zeitaufwändigen Aktivitäten verbunden, die sich über einen Großteil des folgenden Sprints erstrecken und diesen Sprint inhaltlich und in Bezug auf alle Metriken beeinträchtigen. Die Freigabe ist einfach ein stressiger Akt, den niemand im Team gerne mitmacht.

Also habe ich nach dem nächstbesten Szenario für den Umgang mit Releases gesucht.

Die Schlussfolgerung war, jeden zweiten Sprint zum Release-Sprint zu machen. Das bedeutet Folgendes.

Separate Codeversion für die nächste Version

Hier geht es um den Umgang mit separaten Zweigen im GIT-Repository. Es gibt viele Möglichkeiten, das gleiche 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 wenig wie möglich zu beeinträchtigen, ist es wichtig, die Inhalte für die nächste Version in einen separaten Zweig abzutrennen. Nennen wir ihn Release Branch. Damit wird Folgendes gelöst:

• Das Entwicklungsteam kann seine Aktivitäten fortsetzen und ohne Unterbrechung in die neuen Stories des Hauptzweigs einfließen lassen.
• Es besteht kein Risiko, dass der Release-Inhalt durch unerwartete Codeänderungen des Scrum-Teams beeinträchtigt wird.
• Die Testaktivitäten können in einem isolierten Bereich durchgeführt werden. Hier werden nur Änderungen vorgenommen, die für die Durchführung der Tests erforderlich sind.
• Da die Release-Pipeline nur die Inhalte aus dem Release Branch in die Produktion überführt, haben wir einen klaren Prozess und die 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.

Legen Sie den Inhalt der nächsten Version also einfach beiseite und lassen Sie ihn zu einem stabilen Zustand kommen, der für die Veröffentlichung bereit ist.

Timen Sie die Releases so, dass sie immer wieder funktionieren

Ich habe den Ehrgeiz aufgegeben, die Veröffentlichung nach Abschluss jedes einzelnen Sprints durchzuführen. Es war völlig klar, dass dies keine Chance hatte zu funktionieren. Zumindest nicht mit solchen Nebeneffekten wie:

• auswirkungen auf die Entwicklungsinhalte des nächsten Sprints,
• nicht in der Lage zu sein, den Inhalt der Veröffentlichung zu stabilisieren,
• das Aufholen aller erforderlichen Testaktivitäten usw.

Das Ziel war also, die Veröffentlichung bis zum Ende jedes zweiten Sprints durchzuführen. Das würde Folgendes bedeuten:

• Ein Release wird immer Stories aus den letzten beiden bereits abgeschlossenen Sprints enthalten. Da die Freigabe innerhalb des aktuellen (aktiven) Sprints erfolgt, ist dieser Sprintinhalt noch nicht in der Freigabe enthalten.
• Es bleibt ein ganzer Sprint Zeit, um die notwendigen Testaktivitäten und Fehlerbehebungen abzuschließen.
• Der Release-Owner hat genügend Zeit, um mit dem Nicht-Release-Sprint release-relevante Informationen (Testfälle, Release Notes usw.) zu sammeln. Auf diese Weise kann er im Grunde eigenständig arbeiten und den Rest des Entwicklungsteams an neuen Stories arbeiten lassen.
• Falls ein Fehler entdeckt wird, kann sich der Release Owner schnell mit dem konkreten Entwickler in Verbindung setzen, um das Problem zu beheben und zum aktuellen Sprintinhalt zurückzukehren. Es sollte also immer ein gewisser Prozentsatz an Zeit von der Kapazität des Teams für diese Fehlerbehebung eingeplant werden. Wie viel genau, lässt sich im Laufe der Zeit herausfinden.

Es ist klar, dass die Benutzer nicht den neuesten Sprint-Inhalt in der neuesten Version erhalten werden. Aber im Laufe der Zeit wird dies irrelevant werden. Sie werden ohnehin zwei Sprints an Inhalten mit jeder nächsten Version erhalten, nach jedem zweiten Sprint.

Dies scheint ein guter Kompromiss zwischen der Zufriedenheit mit der schnellen Lieferung und der Aufrechterhaltung der Scrum-Aktivitäten ohne größere Störungen zu sein.

Führen Sie das Release Deployment durch

Wenn die Tests, die Fehlerbehebung und die Pipeline-Bereitschaftsaktivitäten erfolgreich abgeschlossen sind, ist es ein recht unkomplizierter Prozess, die Produktionspipeline auszuführen und die Freigabe für die Produktion abzuschließen.

Da die Freigabe von einem eigenständigen Zweig aus erfolgt, kann dies im Grunde eine unbemerkte und unsichtbare Aktivität sein. Niemand braucht davon zu wissen. Wenn das der Fall ist, ist das die bestmögliche Umsetzung der Freigabeverteilung.

Eine Voraussetzung dafür ist, dass Sie eine solide automatisierte DevOps-Pipeline erstellt haben. Diese wird nicht nur für die Bereitstellung in der Produktionsumgebung verwendet, sondern auch für alle anderen Umgebungen auf niedrigerer Ebene. Dazu können Entwicklungs-, Sandbox-, Test-, Qualitätssicherungs-, Performance-Umgebungen usw. gehören. So können Sie mit einem Klick alle Lösungen für jede einzelne Umgebung bereitstellen.

Die Veröffentlichung sollte kein Schmerzpunkt oder Stress sein. Oder ein Alptraum, vor dem sich alle fürchten und sich eine Woche lang auf diesen Tag vorbereiten. Nein – stattdessen ist es das beste Zeichen für eine erfolgreiche Veröffentlichung, wenn niemand etwas davon merkt.

Führen Sie den Release-Zweig in den Entwicklungszweig zurück

Der Release-Zweig enthält nun einige spezielle Inhalte, die im regulären, laufenden Entwicklungszweig nicht vorhanden sind. Er bezieht sich auf alle Korrekturen, die während der Testphase vorgenommen wurden. Diese Inhalte müssen wieder in den Entwicklungszweig zurückgeführt werden, um sicherzustellen, dass die Korrekturen auch nach der nächsten Veröffentlichung dort verbleiben.

Zu diesem Zeitpunkt dient der neueste Release Branch als Notfallcode, der für die erneute Bereitstellung bereit ist. Wenn ein dringendes Problem mit hoher Priorität kurz nach der Produktionsbereitstellung behoben werden muss, kann dieser Zweig verwendet werden. Es ist einfach, diesen Code zu nehmen und die Korrektur darin zu implementieren. Dabei handelt es sich immer noch um eine exakte Kopie des aktuellen Produktionscodes ohne neue, unveröffentlichte Inhalte.

Sobald die neue Testphase beginnt, kann der vorherige Versionszweig gelöscht und durch einen neuen ersetzt werden. Der neue Zweig wird wiederum als Kopie des aktuellen Entwicklungszweigs erstellt.

Regelmäßige Releases einrichten

Und jetzt haben wir es 😀-einen soliden Prozess für die Vorgehensweise bei der Veröffentlichung. Das Einzige, was noch fehlt, ist die Verpflichtung, sie regelmäßig durchzuführen. In diesem Fall nach jedem zweiten Sprint.

Indem wir es regelmäßig machen, schaffen wir die Voraussetzungen dafür, dass es leichter zu bewerkstelligen ist, vor allem weil:

• Wenn die Veröffentlichung nach nicht allzu langer Zeit erfolgt, gibt es nicht so viele neue Inhalte, die in der Produktion installiert werden müssen. Das Inkrement ist klein und gilt als stabil.
• Nicht mehr so viele neue Inhalte bedeuten nicht mehr so viele Testaktivitäten und die Erstellung von Testfällen. Weniger Kommunikation, Abstimmungsgespräche und Zusammenarbeit mit den Beteiligten darüber, was alles neu validiert werden muss. Sie werden auch zustimmen, dass die letzte Veröffentlichung noch nicht so lange her ist. Also wird dieser Aktion weniger Bedeutung beigemessen.
• Das Team wird sich an diesen Zyklus gewöhnen; mit der Zeit wird er zu einem natürlichen Bestandteil des Teams.
• Als Nebeneffekt werden die Daten der Entwicklungs- und Testumgebungen häufig aktualisiert. Das ist ohnehin für jeden neuen Testzyklus erforderlich. Es handelt sich also nicht nur um eine weitere geplante Aktivität, die zu erledigen ist. Vielmehr handelt es sich um eine Aktion, die bereits Teil des etablierten Prozesses ist. Dieser Perspektivwechsel hat so viel Einfluss auf die Atmosphäre im Team. Man würde es nicht glauben.

Fazit

Mit diesem Kapitel schließe ich meine bisherigen Beiträge zum Thema Scrum-Lebenszyklus ab. Außerdem geht es darum, was sich im wirklichen Leben bewährt hat.

Oft beginnen Teams mit dem agilen Weg und machen viele Dinge falsch. Dann entwickeln sie sich schließlich weiter und beginnen, Dinge anders zu machen. Diese Serie könnte einigen von ihnen helfen, diesen Wandel schneller zu vollziehen.

Weder ist dieser Release-Ansatz der einzig praktikable, noch ist er ohne Probleme. Die wird es immer noch geben, und die Teams müssen sich damit auseinandersetzen. Dann verbessern Sie, was möglich ist, und vergessen, was keinen Sinn macht.

Aber nach dem, was ich weiß, hat dieser Ansatz, obwohl er einfach ist, bewiesen, dass Veränderungen möglich sind. Von chaotischen, unvorhersehbaren Sprints zu stabileren Lieferungen mit regelmäßigen Veröffentlichungen, auf die man sich verlassen und mit denen man planen kann. Und dazu braucht es keine spezielle, hochkomplizierte Methodik – nur einfache Regeln und die Bereitschaft, dem Plan zu folgen.