The deployment pipeline checklist: from scary releases to boring ones
A working pipeline runs tests on every commit, builds one artefact and promotes it unchanged, deploys a preview per pull request, then to staging and production behind the same automation — with a rollback that takes one command and under a minute.
Key takeaways
- Optimise for recovery time, not for preventing every bad deploy.
- Build the artefact once and promote it; rebuilding per environment reintroduces the differences you were avoiding.
- Keep the commit pipeline under five minutes or people bypass it.
- An untested backup is a hope, not a backup.
'Nobody deploys on a Friday' is usually treated as a joke about engineering culture. It is a description of a broken pipeline: no automated tests, no staging that matches production, and a deployment process living in one person's terminal history.
The stages, in order
A pipeline that earns its keep
- On every commit: lint, type check and unit tests, finishing in under five minutes.
- Build once, producing a single artefact promoted through environments unchanged.
- A preview environment per pull request, with the URL in the PR so reviewers look at the thing rather than the diff.
- Staging deploy on merge, with integration tests running against it.
- Production deploy with health checks and automatic rollback on failure.
- Secrets in a secret store, never in the repository, rotated on a schedule.
- Every deploy recorded — who, what commit, when — so an incident timeline reconstructs itself.
Where most teams actually are
| Level | Looks like | First thing to fix |
|---|---|---|
| 0 — manual | Someone SSHes in and pulls | Get the deploy into a script anyone can run |
| 1 — scripted | One command, run by two people | Automated tests on commit |
| 2 — automated | Merge deploys to staging | Preview environments and rollback |
| 3 — routine | Deploys are unremarkable, rollback is one command | Cost and capacity |
Infrastructure as code, and why
Deployments normalise file timestamps and machines get rebuilt. Capturing infrastructure as code means the environment can be recreated exactly in a new region or account without archaeology — and it is the only honest disaster recovery plan, because it is the only one you can rehearse.
Monitoring you would wake up for
Alert on the symptoms customers feel — error rate, latency, failed payments, a checkout that stopped completing — rather than on CPU. An alert set that has been ignored for a month is worse than none, because it creates false confidence.
The cloud bill
Bills rarely grow because of a decision; they grow through the absence of one. Non-production environments running twenty-four hours a day pay for roughly three times the hours anyone uses, and a scheduled shutdown outside working hours carries no production risk. More in cloud cost optimisation and CI/CD pipeline setup.