Pre-Deployment Checklist
A pre deployment checklist to decide if a build is ready to ship: tests, approvals, config, migrations and rollback. Use it as a gate before every deploy.
- Typical schedule per deployment
- The checklist 5 sections, 17 items
- Variables
{{service}}{{version}}{{environment}} - Start from CI
Use this checklist as a readiness gate before a deployment starts. It answers one question: is this build, with this configuration, safe to deploy now? It does not cover the rollout itself or the checks afterwards. Pair it with a deployment checklist and a post-deployment verification checklist if you want the full flow. It fits teams that deploy several times a week and want a fast, consistent go or no-go.
Who owns it
The engineer who will run the deployment owns the run. They confirm each item or ask the right person to confirm it, for example the reviewer of a migration. If an item cannot be confirmed, the deploy waits. That rule only works if the team agrees on it in advance.
Common pitfalls
- Testing a different build. If you rebuild for production, you deploy something you did not test. Promote the same artifact through environments and compare its digest or checksum.
- New config that only exists on a laptop. A new environment variable or secret that is missing in the target environment is a classic failed deploy. Check it before you start.
- Dependencies on other teams. If your change needs another service to be deployed first, confirm it is live, not just merged.
- Bad timing. A deploy just before a marketing campaign, a billing run or a holiday has a higher cost if something breaks. Check the calendar.
You can start this run from CI right after the build passes. Some teams hold the deploy job until the run is complete, which turns the checklist into a real gate with a record of who passed it.
The checklist: Pre-deployment check: {{service}} {{version}}
Build and tests
-
CI is green on the exact commit of
{{version}} -
The artifact for
{{version}}is the same one that was tested in stagingCompare the image digest or checksum instead of the tag name.
-
Automated tests for the changed areas ran and passed
-
Known failing or skipped tests are reviewed and accepted optional
Review and approval
-
All changes in
{{version}}were reviewed by someone other than the author -
Change list or release notes for
{{version}}are available to the team -
Approval for
{{environment}}is recorded where your process requires it optional
Configuration and dependencies
-
New environment variables and secrets exist in
{{environment}} -
Feature flags for unfinished work are off in
{{environment}} -
Services or APIs this change depends on are already live in
{{environment}} -
Database migrations are reviewed and compatible with the running version
Rollback readiness
-
Previous version number and its artifact are available
-
Rollback steps are written down, including what to do about migrations
-
Recent backup of affected data stores is confirmed optional
Timing and people
-
No conflicting deploys, maintenance or important business events are planned
-
The deploying engineer and someone who knows the change are available afterwards
-
Go decision is recorded in the run
Checklist as Markdown
Start this checklist from your pipeline
After the build job passes, POST /api/v1/runs with template "Pre-deployment check: {{service}} {{version}}" and block the deploy job until the run is complete.
curl -X POST https://runbook.metastic.ch/api/v1/runs \
-H "Authorization: Bearer $RUNBOOK_TOKEN" \
-H "Content-Type: application/json" \
-d '{"template": "Pre-deployment check: {{service}} {{version}}", "variables": {"service": "…", "version": "…", "environment": "…"}}'Frequently asked questions
What is the difference between a pre-deployment and a deployment checklist?
A pre-deployment checklist is a gate. It confirms that the build, configuration and people are ready, and ends with a go or no-go decision. A deployment checklist then covers the rollout and the first checks. Splitting them keeps the gate short enough to run every time.
Can a pre-deployment checklist be automated?
Many items can be: CI status, artifact digests and the presence of config keys can be checked by scripts. Keep the judgement items manual, such as migration safety, timing and who is available. A good pattern is to automate what you can and keep a short human checklist for the rest.
What happens if an item cannot be confirmed?
The deploy waits until it can, or someone with the authority to accept the risk records that decision in the run with a reason. Skipping items quietly is how checklists lose their value.
Updated