A Boring Release Checklist for Small Services

Photo: Unsplash.

A release checklist should be boring enough to use on an ordinary Tuesday. It is not a ceremony; it is a short defense against forgetting the same things under pressure.

Before deployment

• The exact commit or image digest is recorded.
• Tests and the production build pass from a clean checkout.
• Database migrations are reviewed for locks, duration, and compatibility with the old application version.
• New configuration and secrets exist in the target environment without printing their values.
• A recent backup is available when the change affects persistent data.
• The rollback action is written down and still possible after any migration.

During deployment

• Announce the start in the place your team actually watches.
• Change one environment at a time.
• Save command output or deployment identifiers.
• Stop when an assumption is false; do not stack improvised fixes onto a partially understood state.

After deployment

• Confirm the deployed version from the running service.
• Test one representative user path, not only /health.
• Check error rate, latency, saturation, and background jobs.
• Verify that logs contain no new repeating warning.
• Watch for at least one normal processing interval before declaring success.

For a static blog, the same idea becomes simpler: build, check broken internal links, verify a representative post and asset, confirm the production commit, then inspect the live site from outside the deployment network.

Keep the checklist beside the code and revise it after incidents. If an item never changes a decision, remove it. If a surprise repeats, add the smallest check that would have caught it.