Diese Checkliste ist bewusst kompakt. Sie eignet sich als Ausgangspunkt für kleine Teams und kann an die eigene Plattform, Deployment-Pipeline und Risikoklasse angepasst werden.
1. Release-Umfang festhalten
Welche Tickets, Fehlerbehebungen und technischen Änderungen gehören tatsächlich in dieses Release? Unklare oder nicht getestete Änderungen nicht nebenbei mitnehmen.
2. Tests und Review abgeschlossen
Sind die relevanten automatisierten Tests erfolgreich und die vorgesehenen Reviews abgeschlossen? Bekannte Einschränkungen sollten dokumentiert sein.
3. Datenbank und Migrationen prüfen
Gibt es Migrationen, Datenkorrekturen oder Schemaänderungen? Reihenfolge, Laufzeit und Rückwärtskompatibilität müssen zur Deployment-Strategie passen.
4. Konfiguration und Secrets
Sind neue Umgebungsvariablen, Secrets, Feature Flags oder externe Endpunkte in allen benötigten Umgebungen vorhanden?
5. Abhängigkeiten und Infrastruktur
Wurden neue Bibliotheken, Dienste, Queues, Jobs oder Infrastrukturänderungen berücksichtigt? Externe Voraussetzungen sollten vor dem Release verfügbar sein.
6. Monitoring und Fehlerbilder
Ist klar, woran ein erfolgreiches Release erkannt wird? Logs, Metriken und zentrale Fehlerpfade sollten nach dem Deployment gezielt beobachtet werden.
7. Kommunikation
Wer muss über die Änderung informiert werden? Bei nutzerrelevanten Änderungen gehören kurze Release Notes oder Hinweise zum Ablauf dazu.
8. Rückfallplan
Was passiert, wenn das Release fehlschlägt? Rollback, Feature Flag oder ein klarer Korrekturpfad sollten vorab bekannt sein – nicht erst im Fehlerfall.