Ausführen des Scrum-Release – von der Inhaltsvorbereitung bis zur Bereitstellung

Wenn es um die Bereitstellung von Scrum geht, sind die Leute gewöhnlichally erwarten Sie 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 eine so automatische Erwartung sein kann. Besondersally wenn Sie die folgenden möglichen Aktivitäten berücksichtigen, die vorher 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 aktualisiert istated mit dem latest-Inhalt und die Pipelineself ist zuverlässig in der Ausführung.
• Führen Sie die Pipeline in allen relevanten Umgebungen aus, um sie in die Umgebung zu bringenateSt. State sowohl aus Code- als auch aus Datenperspektive.
• Danach Release Notes und kommunikate mit dem Kunden die impact der Veröffentlichung und was sich danach genau ändern wird.
• Wenn es relevant ist, syncArbeiten Sie mit anderen parallelen Scrum-Teams zusammen, um sicherzustellen, dass die abhängigen Inhalte gleichzeitig veröffentlicht werdenneonormalerweise. Es sollte nichts fehlen, um sicherzustellen, dass Ihre Release-Inhalte wie erwartet funktionieren.
• Darüber hinaus durchlaufen Sie alle Scrum-Zeremonien. Nicht nur related für den aktuellen Sprint, aber auch solche, die für den nächsten Sprint vorgesehen sind (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?

Inhalt freigeben ProcessIng.

Ich falle processes innerhalb des Sprints sind automatisierte, besteht die Möglichkeit, einfach „den Abzug zu betätigen“ und das L zu installierenateAm Ende jedes Sprints wird die erste Codeversion in die Produktion übernommen. Das Problem ist, dass ich noch nie eine so perfekte St. erlebt habeate des Scrum-Teams.

Wenn es sich um Aktu handeltally Dies ist in manchen Kleinprivaten der Fallate Unternehmen, ich really beneide sie. Aber die Realität im Unternehmenate Die Welt ist, dass ein Scrum-Team diesen Reifegrad nicht erreichen wird. Im Gegenteil, loslassen processEs ist üblichally verbunden mit zeitaufwändigen Aktivitäten, die den größten Teil des folgenden Sprints erreichen und sich aus inhaltlicher und metrischer Sicht auf diesen Sprint auswirken. 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 zu Machen Sie jeden zweiten Sprint zum Release-Sprint. Hier ist, was es bedeutet.

Trennenate Codeversion für die nächste Version

Hier geht es um die getrennte Handhabungate Zweige im GIT-Repository. Es gibt viele Möglichkeiten, das gleiche Problem anzugehen, und alle können erfolgreich sein. Für den Zweck dieses Artikels werde ich die Demonstration jedoch auf einfache Weise beschränkenate der Ansatz und seine impact.

Um impact Um die laufenden Entwicklungsaktivitäten so gering wie möglich zu halten, ist es wichtig, sie zu trennenate den Inhalt für die nächste Veröffentlichung in eine separate Dateiate Zweig. Nennen wir es Release Branch. Damit wird Folgendes sein resolved:

• 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 isoliert ausgeführt werdenated Raum. Hier sind nur die Änderungen erforderlich, die zur Behebung des Problems erforderlich sind Testen werden vorgestellt.
• Da die Release-Pipeline nur die Inhalte aus dem Release-Zweig in der Produktion bereitstellt, haben wir eine klare Vorstellung process 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.

Behalten Sie also einfach den Inhalt der nächsten Veröffentlichung beiseite und lassen Sie ihn zu einem stabilen Stand kommenate, bereit zur Veröffentlichung.

Planen Sie die Veröffentlichungen so, dass sie reibungslos funktionierenatetgl

Ich habe morgens aufgegebenbition, die Veröffentlichung nach Abschluss jedes einzelnen Sprints durchzuführen. Es war völlig klar, dass dies keine Chance haben würde, zu funktionieren. Zumindest nicht mit solchen Nebenwirkungen wie:

• impacting 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-Inhaber genügend Zeit, release-relevante Informationen (Testfälle, Release-Notes etc.) zu sammeln. Auf diese Weise können sie operierenate basically eigenständig und lassen Sie den Rest des Entwicklungsteams an neuen Geschichten arbeiten.
• Im Falle von Fehlerentdeckungkann sich der Release-Inhaber 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 an Zeit zur Verfügung stehenated von der Fähigkeit des Teams, diese Fehlerbehebung zu unterstützen. Wie viel genau lässt sich im Laufe der Zeit herausfinden.

Es ist klar, dass die Benutzer das nicht bekommen werdenatest sprint inhalt innerhalb der latest-Veröffentlichung. Aber mit der Zeit wird dies irrelevant werden. Sie erhalten ohnehin bei jeder nächsten Veröffentlichung nach jedem zweiten Sprint zwei Sprints mit Inhalten.

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 Tests, Fehlerbehebungen und Pipeline-Bereitschaftsaktivitäten erfolgreich abgeschlossen sind, ist die Sache ganz einfach process um 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 einfach seinally eine unbemerkte und unsichtbare Aktivität. Niemand muss es wissen. Wenn das der Fall ist, handelt es sich um die bestmögliche Umsetzung der Release-Bereitstellung. 

Voraussetzung dafür ist Createda solide Autoated DevOps Pipeline. Wird nicht nur für die Bereitstellung in der Produktionsumgebung, sondern auch in allen anderen Umgebungen auf niedrigerer Ebene verwendet. Dazu gehören möglicherweise Entwickler, sandbox, Tests, Qualitätssicherung, Leistungsumgebung usw. Mit nur einem Klick können Sie alle Lösungen für jede einzelne Umgebung bereitstellen.

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.

Führen Sie den Release-Zweig wieder mit dem Entwicklungszweig zusammen

Der Release-Zweig enthält jetzt einige spezielle Inhalte, die im regulären Zweig der laufenden Entwicklung nicht vorhanden sind. Es ist related auf alle Korrekturen, die während des Testzeitraums implementiert wurden. Dieser Inhalt muss wieder in den Entwicklungszweig zusammengeführt werden, um sicherzustellen, dass die Korrekturen auch nach der nächsten Veröffentlichung dort verbleiben.

Zu diesem Zeitpunkt war das latest Release Branch dient als Notfall-Produktionscode, der zur erneuten Bereitstellung bereit ist. Wenn ein dringendes Problem mit hoher Priorität behandelt werden muss resolved kurz nach der Produktionsbereitstellung kann dieser Zweig verwendet werden. 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.

Finally, sobald der neue Testzeitraum beginnt, wird der prevDer aktuelle Release-Zweig kann gelöscht und durch einen neuen ersetzt werden. Der Neue ist wieder Created als Kopie aus dem aktuellen Entwicklungszweig.

Etablieren Sie regelmäßige Releases

Und jetzt haben wir es 😀 – ein solides process für die Annäherung an die Veröffentlichung. 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, handeln wirally Legen Sie den Grundstein, um die Umsetzung zu erleichtern, vor allem aus folgenden Gründen:

• 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.
• So viele neue Inhalte bedeuten nicht unbedingt viele Testaktivitäten und Testfälle creatioN. Weniger Kommunikation, Vereinbarungsanrufe und Zusammenarbeit mit Stakeholdern darüber, was alles erneut validiert werden mussateD. Sie werden auch zustimmen, dass die letzte Veröffentlichung noch nicht so 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. Dies ist ohnehin für jeden neuen Testzyklus erforderlich. Es handelt sich also nicht nur um eine weitere geplante Aktivität. Vielmehr handelt es sich um eine Aktion, die bereits zum Etablierten gehört process. Dieser Perspektivwechsel hat großen Einfluss auf die Atmosphäre im Team. Das würde man nicht glauben.

Schlussfolgerung

Dieses Kapitel schließt meine Seite abrevInteressante Beiträge zum Thema Scrum-Lebenszyklus. Außerdem geht es darum, was sich im wirklichen Leben bewährt hat. 

Oft beginnen Teams den agilen Weg und machen viele Dinge falsch. Dann entwickeln sie sich weiter, schließlichallyund anfangen, die Dinge anders zu machen. Diese Serie könnte einigen von ihnen helfen, diese Änderung schneller umzusetzen.

Dieser Release-Ansatz ist auch nicht der einzige workable, und es ist auch nicht ohne Probleme. Diese wird es weiterhin geben und die Teams müssen sich damit auseinandersetzen. Dann verbessern Sie, was möglich ist, und vergessen Sie, was keinen Sinn hat. 

Aber soweit ich weiß, hat dieser Ansatz, obwohl er einfach ist, bewiesen, dass Veränderungen möglich sind. Von chaotisch, unvorhersehbare Sprints zu einer stabileren Bereitstellung mit regelmäßigen Releases, auf die man sich verlassen und mit denen man planen kann. Und es bedarf keiner besonderen, sehr komplizierten Vorgehensweiseated Methodik – einfach einfache Regeln und die Bereitschaft, dem Plan zu folgen.