v1.0 to v2.0

+ Not for: safe-release techniques (flags, canary, dark launch) applied during the

+ rollout itself — use testing-in-production; scheduled probes that run continuously

+ after release — use synthetic-monitoring; designing new tests from prod telemetry —

+ use observability-driven-testing.

+ Related: testing-in-production, qa-metrics, ci-cd-integration, ai-system-testing.

+ version: "2.0"

+ "I think it's fine" ships the bug that the rollback you never practiced can't undo at 6 PM on a Friday. This skill turns "ready to ship" into something measurable: a go/no-go checklist with evidence for each item, a sub-5-minute smoke suite, a staged rollout with metric-gated promotion, rollback thresholds defined before deploy, and post-deployment verification. Every section gives concrete criteria, not aspirations.

+ Check `.agents/qa-project-context.md` first — if it exists, use it and skip anything answered there. Then ask only what's missing.

+ - How often do you release, and who makes the go/no-go call? (Continuous/daily/weekly vs engineering lead/QA lead/release manager — sets how heavyweight the checklist should be.)

+ - What does the current go/no-go process look like, and is it documented?

+ - Has a release ever been rolled back? How long did it take? (Reveals whether rollback is real or aspirational.)

+ - What was the last release incident and its root cause? Any release-blocking bugs right now?

+ - Do you have rollback capability, and how long does a rollback take?

+ - Do you have feature flags, and how are they managed? (Decides flag-based vs infra-level rollout.)

+ - What monitoring and alerting is in place? Are database migrations reversible?

+ - How are stakeholders notified, and is there a release communication channel?

+ If you wait until something is on fire to decide whether to roll back, you'll waste critical minutes debating. Define the criteria in advance, relative to baseline: "If error rate exceeds 2x baseline within 15 minutes, we roll back. No discussion needed." Tie the trigger to your DORA targets — a release whose error rate would push you past your change-failure-rate target, or whose recovery would blow your MTTR target, is one the rollback rule exists to stop.

+ Use this as a template. Adapt it to your context. Every item should be verifiable with evidence, not just "I checked." Store the completed checklist as a versioned artifact (e.g. `RELEASE-<version>.md` or a tracked issue) so sign-off is auditable.

+ - [ ] **Performance budgets met** — API response times and bundle size within thresholds; Lighthouse CI for frontend releases (skip Lighthouse for API/backend-only releases — it measures page load, not service health)

+ 3. **Core workflow** — The primary value-delivering action works (e.g., create a document, submit a form, add to cart or complete a purchase flow)

+ 4. **Data retrieval** — Key data loads correctly (dashboard populates, search returns results, product page loads)

+ - Avoid unnecessary waits — use smart waiting (wait for element, not `sleep(3000)` / `waitForTimeout`)

+ Staging is not production: it has different data volumes, traffic patterns, third-party configurations, and infrastructure scale. That gap is exactly why production and post-deployment smoke tests exist on top of staging verification.

+

+ A typical staged rollout. The same ladder expressed for flag-based rollouts adds a 25% step (see below):

+ | Partial rollout | 25-50% | 2-4 hours | Confirm stability at scale |

+ - P50 and P95 latency are within acceptable range (relative to baseline, not an absolute ceiling)

+ Define rules for automatic promotion between stages. Each gate combines an error-rate ceiling, a latency ceiling expressed **relative to baseline**, a stability window, and (at higher stages) business-metric guardrails. See `references/rollout-automation.md` for the full canary→10%→50%→100% promotion ruleset.

+ | **LaunchDarkly** | Enterprise scale; Guarded Rollouts (auto-canary analysis, GA since May 2025); AI Configs for prompt/model rollouts; agent graphs | Acquired Highlight.io in 2025 — also offers observability tied to flags |

+ | **Statsig** | Experiment-first culture; Switchback experiments (Feb 2026 update) for two-sided marketplaces; auto-tune | Acquired by OpenAI Sept 2025; still operates independently as of mid-2026, but weigh acquisition/roadmap risk before a multi-year infrastructure bet |

+ | **Harness FME** (formerly Split) | Targeted rollouts + monitoring tied to deploy pipelines; warehouse-native experimentation + flag archiving (2026) | Rebranded after Harness acquisition |

+ Vendor-native canary analysis (LaunchDarkly Guarded Rollouts, Statsig Auto-tune, Flagger) is now common — if your platform offers it, prefer it over hand-rolled rollout-policy YAML. Given the vendor churn this table documents (Statsig→OpenAI, Split→Harness FME), prefer OpenFeature-compatible SDKs (CNCF spec; Harness FME and others now standardize on it) so flag tooling stays swappable.

+ Define these thresholds BEFORE deployment. When any trigger fires, rollback begins automatically. All thresholds are relative to the measured baseline, not absolute ceilings.

+ - Notify the release channel using the rollback skeleton below

+ #### Rollback announcement skeleton

+

+ Drop this in the release channel during Step 4. For the full release + rollback templates, see `references/communication-templates.md`.

+

+ ```

+ Subject: [Rollback] v{version} — {date} {time}

+ Status: ROLLED BACK

+ Reason: {one line — e.g. error rate 4x baseline within 8 min}

+ Impact: {who was affected, for how long}

+ Current state: Running previous version v{prev_version}

+ Next steps:

+ - Root cause investigation: {owner}

+ - Fix ETA: {estimate or "investigating"}

+ ```

+

+ ---

+ ## Verification

+ Run these immediately after the deploy completes, smallest check first. Expand the error-tracker queries in `references/rollout-automation.md`.

+

+ ```bash

+ # Health endpoint returns healthy

+ curl -s https://your-app.com/health | jq .

+

+ # Response time + status in one shot

+ curl -o /dev/null -s -w "HTTP %{http_code} in %{time_total}s\n" https://your-app.com

+

+ # New errors since deploy (Sentry CLI) — should be empty

+ sentry-cli issues list --project your-project --query "firstSeen:>15m"

+

+ # Datadog: compare 5xx count for the service before vs after deploy — must not increase

+ ```

+

+ Pass criteria: health returns `healthy`, status is `200` within your latency budget, the Sentry query returns no new issues, and the post-deploy 5xx count is at or below the pre-deploy baseline.

+

+ Staging is not production — different data volumes, traffic patterns, third-party configurations, and infrastructure scale. Staging success is necessary but not sufficient evidence of readiness.

+ - Go/no-go checklist completed with evidence for each item and stored as a versioned artifact (e.g. `RELEASE-<version>.md` or a tracked issue), signed off by the named approver with a timestamp

+ - Smoke test suite run against the release candidate in staging — all tests pass (exit code 0)

+ - Rollback criteria documented as specific baseline-relative thresholds, and the rollback procedure practiced on staging at least once

+ - Staged rollout plan defined with traffic percentages, per-stage promotion criteria, and guardrail metrics for each stage

+ - Post-deployment verification commands run and passing (health 200, no new Sentry issues, 5xx count at or below baseline)

+ - **rollout-automation.md** — Automated canary→10%→50%→100% promotion criteria (baseline-relative) and post-deployment verification command snippets.

+ - **communication-templates.md** — Load when writing a release or rollback announcement: fill-in-the-blank release and rollback templates.

+ - `testing-in-production` — Overlaps directly with progressive rollout. Go there for the safe-release *techniques* (flags, canary, dark launch, guardrail metrics) applied while shipping; come here for the go/no-go *decision* that gates the release.

+ - `synthetic-monitoring` — Scheduled probes that run continuously after release. Release-readiness covers the one-shot post-deploy verification window; synthetic-monitoring covers ongoing SLA validation.

+ - `qa-metrics` — Source of the DORA evidence (change failure rate, MTTR) and error/pass-rate numbers you cite in go/no-go decisions and rollback thresholds.

+ - `ci-cd-integration` — The CI pipeline must be green as a prerequisite; go there to build the pipeline, come here to gate on it.

+ - `ai-system-testing` — When releasing AI/LLM features: prompt-version eval tests and kill-switch design. The rollout pattern here points at it.

+ - `compliance-testing` — EU AI Act / EAA / GDPR requirements that may legally gate a release before go/no-go.

+ - `playwright-automation` — Smoke tests are often implemented here; go there for the test structure, come here for which journeys are smoke-critical.

+ - `quality-postmortem` — When a release goes wrong, the postmortem feeds the missing check back into this go/no-go checklist.