Release Planning

Purpose: Align engineering, product, and stakeholders on the scope, timeline, and risk of an upcoming release

How to run this meeting

Define your go/no-go criteria before you talk about anything else. A release plan without explicit criteria for what would cause you to delay or roll back is just a schedule — not a plan. Ask the room: "What would have to be true for us to pull this release at the last minute?" Write those conditions down. Then make sure the testing strategy actually validates those conditions.

Identify a release captain — one person who owns the release end to end, from code freeze through post-release monitoring. This person is not necessarily the most senior engineer; they're the person who will track open items, run the go/no-go call, coordinate the rollout, and make the call to roll back if needed. Without a named captain, accountability diffuses across the team and things fall through the cracks.

Treat rollback as a first-class plan, not an afterthought. Walk through the rollback procedure explicitly, including estimated time to rollback, any data migration concerns, and how you'll communicate to customers if rollback is needed. If you can't describe your rollback procedure in under two minutes, your release is not ready to plan.

Before the meeting

• Confirm the full feature scope for this release (nothing ambiguous on the list)
• Identify all cross-team and external dependencies
• Run a preliminary risk assessment before the meeting, not during it
• Ensure the testing strategy has been drafted by QA or the test-owning team
• Prepare a draft rollout plan including any phased rollout or feature flag approach
• Schedule a go/no-go decision checkpoint 24–48 hours before the release date

Meeting Details

• Date:
• Facilitator:
• Attendees:
• Duration: 60–90 minutes

---

Release Goals

What this release accomplishes for users and the business. One to three clear outcomes.

• Enable merchants to process international payments in 12 new currencies
• Reduce checkout abandonment by eliminating the secondary confirmation step (A/B validated in beta)
• Resolve 3 high-severity bugs reported by enterprise customers since v2.13

Version: v2.15.0 Target release date: 2026-03-28 Code freeze: 2026-03-25 EOD

---

Key Features

Enumerate everything included in this release. No surprises allowed — if it's not listed here, it's not in scope.

---

Dependencies

External systems, teams, or vendors that need to deliver something for this release to succeed.

---

Risk Assessment

What could go wrong, how likely, and how bad. Mitigation should be specific.

---

Cutoff Date

Hard deadlines within the release cycle. Anything that misses these dates does not ship in this release.

• Feature cutoff: 2026-03-20 (no new features after this date)
• Code freeze: 2026-03-25 EOD
• Go/no-go decision: 2026-03-27 at 10:00 UTC
• Release window: 2026-03-28 09:00–11:00 UTC

Go/no-go criteria — release proceeds only if:

• All P0 and P1 bugs from QA are resolved
• Load test results show < 5% degradation vs. baseline
• Legal sign-off received
• Rollback procedure has been tested in staging

---

Testing Strategy

How the release will be validated before it ships. Be specific — "we'll test it" is not a strategy.

• Unit/integration tests: Must pass at 100% in CI. No bypass.
• QA regression: @qa-lead running full checkout regression suite plus multi-currency scenarios. Estimated: 3 days (March 22–24).
• Load test: Infra team running 2x peak traffic simulation on March 24. Results reviewed at go/no-go call.
• Beta testing: Multi-currency feature enabled for 5 internal merchant accounts starting March 21.
• Staging validation: All bug fixes verified in staging before code freeze.

---

Rollout Plan

How the release reaches production. Define the sequence, who's involved, and when to stop.

1. Deploy to staging — March 26 (post-code-freeze validation)
2. Deploy to production — March 28, 09:00 UTC (maintenance window)
3. Smoke test production — 09:15–09:30 UTC, @dev-ops and @dev on call
4. Enable simplified_checkout_v2 for 5% of traffic — 09:30 UTC
5. Monitor conversion and error rates for 2 hours
6. Expand to 50% then 100% — March 28 afternoon if metrics hold
7. Enable multi_currency_enabled per-merchant as Stripe keys are provisioned

Rollback trigger: Error rate on /v1/checkout exceeds 1% OR conversion drops more than 5% relative to control. @release-captain makes rollback call. Estimated rollback time: < 10 minutes (feature flags) or 25 minutes (full deploy rollback).

---

Action Items

Follow-up

The release captain owns all items from this point forward. Open a dedicated Slack channel (#release-v2-15) for release coordination and add all stakeholders. Post a release plan summary to the engineering and product channels. The go/no-go call should be a brief (15-minute) meeting with clear pass/fail criteria — not a discussion. After the release, the captain should send a brief release summary noting what shipped, any issues encountered, and any follow-up actions for v2.15.1.