What this template is for
Deployment checklists are how teams stop having outages from things they already know how to avoid. Most production incidents from deploys come not from new failures but from skipped steps: someone forgot the cache warm-up, someone didn’t post in #deploys, someone deployed during the wrong window.
This template structures both layers:
- Fields on the deploy ticket - window, operator, on-call, pre-deploy validation, smoke tests, rollback plan, rollback trigger. The rollback-plan and rollback-trigger fields together force the team to define ‘how do we know to revert?’ before the deploy starts.
- STM-created sub-tasks - pre-deploy validation, deploy execution, smoke tests, monitor, rollback-if-needed, post-deploy update. Created the moment the deploy ticket is opened so the operator has a checklist instead of muscle memory.
When to use it
Use this template for non-routine deploys: out-of-band releases, hotfixes, multi-service coordinated deploys, schema migrations, infrastructure changes that touch production.
For routine pipeline deploys, don’t file a ticket per deploy - your CI/CD system is the deployment record. If a routine deploy goes wrong, the resulting work belongs on the incident-response template, not retroactively as a deployment checklist.
Fields to add to your Jira create screen
These are the fields a project admin should make sure exist on the Create Issue screen for this issue type (Project settings → Screens). Without these on the screen, reporters can't provide the information triage needs - and STM can't reference them either.
| Field | Example value | Required |
|---|---|---|
Summary | Deploy 4.13.0 to production - checkout redesign + 12 fixes | Yes |
Release Version | 4.13.0 | Yes |
Deployment Window | 2026-05-29 06:00-08:00 UTC | Yes |
Deployment Type (custom) | Normal / Hotfix / Schema change / Multi-step | Yes |
Deploy Operator | @release-engineer.on.duty | Yes |
On-Call During Deploy | @platform-oncall - has been notified | No |
Pre-Deploy Validation (custom) | Staging green; load tests passed; feature flags configured | Yes |
Smoke Tests (custom) | List of post-deploy checks with expected results | Yes |
Rollback Plan (custom) | Specific command/runbook - not 'roll back' | Yes |
Rollback Trigger (custom) | What metric or check forces a rollback? | Yes |
Customer Communication (custom) | Status-page posted? Email sent? | No |
Linked Release | RELEASE-4130 | No |
Note on custom fields. STM currently supports up to 5 custom fields per template. You can add as many custom fields as you like to your Jira Create Issue screen - the 5-field limit only applies if you want STM to set or update those custom fields itself.
Sub-tasks STM creates automatically
Build an STM sub-task template containing the items below, then wire it to an On Create Issue Executor scoped to this issue type. Whenever a new issue of this type is created in the project, STM creates the full sub-task set in one step - with assignee, due date, and components inherited from the parent unless you override them.
- Pre-deploy: confirm staging is green and load tests pass
- Pre-deploy: post in #deploys with deploy window and on-call confirmation
- Execute deploy steps in order per the runbook
- Run smoke tests in production - all must pass
- Monitor key metrics for 30 minutes post-deploy
- If rollback triggered: execute rollback plan and confirm restoration
- Post-deploy: update release ticket with outcome and any deviations
Common questions
What's the difference between a deployment checklist and a change request?
Change requests are for non-routine production changes that need risk assessment and CAB review. Deployment checklists are for routine but high-stakes deploys that follow a predictable pattern. A schema migration is a change request. A regular release of pre-tested code is a deployment checklist. Many teams use both for different categories of work.
Should every Jira deployment have a checklist ticket?
No - routine deploys through the CI/CD pipeline should not generate a ticket per deploy. Use this template for deploys that are non-routine: out-of-band releases, hotfixes, multi-service deploys, schema migrations, or any deploy where 'just run the pipeline' would be inadequate. If you're filing checklist tickets for every deploy, your pipeline doesn't trust itself yet.
What makes a deployment rollback plan adequate?
Specific commands, not directions. 'Run terraform apply on the previous version' is not a rollback plan. 'kubectl rollout undo deployment/checkout-api -n prod; verify with `kubectl rollout status` until COMPLETE; confirm checkout_api_requests_total in Grafana within 5%' is. The on-call engineer at 3am can execute the second version; the first will not survive contact with reality.
Who owns smoke tests on a Jira deployment ticket?
The deploy operator runs them; the engineering team that owns the deployed service writes them. Smoke tests are not 'does it return 200' - they are 'does the user-visible behaviour that this deploy was supposed to ship actually work in production'. Treat smoke tests as part of the deployment artifact, updated every release.
Automate the sub-tasks with STM
STM Issue Templates saves the sub-task list above as a reusable template and creates them on every new issue of this type - via an Executor on issue creation, on status transition, or triggered manually from the issue's "Create bulk sub-tasks" menu. STM does not change the parent issue's create screen (that's a Jira project-settings job) but it removes the manual work of creating the sub-tasks every time.
Try STM on the Atlassian Marketplace ↗ See how STM templates are built →