Release Planning Checklist

Walk the Jira/Linear board for tickets tagged to this release. Each story needs a measurable AC and a definition of done — vague tickets ("improve dashboard performance") are a common source of scope creep mid-sprint. Kick anything ambiguous back to product before locking scope.

Identify tickets that depend on platform, data, or external API changes. A blocked ticket discovered on release day is the most common reason scope ships short. Link the dependency in the ticket and notify the upstream team's tech lead.

Hold a 30-minute scope-lock meeting with PM and tech lead. After this meeting, additions require a written exception from the release captain — otherwise scope creep eats the QA window.

List every flag this release introduces or flips. Include the flag key, the rollout plan (5% canary → 25% → 100%), and the named owner who will clean it up. Flags without owners become 18-month dead code paths.

Pull the Snyk or Dependabot report for the release branch. Triage anything CVSS 7+ before merge; defer lower-severity transitive findings only if the package is not on a request path. Document the deferral in the ticket.

For any new public API or webhook, walk OWASP Top 10 with the AppSec partner: authn/authz coverage, input validation, rate-limit posture, PII in logs. A 30-minute pairing session is enough for incremental changes.

Either the migration has a tested down-migration, or there is a written forward-fix plan if rollback after schema change is impossible. Dropping a column you just added is reversible; populating it from a third-party API and then deleting that column is not.

Backfills that run as a single UPDATE block writes for the duration. Chunk by primary key (e.g., 5,000 rows per batch with a 200ms sleep) and watch replication lag during the rehearsal. Use CREATE INDEX CONCURRENTLY for new indexes on Postgres.

Check PagerDuty for the deploy window and the four hours after. Release captain plus primary on-call must both be online; a vacation collision is a common reason hotfixes get botched.

Block Tuesday 10am–12pm (or your team's standard window). Avoid Fridays and the day before a holiday — if something breaks Saturday morning, the on-call carries it alone.

Cut the release branch, tag -rc.1, and run Playwright/Cypress in the staging pipeline. Investigate every red — "just rerun, it's flaky" is how real regressions slip through. Open tickets for any flakes you defer.

Map the merged PRs to user-facing surfaces. Auth, billing, and primary checkout paths get manual smoke regardless of automated coverage; secondary surfaces only if a PR touched them.

QA lead records the verdict, attaches the test report, and notes any deferred bugs. "Pass with notes" is allowed for cosmetic issues with a tracked follow-up; functional regressions are Fail.

Generate the draft from changelog entries, then strip internal jargon. Group by feature/fix/breaking change. Anything marked breaking needs a migration note for API consumers and a 90-day deprecation window if it changes existing endpoints.

15-minute walkthrough with the support lead. Cover what changed, expected ticket categories, and the engineer to escalate to. Without this brief, support backlog spikes the day after release.

Pull-test the prior version's image tag from ECR/GCR. Image lifecycle policies sometimes prune the very tag you need to roll back to — discovering this during an incident is too late.

Read the runbook out loud with the on-call engineer. Confirm every command works against the current cluster — kubectl contexts, deploy script flags, feature-flag kill switches. Update anything stale before deploy day.

Open the Datadog/Grafana service dashboards. New endpoints need RED-method panels (rate, errors, duration). A new service shipping without a dashboard is a guaranteed blind spot during the post-deploy window.

Establish baseline p99 latency and error-rate burn-rate alerts. Route to the on-call rotation in PagerDuty, not a dead Slack channel — the cert-renewal failure pattern lives here too.