Release-Checkliste für Software
Release-Checkliste für Software-Teams: Scope festlegen, Go/No-Go, Release Notes, Support-Briefing und Go-Live als Vorlage für jede neue Version.
- Typischer Rhythmus pro Release
- Die Checkliste 5 Abschnitte, 23 Punkte
- Variablen
{{product}}{{version}}{{release_date}} - Aus der CI starten
Ein Release ist mehr als ein Deployment. Es ist der Moment, in dem Kunden, Support und Vertrieb eine neue Version zu sehen bekommen. Diese Checkliste deckt die Wochen und Tage davor ab, den Go-Live selbst und die ersten Tage danach. Sie eignet sich für versionierte Releases wie Major- und Minor-Versionen, mobile Apps, On-Premise-Software oder größere Funktionspakete, die angekündigt werden.
Wer verantwortlich ist
Eine Person übernimmt die Rolle des Release Managers. In kleinen Teams ist das oft die Produktverantwortliche oder der Tech Lead. Diese Person führt das Go/No-Go-Meeting und hält den Termin. Sie entscheidet im Zweifel auch, ob eine Funktion aus dem Release fliegt. Einzelne Schritte wie Release Notes oder Support-Briefing werden im Durchlauf an die zuständigen Personen vergeben.
Typische Fehler
- Scope wächst bis zum letzten Tag. Einen Code Freeze festlegen und danach nur noch Bugfixes zulassen.
- Release Notes am Release-Tag schreiben. Sie werden dann zu knapp, technisch und unvollständig. Den Entwurf parallel zur Entwicklung pflegen.
- Support erfährt es von Kunden. Das Support-Team vorher briefen und Antworten auf die naheliegenden Fragen bereitlegen.
- Kein klares No-Go-Kriterium. Vorher festlegen, welche offenen Bugs ein Release stoppen.
- App-Store-Prüfung vergessen. Bei mobilen Apps die Review-Zeit der Stores einplanen und nicht mit dem Marketing-Termin kollidieren lassen.
Den Durchlauf kann die Pipeline beim Anlegen des Release-Branches starten. So hängt jede Version an einer eigenen, nachvollziehbaren Checkliste.
Die Checkliste: Release {{product}} {{version}}
Planung und Scope
-
Scope für
{{version}}festgelegt und im Tracker als Meilenstein markiert -
Zieltermin
{{release_date}}mit Entwicklung, Support und Marketing abgestimmt -
Code Freeze terminiert und im Team kommuniziert
-
No-Go-Kriterien festgelegt (z. B. offene kritische Bugs, fehlende Migration)
Qualität und Freigabe
-
Alle Tickets im Meilenstein erledigt oder bewusst auf ein späteres Release verschoben
-
Regressionstests auf dem Release-Kandidaten bestanden
Automatisierte Tests plus ein manueller Durchgang der wichtigsten Abläufe.
-
Sicherheitsrelevante Abhängigkeiten auf bekannte Schwachstellen geprüft
-
Performance des Release-Kandidaten mit der Vorversion verglichen optional
-
Datenschutzerklärung und AGB geprüft, falls neue Daten verarbeitet werden optional
Neue Tracking-Tools, Drittanbieter oder Datenkategorien mit der Datenschutzverantwortlichen klären.
-
Go/No-Go-Meeting durchgeführt und Entscheidung im Durchlauf notiert
Kommunikation vorbereiten
-
Release Notes für Kunden geschrieben, gegengelesen und freigegeben
In Nutzersprache schreiben: was neu ist, was sich ändert, was Kunden tun müssen.
-
Dokumentation und Hilfeartikel aktualisiert
-
Support-Team gebrieft, Antworten auf erwartbare Fragen bereitgelegt
-
Ankündigung für Blog, Newsletter oder In-App-Hinweis vorbereitet optional
-
Kunden mit Breaking Changes vorab direkt informiert optional
Go-Live
-
Deployment-Checkliste für
{{version}}durchlaufen und abgeschlossen -
App-Store- oder Paket-Veröffentlichung freigegeben optional
-
Release Notes und Dokumentation veröffentlicht
-
Ankündigung veröffentlicht und intern geteilt
-
Versions-Tag im Repository gesetzt
Nach dem Release
-
Fehlerraten, Support-Tickets und Feedback in den ersten Tagen beobachtet
-
Hotfix-Bedarf geprüft und entschieden
-
Kurze Retrospektive durchgeführt und Verbesserungen als Tickets erfasst
Checkliste als Markdown
Diese Checkliste aus der Pipeline starten
Beim Anlegen des Release-Branches POST /api/v1/runs mit der Vorlage "Release {{product}} {{version}}" und version sowie release_date aufrufen.
curl -X POST https://runbook.metastic.ch/api/v1/runs \
-H "Authorization: Bearer $RUNBOOK_TOKEN" \
-H "Content-Type: application/json" \
-d '{"template": "Release {{product}} {{version}}", "variables": {"product": "…", "version": "…", "release_date": "…"}}'Häufige Fragen
Was gehört in eine Release-Checkliste?
Eine gute Release-Checkliste deckt vier Phasen ab: Scope und Termin festlegen, Qualität sichern, Kommunikation vorbereiten und den Go-Live begleiten. Dazu gehört eine Nachbereitung in den Tagen danach. Die technischen Schritte des Deployments stehen besser in einer eigenen Deployment-Checkliste.
Wer entscheidet beim Go/No-Go?
In der Regel die Person mit der Release-Verantwortung, nach Rücksprache mit Entwicklung, QA und Support. Wichtig ist, dass die No-Go-Kriterien vorher feststehen. Dann ist die Entscheidung eine Prüfung gegen Kriterien und keine Diskussion unter Zeitdruck.
Wie oft sollte man eine Release-Checkliste anpassen?
Nach jeder Retrospektive kurz prüfen, ob ein Schritt fehlt oder überflüssig ist. Wenn ein Problem zweimal aufgetreten ist, gehört der passende Prüfschritt in die Vorlage. Schritte, die nie zutreffen, als optional markieren oder streichen.
Aktualisiert