Release-Management-Prozess für Teams, die oft ausliefern
7 Min. Lesezeit
Ein Release-Management-Prozess ist die Folge von Schritten, die eine Änderung von “gemerged” zu “läuft in Produktion und ist den Betroffenen erklärt” bringt. Für ein Team, das oft ausliefert, läuft er auf sieben Schritte hinaus: Umfang planen, die Änderung isolieren, bauen und testen, freigeben, ausrollen und prüfen, kommunizieren und rückblicken. Jeder Schritt braucht eine namentlich genannte Verantwortliche und ein Abschlusskriterium, sonst findet er irgendwann still nicht mehr statt.
Dieser Leitfaden geht von einem Team mit 5 bis 50 Entwicklerinnen aus, das wöchentlich oder täglich ausrollt und möchte, dass der Prozess nicht im Weg steht.
| Schritt | Verantwortlich | Abschlusskriterien |
|---|---|---|
| 1. Umfang planen | Produkt- oder Tech-Lead | Die Liste der Änderungen dieses Releases ist aufgeschrieben, Riskantes ist markiert |
| 2. Branch oder Flag | Die Entwicklerin, der die Änderung gehört | Die Arbeit liegt auf einem kurzlebigen Branch oder hinter einem Flag, sodass main auslieferbar bleibt |
| 3. Bauen und testen | CI, mit der Autorin in Bereitschaft für Fehler | Pipeline grün auf genau dem Commit, der ausgeliefert wird |
| 4. Freigeben | Reviewerin, bei riskanten Änderungen zusätzlich die Release-Managerin | Review erledigt, Rollback-Weg benannt, Go oder No-Go festgehalten |
| 5. Ausrollen und prüfen | Release-Managerin oder Entwicklerin in Bereitschaft | Ausgerollt, Smoke-Checks bestanden, Fehlerrate und Latenz entsprechen der Baseline vor dem Release |
| 6. Kommunizieren | Wer die Änderung versteht, redigiert von jemandem, der sie nicht versteht | Release Notes dort veröffentlicht, wo Nutzerinnen sie lesen, Support und Vertrieb informiert |
| 7. Rückblick | Release-Managerin | Metriken gelesen, alles, was schiefging, hat eine Verantwortliche und einen Fix |
Was ist der Release-Management-Prozess?
Es ist der wiederholbare Weg, den eine Änderung bis zu den Nutzerinnen nimmt: Umfang, Build, Test, Freigabe, Rollout, Prüfung, Ankündigung und Rückblick. Der Sinn, ihn aufzuschreiben, ist, dass jedes Release denselben Weg geht. So kann eine Kollegin im Urlaub, ein neuer Mitarbeiter oder eine Entwicklerin in Bereitschaft um 2 Uhr nachts ihn durchführen, ohne jemanden zu fragen, wie er funktioniert.
Welche Arten von Release-Management gibt es?
Es gibt drei praktische Arten: Continuous Deployment, geplante Releases und regulierte Änderungsverwaltung. Sie unterscheiden sich darin, wie viel vor einem Release passiert und wie viel automatisiert ist. Continuous Deployment liefert jede gemergte Änderung aus, geplante Releases bündeln Änderungen in einem Zug, und regulierte Änderungsverwaltung ergänzt formale Freigabe und einen Prüfpfad.
| Continuous Deployment | Geplante Releases | Regulierte oder ITIL-Änderungsverwaltung | |
|---|---|---|---|
| Release-Einheit | Ein gemergter Pull Request | Ein Bündel, wöchentlich oder alle zwei Wochen | Ein Änderungsantrag |
| Umfangsschritt | Implizit, der Merge ist der Umfang | Release-Planungsmeeting | Änderungsdatensatz mit Risikoeinstufung |
| Freigabe | Code-Review plus automatische Prüfungen | Die Release-Managerin gibt das Bündel frei | Change Advisory Board oder delegierte Freigeberin |
| Risikokontrolle | Feature Flags, Canaries, schneller Rollback | Staging-Soak, Release Candidate | Dokumentierter Backout-Plan, Wartungsfenster |
| Typischer Rhythmus | Viele pro Tag | Wöchentlich bis monatlich | Vom Änderungskalender bestimmt |
| Schwachstelle | Niemand sagt Nutzerinnen, was sich geändert hat | Große Bündel verstecken die Änderung, die etwas kaputt gemacht hat | Prozesszeit übersteigt die Änderung selbst |
Die meisten Teams sind eine Mischung. Ein SaaS-Produkt kann kontinuierlich ausrollen, während seine mobile App mit einem wöchentlichen Zug rausgeht und der eine Zahlungsdienst, der die Prüferinnen interessiert, einem formalen Änderungsdatensatz folgt. Wählt die Art pro Dienst, nicht pro Firma. Wo Änderungen nur schrittweise sichtbar werden, werden Release und Ankündigung zu getrennten Ereignissen, was der Fall in Feature-Flag-Release-Notes ist.
Welche Aufgaben hat eine Release-Managerin?
Eine Release-Managerin verantwortet den Weg, den eine Änderung bis in Produktion nimmt. Sie führt den Release-Kalender, entscheidet, ob eine Änderung bereit ist, führt das Deployment durch oder beaufsichtigt es, trifft die Rollback-Entscheidung, stellt sicher, dass Nutzerinnen informiert werden, und leitet den Rückblick.
Vor dem Release bestätigt sie den Umfang und prüft, dass jede riskante Änderung einen Rollback-Weg hat. Währenddessen arbeitet sie die Deploy-Checkliste ab, beobachtet die ersten Minuten der Produktionsmetriken und ruft den Rollback früh aus. Danach bestätigt sie, dass die Notes rausgegangen sind, und hält fest, was am Prozess zu beheben ist.
In einem kleinen Team rotiert die Rolle wöchentlich, und die Checkliste ist so geschrieben, dass niemand Stammeswissen braucht. Ein Monorepo mit vielen unabhängig veröffentlichten Paketen braucht meist eine Release-Verantwortliche pro Paket, sonst wird die Rolle zum Engpass.
Was sind die wichtigsten Kennzahlen für Release-Management?
Verfolgt die DORA-Metriken zur Software-Auslieferung und ergänzt eine eigene: wie lange es dauert, bis Nutzerinnen informiert sind. DORAs Forschung nennt fünf Metriken, aufgeteilt in Durchsatz (Change Lead Time, Deployment-Häufigkeit, Wiederherstellungszeit nach fehlgeschlagenem Deployment) und Instabilität (Change-Fail-Rate, Deployment-Rework-Rate).
DORAs Leitfaden definiert sie in schlichten Worten (dora.dev, software delivery metrics):
| Kennzahl | Was sie misst | Worauf zu achten ist |
|---|---|---|
| Change Lead Time | Zeit vom Commit in der Versionskontrolle bis zum Deployment in Produktion | Eine steigende Zahl bedeutet meist Warteschlangen bei Review oder Freigabe |
| Deployment-Häufigkeit | Wie oft ihr ausrollt, oder die Zeit zwischen Deployments | Sinkende Häufigkeit heißt, dass die Bündel wachsen |
| Wiederherstellungszeit nach fehlgeschlagenem Deployment | Zeit zur Erholung von einem Deployment, das sofortiges Eingreifen braucht | Rollback- und Alarmierungsprobleme zeigen sich hier |
| Change-Fail-Rate | Anteil der Deployments, die einen Rollback oder Hotfix brauchen | Steigt, wenn Bündel zu groß sind oder die Tests dünn |
| Deployment-Rework-Rate | Anteil der Deployments, die ungeplant sind und von einem Produktionsvorfall ausgelöst wurden | Ein Zeichen, dass Fixes schneller ausgeliefert werden als Lehren gezogen |
| Zeit, bis Nutzerinnen informiert sind | Minuten vom Produktions-Deployment bis zu einer veröffentlichten Notiz für Nutzerinnen | Messt sie selbst, kein Framework liefert sie |
Ältere Texte nennen vier Schlüsselmetriken und nennen die Wiederherstellung “Time to Restore”. Der aktuelle Leitfaden nutzt die fünf oben.
Derselbe Leitfaden warnt davor, sie als Ziele zu behandeln. Ein Ziel wie “alles wird bis Jahresende mehrmals täglich ausgerollt” lädt Teams ein, die Zahlen zu schönen, und die Metriken sind pro Anwendung oder Dienst zu lesen, nicht über die Firma vermischt. Sein praktischer Rat, um alle zu verbessern, ist, die Größe jeder Änderung zu verkleinern, weil kleinere Änderungen leichter zu prüfen sind, leichter durch die Pipeline laufen und sich leichter zurückholen lassen.
Wie passt die Release-Kommunikation in den Release-Management-Prozess?
Es ist Schritt sechs, und er hat eine Verantwortliche und ein Abschlusskriterium wie jeder andere Schritt: Notes dort veröffentlicht, wo Nutzerinnen lesen, und interne Teams informiert. Teams überspringen ihn am häufigsten, weil Deployment-Werkzeuge Erfolg melden, sobald der Code live ist.
Der günstigste Weg, diesen Schritt im Plan zu halten, ist, den Eintrag zu schreiben, wenn die Änderung gemerged wird, nicht wenn das Release ausgeliefert wird. Der Pull Request enthält schon Titel, Autorin, verknüpftes Issue und Kontext. Ein daraus gebauter Entwurf wird redigiert, nicht eine Woche später aus dem Gedächtnis geschrieben. Das ist die Idee hinter Changelog-Automatisierung: beim Merge einen Entwurf ableiten, ihn zur Freigabe durch einen Menschen zurückhalten und ihn dann aus einer Quelle überall veröffentlichen. Changeloop arbeitet so, entwirft Einträge mit KI aus gemergten Pull Requests und hält sie zur Freigabe zurück, bevor etwas veröffentlicht wird.
Zwei Varianten lohnen die Vorausplanung. Support und Vertrieb brauchen eine andere Note als Kundinnen, wofür interne Release Notes da sind. Ein vorfallgetriebenes Release hat keine Zeit für die normale Entwurfsschleife, also haltet eine kurze Vorlage bereit, wie in Notfall-Release-Notes beschrieben. Die Release-Notes-Vorlage gibt euch eine Ausgangsform für die Fassung für Kundinnen.
Wie hält man den Prozess schlank?
Automatisiert jedes Abschlusskriterium, das eine Maschine prüfen kann, und behaltet Menschen für die Ermessensentscheidungen. Eine grüne Pipeline, eine Deploy-Markierung in den Dashboards und ein Changelog-Entwurf pro gemergtem Pull Request sind prüfbar. Ob ein Rollback-Plan glaubwürdig ist oder die Notes für eine Kundin Sinn ergeben, braucht einen Menschen.
Um den Prozess zu testen, nehmt ein Release vom letzten Monat und fragt, ob jemand außerhalb des Teams allein aus der schriftlichen Aufzeichnung erkennen könnte, was ausgeliefert wurde, wer es freigegeben hat, wie es geprüft wurde und wann die Nutzerinnen informiert wurden. Jede Lücke ist eure nächste Verbesserung.
FAQ
Was ist der Unterschied zwischen Release-Management und Change-Management? Release-Management bringt eine Menge von Änderungen gebaut, getestet, ausgerollt und angekündigt ans Ziel. Change-Management im ITIL-Sinn ist der Freigabe- und Risikoprozess um jede einzelne Änderung. Teams, die oft ausliefern, legen die Freigabe in Code-Review und automatische Prüfungen.
Wie oft sollten wir ausliefern? So oft, wie eure Tests und euer Rollback-Weg es zulassen, was für viele Web-Teams täglich oder öfter heißt. DORAs Rat ist, die Größe jeder Änderung zu reduzieren, da kleine Änderungen leichter zu prüfen und zurückzuholen sind.
Brauchen kleine Teams eine Release-Managerin? Sie brauchen die Aufgaben, aber nicht unbedingt den Titel. Lasst die Rolle zwischen Entwicklerinnen rotieren, gebt der Person in der Rotation eine schriftliche Checkliste und stellt sicher, dass jemand jeden der sieben Schritte verantwortet.
Was sollte eine Release-Checkliste enthalten? Umfang bestätigt, Pipeline grün auf dem auszuliefernden Commit, Rollback-Weg benannt, Freigabe festgehalten, Smoke-Checks nach dem Deployment, Metriken mit der Baseline verglichen, Release Notes veröffentlicht, Support informiert und ein Rückblick angesetzt. Haltet sie auf einer Seite.
Die technischen Aussagen in diesem Artikel wurden nicht unabhängig geprüft. Wenn etwas nicht stimmt, sagen Sie es uns, und wir korrigieren es.