Was ist eine Release-Checkliste?
Eine Release-Checkliste macht den Produktionslaunch zu abhakbaren Schritten auf dem Arbeitselement: Pre-Release-Bereitschaft, Build und Artefakte, Change-Freigabe, das Deploy selbst, Smoke-Tests und Monitoring, Rollback und Abschluss. Die Überschriften bleiben stabil; die Haken, SHAs und Notizen ändern sich mit jedem Deploy.
Teams liefern auf unterschiedliche Weise aus. Continuous-Delivery-Teams streichen die Change-Window-Zeilen. Wöchentliche Release-Züge behalten sie. Behandeln Sie die Liste als Start-Runbook und speichern Sie Ihre Version, damit der Produktionswechsel am Freitag nicht vom Gedächtnis abhängt.
Warum Teams die Release-Checkliste auf dem Vorgang halten
Ein Runbook auf einer Wiki-Seite oder in einem Slack-Thread ist leicht zu übersehen, wenn das Deploy startet. Eine Checkliste auf dem Arbeitselement hält SHA, Window, Smoke-Tests und Rollback-Pfad dort, wo die Änderung schon lebt — Release Manager, On-Call und Entwickler sehen dieselbe Restarbeit.
Dasselbe Gerüst gilt, ob Sie kontinuierlich oder in einem Change Window ausliefern: Sie öffnen den Vorgang, sehen, was offen ist, haken unterwegs ab und schreiben, was passiert ist, wenn etwas schiefgeht. Risikoarme Flag-Flips können Freigabe-, Kommunikations- und Rollback-Zeilen streichen; bei hohem Risiko bleiben sie.
Wann anwenden
Nutzen Sie eine Release-Checkliste, wenn eine Änderung in Produktion geht — auf der Story, die ausgeliefert wird, oder auf einem eigenen Change-Vorgang, wenn das Deploy eigenen Owner, eigene Daten und einen eigenen Workflow hat. Wenden Sie sie automatisch an, wenn der Status Ready to release oder Deploying wird, damit das Runbook vor dem Window erscheint. Streichen Sie Zeilen bei risikoarmen Continuous Deploys; behalten Sie Freigabe, Kommunikation und Rollback, wenn die Änderung für Benutzer sichtbar oder schwer rückgängig zu machen ist.
Release vs. QA-Tests vs. Definition of Done
Die QA-Testcheckliste ist der Testdurchlauf, bevor Sie das Window öffnen. Definition of Done ist die gemeinsame Exit-Leiste auf der Story — Review, Tests und Release-Bereitschaft, die jedes Element am Ende schuldet. Die Release-Checkliste ist das Launch-Runbook auf der Änderung, die tatsächlich ausgeliefert wird. Halten Sie sie als getrennte Listen, damit Testdurchlauf, Ship-Leiste und Produktionswindow klar getrennt bleiben. Acceptance Criteria beschreiben weiterhin das Verhalten, das Sie live bringen.
Release und Deployment — ein Beispiel zum Start
Um Ihre erste Release-Checkliste aufzubauen, starten Sie mit dem Beispiel unten. Kopieren Sie die Liste und fügen Sie sie in das Eingabefeld von Checklist for Jira auf einem Change- oder Release-Arbeitselement ein. Ideal: als Vorlage speichern und automatisch anwenden, wenn Arbeit nach Ready to release wechselt — so hat jedes Deploy ein konsistentes Gerüst und dieselben Überschriften jedes Mal. Streichen Sie Zeilen, die Ihr Team überspringt; ergänzen Sie, was Ihr Prozess braucht.
Release und Deployment
- Pre-Release-Bereitschaft
- Change, Feature Flag und Ticket-Keys sind auf diesem Arbeitselement aufgeführt
- Stakeholder und On-Call kennen das Window — oder den Grund, warum es kontinuierlich ist
- Risiko, Blast Radius und worauf zu achten ist, stehen auf dem Arbeitselement
- Build und Artefakte
- Build-Artefakt oder Commit-SHA ist erfasst
- Pre-Prod- oder Staging-Verifikation ist erledigt oder schriftlich ausgesetzt
- Secrets, Zertifikate und Deploy-Zugriff sind vorhanden
- Security und Change-Freigabe
- Security-Review oder Threat-Notizen sind verlinkt, wenn die Änderung sensibel ist
- Freigaben, die Ihre Policy verlangt, sind auf dem Arbeitselement festgehalten
- Deploy
- Produktions-Deploy-Schritte liefen in der dokumentierten Reihenfolge
- Migrationen oder Config-Änderungen liefen ohne unbeantwortete Fehler durch
- Feature Flags entsprechen der vorgesehenen Zielgruppe
- Smoke-Tests und Monitoring
- Smoke-Tests auf dem Produktionspfad sind bestanden
- Fehlerrate, Latenz und Business-KPIs wirken für das Window normal
- Monitoring-Dashboards und Alerts für den geänderten Service sind offen
- Rollback, Kommunikation und Abschluss
- Rollback- oder Disable-Pfad ist nutzbar genug getestet
- Support, Success oder Statusseite ist aktualisiert, wenn Benutzer die Änderung sehen können
- Incident- oder Follow-up-Arbeitselement ist verlinkt, wenn der Release Schaden verursacht hat
- Post-Release-Notizen und Restaufgaben sind auf diesem Vorgang festgehalten
Dieses Gerüst gehört auf die Änderung, die ausgeliefert wird. In Checklist for Jira fügen Sie Punkte im Issue-Panel hinzu oder haken sie ab, speichern die Überschriften als Projekt- oder globale Vorlage und wenden sie automatisch an, wenn der Status Ready to release wird — oder manuell über Add → Add from template, wenn Sie sie brauchen.
Bringen Sie die Checkliste dorthin, wo das Team arbeitet
Checklist for Jira legt Vorlagen, Automatisierung und Workflow-Prüfungen direkt auf den Vorgang. Kostenlos für Teams mit bis zu 10 Benutzern — ohne extra Subtasks.
Starter speichern, das Runbook automatisieren
- Checklist for Jira fügt ein Checklist-Panel in der Vorgangsansicht hinzu. Fügen Sie das Beispiel oben auf einem Change- oder Release-Arbeitselement ein, passen Sie Zeilen an Ihren Prozess an und speichern Sie die Form als Projekt- oder globale Vorlage in den Checklist settings.
- Markieren Sie die Vorlage als Protected, wenn das Runbook gesperrt bleiben soll, während Punkte abgehakt werden — damit die Schritte von einem Deploy zum nächsten nicht still schrumpfen.
- Nutzen Sie Automatisierung pro Vorlage, um das Release-Gerüst anzuhängen, wenn der Status Ready to release oder Deploying wird. Diese Automatisierungen sind in Checklist for Jira eingebaut und laufen ohne Jira-Automation-Credits.
- Wenn Ihr Team ein hartes Gate will, setzen Sie einen Completion-Validator auf den Shipped-Status, begrenzt auf diese Vorlage. Eine Post Function kann die Liste zurücksetzen, wenn Sie rollbacken und es erneut versuchen. Jira Automation kann dieselbe Liste anwenden, abschließen oder zurücksetzen, wenn die Bedingung reicher ist als ein einzelner Status.
- Kombinieren Sie mit der QA-Testcheckliste vor dem Window und Definition of Done auf der Story — siehe Automatisierungsleitfaden.
Mit dem Rest des Delivery-Sets kombinieren
Halten Sie die QA-Testcheckliste auf dem Vorgang, bis der Durchlauf grün ist. Hängen Sie Definition of Done an die Story, damit die Ship-Leiste vom ersten Tag an sichtbar ist. Nutzen Sie Definition of Ready in der Refinement, wenn Intake-Qualität Ihrem Team hilft. Das volle Set finden Sie im Vorlagen-Hub.
Häufige Fragen
Sollte der Release auf einem eigenen Jira-Vorgang leben?
Wenn das Deploy ein echtes Vorhaben mit eigenem Owner, eigenen Daten und eigenem Workflow ist, ist ein eigener Vorgang oder eine Unteraufgabe richtig. Wenn das Runbook eine Prüfliste auf einer Änderung ist, die Sie schon haben, halten Sie eine Checkliste auf diesem Arbeitselement.
Braucht jedes Team dieselbe Release-Checkliste?
Nein. Starten Sie mit einer Vorlage und kürzen Sie. Continuous-Delivery-Teams streichen oft Change-Window- und Freigabezeilen. Ein regulierter wöchentlicher Zug behält Freigaben, Kommunikation und Rollback. Speichern Sie eine zweite Vorlage, wenn zwei Produkte unterschiedliche Runbooks behalten.
Können globale Vorlagen jedes Projekt bedienen?
Ja. Jira-Administratoren speichern globale Vorlagen; Projektadministratoren speichern projektbezogene. Protected globale Runbooks sind ein starker Default, wenn mehrere Teams gleich ausliefern sollen.
Wie setzen wir die Liste nach einem Rollback zurück?
Setzen Sie eine Post Function oder ein Jira-Automation-reset-all auf den Übergang zurück von shipped, begrenzt so, dass nur die Release-Liste geleert wird. Der Automatisierungsleitfaden führt durch Reset und Completion-Validatoren.
Bringen Sie die Checkliste dorthin, wo das Team arbeitet
Checklist for Jira legt Vorlagen, Automatisierung und Workflow-Prüfungen direkt auf den Vorgang. Kostenlos für Teams mit bis zu 10 Benutzern — ohne extra Subtasks.