A Production Deployment Checklist: Before, During and After

Run this list for any release that isn't trivial:

1. The change has passed CI, including tests and a production build, on the exact commit you're shipping.
2. A second person has reviewed it, and the reviewer knows what could go wrong.
3. Database migrations are backward compatible, so the old code still works against the new schema.
4. New configuration and secrets exist in the production environment already, not only in staging.
5. You know the rollback method and it has been tried in the last few months.
6. Dashboards and alerts for the affected area are open and healthy, so you know what "normal" looks like.
7. Nothing else risky is shipping in the same window, and support knows about the release.

Avoid deploying right before a weekend or when the person who knows the change best is unavailable.

Release size is a hidden risk factor. A release containing one change is easy to reason about and easy to roll back. A release bundling twenty changes turns every problem into a search. If several changes are waiting, ship them separately, or use flags so they can be turned on one at a time.

Schema changes cause many rollbacks that code alone wouldn't. Use the expand and contract pattern:

1. Expand: add the new column or table without removing anything, and keep it optional.
2. Deploy code that writes to both old and new structures and reads from the old.
3. Backfill existing rows in batches, watching load.
4. Switch reads to the new structure and monitor.
5. Contract: in a later release, remove the old column once nothing uses it.

Each step can be rolled back on its own. Never combine a destructive schema change with the release that stops using the old structure, and avoid long locks on large tables during business hours.

Yes, because they separate deploying code from turning it on. Ship the change dark, enable it for internal users, then a small percentage of customers, and widen as the metrics stay healthy. If something breaks, switching the flag off is faster than redeploying.

A feature flag service such as LaunchDarkly gives you targeting and an audit trail, but even a simple flag in configuration works to start. Two cautions: flags are debt, so remove them once a feature is fully released, and test both flag states, since the off path breaks silently. Change failure rate is the metric that tells you whether your process works. In DORA's 2024 clusters, the highest-performing group reported a change failure rate of about 5%¹.

Don't walk away when the pipeline turns green. Spend the first fifteen minutes checking:

• Error rate, latency and saturation for the affected services compared to the hour before.
• One real end-to-end path, such as signing in and completing the action the release changed.
• Logs for new error messages, and background job queues for growing backlogs.
• Customer-facing signals: support inbox, status of key integrations.

Define ahead of time the trigger for rollback, such as error rate above a set level for five minutes, so nobody debates it during an incident. Then record the release in a changelog with the time, the commit and anything odd you noticed.

Tier it. Small, low-risk changes with automated checks and a flag get the automated path and no meeting. Anything touching data, billing or authentication gets the full list and a named person on watch. After every failed release, add one item that would have caught it, and remove items nobody has needed in a year. Put the list in your deploy tooling, such as a pull request template or a required job in GitHub Actions, so it runs by default rather than by memory.