Checklist · DevOps

DevOps Delivery Checklist

Shorten the distance between merge and live — the four measures that show whether it is working, the practices that move them, and the rollback that has to be tested rather than assumed.

Download the checklist Read the full guide

Markdown. No sign-up, no email.

Team / system: _______________ Date: _______

1. Measure first#

You cannot improve what you have not measured. Record these before changing anything.

Measure	Current	Target
Deployment frequency
Lead time (merge → production)
Change failure rate
Time to restore

[ ] All four measured, not estimated
[ ] Measured from existing records if no tooling exists — a spreadsheet is fine

2. Foundations#

[ ] Everything in version control, including infrastructure and configuration
[ ] Nothing exists only because someone typed it once
[ ] Build runs automatically on every change
[ ] Build fails visibly
[ ] Tests run automatically
[ ] One artefact built once and promoted through environments
[ ] Configuration separate from code
[ ] Secrets from a secret store, never the repository

3. Deployment#

[ ] Deployment is a script, not a sequence someone remembers
[ ] Anyone on the team can run it
[ ] Rollback procedure written
[ ] Rollback tested — not assumed
[ ] Point of no return identified
[ ] Rollback decision-maker named
[ ] Previous version kept warm for an agreed period

The most common reason an incident lasts hours is discovering during it that the rollback does not work.

4. Database changes#

[ ] Schema changes are backward-compatible — add columns before using them, remove a release later
[ ] Any version can run against any adjacent schema
[ ] Migrations tested against production-sized data
[ ] Rollback path for data changes exists, or a forward-fix is prepared

5. Change size#

[ ] Branches are short-lived
[ ] Changes merged frequently
[ ] Large batched releases avoided
[ ] Feature flags used to decouple deploying from releasing

Small frequent changes have lower failure rates than large infrequent ones. Frequency is what makes changes small.

6. Environments#

[ ] Test environment matches production in the ways that matter
[ ] Data volume and shape realistic — the most common cause of "worked in test"
[ ] Same configuration mechanism as production
[ ] Provisioned from code, not hand-built

7. Observability#

[ ] Monitoring answers "is the business function working", not just CPU
[ ] Alerts reach a person
[ ] Alerts that fire often and are ignored have been fixed or removed
[ ] Logs sufficient to diagnose without reproducing
[ ] Someone is accountable for a failing alert

8. Cost#

[ ] Non-production shut down outside working hours
[ ] Infrastructure cost attributed to a named owner
[ ] AI / inference spend tracked separately, per completed task
[ ] Reviewed monthly

9. The traps#

[ ] Not buying a platform to sit in front of an unchanged process
[ ] Not creating a "DevOps team" that deploys on behalf of everyone
[ ] Not automating a broken process — fixed the sequence first
[ ] No manual step that only one person can perform

Sign-off#

	Name	Date
Completed by
Reviewed by

Back to DevOps