# DevOps Delivery Checklist

**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 | | |