Deployment Readiness Review

Purpose: Confirm the team is ready to deploy safely and agree on a go / no-go decision

How to run this meeting

Define your rollback triggers before you ship, not after something goes wrong. A rollback plan that says "we'll roll back if there are problems" is not a plan. Write down the specific conditions that will trigger a rollback — error rate above X%, p95 latency above Y ms, a specific alert firing — and make sure the on-call engineer knows exactly what steps to take. Ambiguity in a production incident is expensive.

Assign a named on-call owner for the deployment window. "The team" is on call is the same as nobody is on call. One person should own the pager, know the rollback steps by heart, and be reachable for the first 24 hours post-deploy. Rotate this responsibility; don't let it always fall on the same person.

Verify that monitoring dashboards are set up and showing real data before the meeting ends. A dashboard that hasn't been validated doesn't exist. During the readiness review, someone should open the dashboard and confirm that the key metrics are populated and alerting thresholds are configured. If anything is missing, it's a blocker.

Before the meeting

• All P0 and P1 issues from QA review are resolved and verified
• Release branch is tagged and frozen — no new commits after this point without a process
• Runbook for the deployment is written and linked
• Rollback steps are documented and tested in staging
• Monitoring dashboards are set up and confirmed to show live data
• On-call owner is identified and has accepted the role
• Customer-facing teams (CS, support) are briefed on the feature and known issues

Meeting Details

• Date:
• Facilitator:
• Attendees:
• Duration: 30 minutes

---

Release Checklist

Walk through each item as a group. Mark each one explicitly. If anything is not ready, it's a blocker — document what needs to happen and who owns it.

---

Testing Status

Summarize the final state of testing. Link to the QA review notes. Call out any known issues shipping with this release.

QA sign-off: ✅ Received 2024-12-12 — → QA Test Review notes

Known issues shipping:

• P2: Email subject line truncated in Gmail mobile at >60 chars — tracked in Issue #1210, fix in next patch
• P2: Minor UI misalignment in Firefox on permissions table — tracked in Issue #1208, fix in next patch

Regression suite: 847 cases, 841 passed, 6 failures (all pre-existing, not introduced by this release — verified)

Load test: Passed at 500 concurrent schedules and 1.5M row report generation. Behavior beyond these limits is not validated — monitor at launch.

---

Rollback Plan

Document the specific rollback procedure and the exact conditions that will trigger it. This must be specific enough for the on-call engineer to execute alone at 2am.

Rollback triggers (any one of these fires → rollback immediately):

• Error rate on /api/reports/schedule endpoint exceeds 2% over a 5-minute window
• p95 report generation time exceeds 10 seconds for more than 10 minutes
• Any data integrity issue reported (report content incorrect or belonging to wrong workspace)
• PagerDuty alert: "Sidekiq scheduled reports queue depth > 500"

Rollback steps:

1. Disable the scheduled_reports feature flag in LaunchDarkly (immediate, no deploy required)
2. Notify @priya and @elena via Slack in #incidents
3. If flag disable is insufficient: deploy previous release tag (v2.13.1) via Deployment runbook — estimated 8 minutes
4. Post status update in #status-page channel within 15 minutes of rollback decision
5. Open a post-mortem issue within 24 hours

On-call owner: @infra-james (primary), @backend-ana (secondary) On-call window: 2024-12-13 12:00 UTC through 2024-12-14 12:00 UTC

---

Monitoring Plan

List the dashboards, alerts, and metrics that will be watched post-deploy. Confirm each is set up and showing data.

Post-deploy check: On-call engineer confirms all dashboards are green 15 minutes after deploy completes.

---

Go / No-Go Decision

Record the final decision and who made it. If no-go, document what must be resolved before the next attempt.

Decision: GO Decision maker: @elena (Engineering Lead) with sign-off from @priya (PM) Date/time: 2024-12-13 11:45 UTC Deploy window: 2024-12-13 12:00–13:00 UTC

Conditions: Rollback script must be validated in staging by @infra before deploy begins (within the deploy window). If not validated in time, on-call engineer uses manual rollback steps.

---

Action Items

Follow-up

The on-call engineer posts a deploy confirmation with dashboard screenshots in #releases once the deploy is green. If the deploy triggers a rollback, open a post-mortem within 24 hours. The PM sends a feature announcement once the deploy is confirmed stable. Schedule a post-launch review 7 days after deploy to assess metrics against the goals set in the feature kickoff.