What is a release checklist?
A release checklist turns the production launch into tickable steps on the work item: pre-release readiness, build and artifacts, change approval, the deploy itself, smoke tests and monitoring, rollback, and closure. The headings stay stable; the ticks, SHAs, and notes change with each deploy.
Teams ship in different ways. Continuous delivery teams will drop the change-window rows. Weekly release trains will keep them. Treat the list as a starting runbook, then save your version so Friday's production change does not depend on memory.
Why teams keep the release checklist on the issue
A runbook that lives in a wiki page or a Slack thread is easy to miss when the deploy starts. A checklist on the work item keeps the SHA, the window, the smoke tests, and the rollback path where the change already lives — release managers, on-call, and developers see the same remaining work.
The same scaffold applies whether you ship continuously or in a change window: you open the issue, see what is left, tick as you go, and write what happened when something is off. High-risk releases keep approval, comms, and rollback rows; a small flag flip can drop them.
When to apply it
Use a release checklist when a change is heading to production — on the story that ships, or on a dedicated change issue when the deploy has its own owner, dates, and workflow. Auto-apply it when status becomes Ready to release or Deploying so the runbook appears before the window. Trim rows for low-risk continuous deploys; keep approval, comms, and rollback when the change is user-facing or hard to reverse.
Release vs QA testing vs Definition of Done
The QA testing checklist is the test pass before you open the window. Definition of Done is the shared exit bar on the story — review, tests, and release readiness every item owes at the end. The release checklist is the launch runbook on the change that actually ships. Keep them as separate lists so the test pass, the ship bar, and the production window stay distinct. Acceptance criteria still describe the behavior you are putting live.
Release and deployment — an example to start with
To build your first release checklist, start with the example below. Copy the list and paste it into the Checklist for Jira input field on a change or release work item. Ideally, save it as a template and auto-apply it when work moves to Ready to release — that gives every deploy a consistent scaffold and reuses the same headings each time. Trim rows your team skips; add ones your process needs.
Release and deployment
- Pre-release readiness
- Change, feature flag, and ticket keys are listed on this work item
- Stakeholders and on-call know the window, or the reason it is continuous
- Risk, blast radius, and what to watch are written on the work item
- Build and artifacts
- Build artifact or commit SHA is recorded
- Pre-prod or staging verification is done, or waived in writing
- Secrets, certificates, and deploy access are in place
- Security and change approval
- Security review or threat notes are linked when the change is sensitive
- Approvals required by your policy are recorded on the work item
- Deploy
- Production deploy steps ran in the documented order
- Migrations or config changes completed without unanswered errors
- Feature flags match the intended audience
- Smoke testing and monitoring
- Smoke tests on the production path passed
- Error rate, latency, and business KPIs look normal for the window
- Monitoring dashboards and alerts for the changed service are open
- Rollback, comms, and closure
- Rollback or disable path is tested enough to use
- Support, success, or status page is updated when users can see the change
- Incident or follow-up work item is linked when the release caused harm
- Post-release notes and leftover tasks are captured on this issue
That scaffold belongs on the change that ships. In Checklist for Jira you add or tick items on the issue panel, save the headings as a project or global template, and auto-apply it when status becomes Ready to release — or apply it manually from Add → Add from template whenever you need it.
Put this on the work item with Checklist for Jira
Templates, automation, workflow gates, and a Rovo agent — free for teams of up to 10 users.
Save a starter, automate the runbook
- Checklist for Jira adds a checklist panel on the issue view. Paste the example above on a change or release work item, adjust rows for your process, then save the shape as a project or global template in Checklist settings.
- Mark the template Protected if you want the runbook locked while people tick items — so the steps cannot quietly shrink from one deploy to the next.
- Use per-template automation to attach the release scaffold when status becomes Ready to release or Deploying. These automations are built into Checklist for Jira and run without Jira Automation credits.
- If your team wants a hard gate, add a completion validator on the shipped status, scoped to this template only. A post function can reset the list if you roll back and try again. Jira Automation can apply, complete, or reset the same list when the condition is richer than a single status.
- Pair with the QA testing checklist before the window and Definition of Done on the story — see the automation guide.
Pair it with the rest of the delivery set
Keep the QA testing checklist on the issue until the pass is green. Attach Definition of Done on the story so the ship bar is visible from day one. Use Definition of Ready during refinement if intake quality helps your team. Browse the template hub for the full set.
FAQ
Should the release live on a separate Jira issue?
If the deploy is a real project with its own owner, dates, and workflow, a dedicated issue or sub-task is right. If the runbook is a list of checks on a change you already have, keep a checklist on that work item.
Does every team need the same release checklist?
No. Start from one template, then trim. Continuous delivery teams often drop change-window and approval rows. A regulated weekly train will keep approvals, comms, and rollback. Save a second template when two products keep different runbooks.
Can global templates serve every project?
Yes. Jira administrators save global templates; project administrators save project ones. Protected global runbooks are a strong default when several teams should ship the same way.
How do we reset the list after a rollback?
Add a post function or a Jira Automation reset-all on the transition back from shipped, scoped so only the release list clears. The automation guide walks through reset and completion validators.
Put this on the work item with Checklist for Jira
Templates, automation, workflow gates, and a Rovo agent — free for teams of up to 10 users.