Deployment Plan Checklist

Branch from main and tag the build using semver (e.g., v2024.45.0-rc.1). Confirm every PR merged since the last release has a changelog entry — release-notes drift is the single most common day-of surprise.

Deploy the release candidate to staging and run the full Playwright/Cypress e2e suite. Investigate any failures — don't merge a flaky-rerun habit into the release path. QA smoke-tests critical user paths (login, billing, primary workflow) on the staged build.

Verify the previous container image is still in the registry (not pruned), the previous Helm release is rollback-able, and any DB migration in this release is reversible — or has a documented forward-fix. A rollback plan that's never been tested isn't a rollback plan.

Check PagerDuty / Incident.io for active incidents. Deploying on top of a live SEV1 conflates the rollback signal with the existing incident and turns a ten-minute revert into a two-hour war room.

Announce the release window, scope, release captain, and rollback contact. Lock main to release-blocking PRs only for the duration of the window so a stray merge doesn't ride along untested.

Apply schema changes before the application deploy so the new code lands on a compatible schema. For Postgres, use CREATE INDEX CONCURRENTLY and avoid ADD COLUMN with a default on large tables — that triggers a full table rewrite under exclusive lock. Watch replication lag throughout.

Route 5% of production traffic to the new backend image. Watch the error-rate and p99 latency dashboards for at least 10 minutes before promoting. The canary catches schema-mismatch and config-drift bugs that slipped past staging.

Roll out 25% → 50% → 100%, watching golden signals (latency, traffic, errors, saturation) at each step. Hold at each percentage for at least 5 minutes; a regression that affects 1% of requests doesn't show at 5% traffic in 60 seconds.

Frontend ships after the backend is fully out, since the backend is forward-compatible with the old frontend but not vice-versa. Invalidate the CDN cache for the index document and confirm the new bundle hash is being served.

Page the release captain and post a rollback declaration so the team stops merging and starts watching. If customers are affected, open an incident in PagerDuty/Incident.io and assign an IC — don't try to roll back and run comms simultaneously.

Redeploy the prior known-good image tag (recorded pre-deploy). For Helm, helm rollback <release> <previous-revision>. If the migration is non-reversible, deploy a forward-fix image instead — never run a destructive down-migration against live data.

Hold the release-captain seat for 30 minutes post-deploy, eyes on Datadog/Grafana. Watch for slow regressions that didn't trigger the canary — N+1 queries on a code path that only fires for paying customers, for example.

Filter Sentry to errors first seen in the last hour. New signatures from the deploy show up here before they show up in dashboards or support tickets. Triage critical and high severity to a hotfix ticket immediately.

Enable any flags scheduled to flip with this release in LaunchDarkly / Unleash / Statsig. Flip gradually (internal users → 1% → 10% → 100%) for customer-visible changes; a flag flip is a deploy, not a config change.

Promote the rc tag to the final release tag (e.g., v2024.45.0) on the deployed sha. This is the artifact bisect tooling and rollback playbooks rely on — skipping it makes the next post-mortem harder.

Update the public changelog and the in-app release notes. Update the status page if a user-visible feature shipped. Send the release summary to #engineering and #support so everyone sees what's now in production.