Software-Release-Prozess: Flussdiagramm mit Freigabe und Rollback

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.