Software-Release-Prozess: Flussdiagramm mit Freigabe und Rollback

Was ist software-release-prozess: flussdiagramm mit freigabe und rollback?

Ein Software-Release-Prozess ist die Menge der Tore zwischen einem fertiggestellten Build und einem stabilen Produktionssystem. Die Schritte selbst sind vertraut (Branch ziehen, bauen, testen, ausliefern), doch der Wert des aufgeschriebenen Prozesses liegt in den Toren: der Punkt, an dem sich der Umfang nicht mehr ändert; der Punkt, an dem eine rote Testsuite die Arbeit zurück in die Entwicklung schickt statt nach vorn; der Punkt, an dem jemand mit der entsprechenden Befugnis Go sagt; und der Punkt, an dem ein schlechtes Release zurückgerollt statt diskutiert wird. Jedes Tor hinterlässt einen Nachweis darüber, was im Release war, was getestet wurde, wer freigegeben hat und was nach dem Livegang passiert ist.

Die meisten Release-Probleme sind Übergabeprobleme und keine technischen Probleme. Ein Branch wird gezogen, während noch drei Merges unterwegs sind, und danach kann niemand sagen, was tatsächlich im Build steckt. Die QA fährt ein Regressionspaket gegen eine Staging-Umgebung, die vor Monaten von der Produktion abgedriftet ist. Der Go/No-Go-Termin findet in einer Videokonferenz ohne schriftliche Kriterien statt, sodass die lauteste Meinung gewinnt. Ein Release geht am späten Nachmittag heraus, ohne dass eine Beobachtungszeit vereinbart wäre, und das erste Anzeichen für ein Problem ist am nächsten Morgen eine Kunden-E-Mail. Als Swimlanes gezeichnet wird jede Übergabe explizit, und es ist jederzeit erkennbar, wer das Release gerade hält.

Diese Vorlage ist ein arbeitsfähiger Release-Ablauf über fünf Bahnen: Entwicklung, QA, Release-Manager, IT-Betrieb und Product Owner, ausgelegt über fünf Phasen vom Scope-Freeze bis zum Abschluss. Sie enthält die drei Schleifen, die Teams sonst ungezeichnet lassen: das automatisierte Test-Gate, das Fehlschläge auf den Release-Branch zurückführt, die No-Go-Entscheidung, die ein Release zur Nacharbeit zurückschickt statt in die Produktion, und den Hotfix-Pfad, über den ein Fehler nach dem Release erneut in Deployment und Verifikation einläuft, ohne dass jemand einen Parallelprozess erfinden muss.

Was dieses Flussdiagramm abdeckt

In dieser Vorlage

• Umfang und Branch über die ersten drei Bahnen: In der Entwicklung ist der Code für das Release fertiggestellt, die QA bestätigt Testumfang und Eintrittskriterien, danach friert der Release-Manager den Umfang ein und zieht den Release-Branch.
• Das automatisierte Test-Gate: Die Entwicklung erstellt den Build und führt die automatisierten Tests aus, die QA hält die Entscheidung „Automatisierte Tests bestanden?“, die Fehlschläge zu „Fehler im Release-Branch beheben“ und über die Kante Neu bauen zurück in den Build schickt statt nach vorn.
• Staging und UAT als drei getrennte Übergaben: Der IT-Betrieb deployt den Build auf Staging, die QA fährt die Regressionstests dagegen, und der Product Owner führt die UAT durch und dokumentiert die Abnahme.
• Freigabe als Nachweis plus Entscheidung: Der Release-Manager stellt das Release-Freigabedokument zusammen, der Product Owner gibt das Release für die Produktion frei, und die Entscheidung „Go oder No-Go?“ liefert es entweder aus oder führt es zurück in die Fehlerbehebung.
• Der Produktionspfad in der Bahn IT-Betrieb: Deployment im Release-Fenster, Smoke-Tests in der Produktion, danach die Entscheidung „Release stabil?“, die ein fehlerhaftes Release über „Auf die Vorversion zurückrollen“ und die Kante Neu planen zurück in die Fehlerbehebung leitet.
• Überwachung und Abschluss: eine festgelegte Beobachtungszeit, die Entscheidung „Fehler in Produktion gefunden?“, deren Ja-Zweig den Hotfix über Deployment und Smoke-Tests erneut einspeist, und ein Schlussschritt, der die Release Notes veröffentlicht und das Release schließt.

Wann Sie diese Vorlage verwenden sollten

• Sie schreiben oder überarbeiten ein Release-Verfahren für ein Team, das bisher aus Gewohnheit und über Chat-Threads ausgeliefert hat und ein abgestimmtes Bild braucht, bevor es in eine Pipeline gegossen wird.
• Sie arbeiten neue Entwickler, QA-Analysten oder Rufbereitschaftskräfte ein, die wissen müssen, welches Tor sie halten und was stromabwärts passiert, wenn sie es zuhalten.
• Sie klären, wer die Go/No-Go-Entscheidung tatsächlich trifft und anhand welcher Kriterien, bevor das nächste Release die Diskussion erzwingt.
• Sie beantworten einen Sicherheitsfragebogen eines Kunden oder eine interne Auditanfrage dazu, wie Änderungen getestet, freigegeben und zurückgerollt werden.
• Sie werten nach einem missglückten Release aus und wollen darüber sprechen, welches Tor übersprungen wurde, statt den Ablauf aus dem Gedächtnis zu rekonstruieren.

So funktioniert es

1. Benennen Sie die Bahnen nach Ihren echten Rollen

   Ersetzen Sie Entwicklung, QA, Release-Manager, IT-Betrieb und Product Owner durch die Rollen, die es bei Ihnen wirklich gibt. Viele Teams haben keinen eigenen Release-Manager; führen Sie diese Bahn dann mit der technischen Leitung zusammen, statt ein leeres Band stehen zu lassen. Gibt es kein getrenntes Betriebsteam, verlagern Sie das Deployment in die Entwicklung und schreiben Sie das an das Diagramm.

2. Definieren Sie, was der Scope-Freeze bedeutet

   Schreiben Sie Ihre Freeze-Regel an den Schritt mit dem Release-Branch: Was darf nach dem Ziehen noch auf dem Branch landen, wer genehmigt eine Ausnahme, und wie wird der Branch getaggt? Halten Sie den Commit fest, aus dem der Branch entstanden ist, er ist es, der den Build reproduzierbar macht und die Release Notes aus dem Diff erzeugbar.

3. Definieren Sie an jedem Test-Gate, was „bestanden“ heißt

   Die Entscheidung „Automatisierte Tests bestanden?“ ist nur so gut wie ihre Definition. Legen Sie fest, welche Suiten grün sein müssen, welche Flaky-Rate oder Abdeckungsschwelle Sie akzeptieren und wer einen roten Build übersteuern darf. Tun Sie dasselbe für das Regressionspaket auf Staging und für die UAT, damit der Product Owner weiß, was er abnimmt.

4. Schreiben Sie die Go/No-Go-Kriterien auf, bevor Sie sie brauchen

   Ersetzen Sie die allgemeine Entscheidung durch Ihre eigene Checkliste: keine offenen kritischen Fehler, Rollback geprobt, Rufbereitschaft bestätigt, abhängige Teams informiert, Cut-off-Zeitpunkt genannt. Benennen Sie, wer den Termin leitet und wer ein Veto hat. Diese Punkte zu vereinbaren, während ein Release schon wartet, ist der Weg, auf dem schlechte Releases freigegeben werden.

5. Legen Sie Rollback-Auslöser, Beobachtungszeit und Hotfix-Weg fest

   Bestimmen Sie, was „Release stabil?“ mit Fehlerhaft beantwortet: eine konkrete Fehlerrate, eine Latenzschwelle oder ein fehlgeschlagener Smoke-Test, keine Ermessensfrage. Legen Sie fest, wie lange die Beobachtungszeit läuft und was dabei beobachtet wird. Entscheiden Sie danach, welche Freigabe ein Hotfix braucht, wer ihn außerhalb der Geschäftszeiten genehmigen darf und wie er in den Hauptzweig zurückgeführt wird, ein Fix, der nur auf dem Release-Branch lebt, ist eine verbreitete Quelle der nächsten Regression.

6. Veröffentlichen Sie es und halten Sie eine gültige Fassung

   Legen Sie das Diagramm dort ab, wo gearbeitet wird (neben der Release-Checkliste oder im Runbook) und holen Sie die Freigabe der darin benannten Personen ein. Bewahren Sie die älteren Fassungen auf, damit belegbar ist, wann sich das Verfahren geändert hat und warum, und prüfen Sie es nach jedem Release, das schlecht gelaufen ist.

Häufig gestellte Fragen

Aus welchen Phasen besteht ein Software-Release-Prozess?

Fünf Phasen decken die meisten Teams ab. Erstens Umfang und Branch: festlegen, was im Release ist, Eintrittskriterien für den Test bestätigen, den Umfang einfrieren und den Release-Branch ziehen. Zweitens Build und Test: einen Release-Kandidaten erzeugen, die automatisierte Suite fahren und Fehlschläge zurück auf den Branch schicken statt nach vorn. Drittens Staging und UAT: auf eine Staging-Umgebung deployen, Regressionstests fahren und die UAT-Abnahme des Product Owners einholen. Viertens Freigabe: das Freigabedokument zusammenstellen und eine ausdrückliche Go/No-Go-Entscheidung treffen. Fünftens Release und Überwachung: im vereinbarten Fenster deployen, Smoke-Tests fahren, die festgelegte Beobachtungszeit überwachen, dann die Release Notes veröffentlichen und das Release schließen.

Was ist der Unterschied zwischen Release-Prozess und Deployment-Pipeline?

Die Deployment-Pipeline ist die Automatisierung: Sie baut, testet und liefert Code auf einen Auslöser hin aus. Der Release-Prozess ist die Entscheidungsfindung darum herum: wer den Umfang vereinbart hat, wer bestätigt hat, dass die Tests aussagekräftig waren, wer die Produktion freigegeben hat, was bei einem missglückten Release passiert und wann das Team wieder in den Normalbetrieb geht. Eine ausgereifte Pipeline beseitigt manuelle Schritte, aber sie beseitigt die Entscheidungen nicht. Dieses Diagramm zeigt die Entscheidungen bewusst als Entscheidungen, damit Sie sehen, welche davon Ihre Pipeline bereits erzwingt und welche noch darauf beruhen, dass jemand daran denkt.

Wer sollte die Go/No-Go-Entscheidung treffen, und worauf sollte sie sich stützen?

Eine namentlich benannte Person sollte den Termin leiten, üblich sind der Release-Manager oder wer die Produktion verantwortet, wobei die Freigabe des Product Owners bereits als Eingangsgröße dokumentiert vorliegt und nicht im Termin verhandelt wird. Stützen Sie die Entscheidung auf Kriterien, die vor dem Release aufgeschrieben wurden: keine offenen kritischen Fehler, Regression und UAT abgeschlossen, Rollback geprobt, Rufbereitschaft bestätigt, abhängige Teams informiert. Halten Sie fest, wer teilgenommen hat und was entschieden wurde, nicht nur das Ergebnis. Bei einem SOC-2-Audit ist das einschlägige Kriterium CC8.1: Änderungen müssen autorisiert, getestet, freigegeben und dokumentiert sein: das Freigabedokument und die Freigabespur sind genau der Nachweis dafür, und das Diagramm zeigt, wo sie entstehen.

Wie werden Hotfixes behandelt, ohne den Release-Prozess zu umgehen?

Ein Hotfix staucht den Prozess zusammen, er überspringt ihn nicht. In dieser Vorlage führt ein während der Beobachtungszeit gefundener Fehler zu „Hotfix bauen und testen“ in der Bahn Entwicklung und läuft danach wieder beim Deployment ein, durch dieselben Smoke-Tests in der Produktion und dieselbe Prüfung „Release stabil?“ wie ein geplantes Release. Was sich ändert, ist die Geschwindigkeit der Freigabe, nicht die Verifikation. Zwei Regeln halten das ehrlich: vorab vereinbaren, wer einen Hotfix außerhalb der Geschäftszeiten genehmigen darf, und den Fix noch am selben Tag in den Hauptzweig zurückführen, denn ein Fix, der nur auf dem Release-Branch existiert, taucht im nächsten Release als Regression wieder auf.