Release Readiness

"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.

---

Discovery Questions

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

Release cadence and process:

• 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.)
• Is there a release train schedule or is it ad-hoc?
• How many environments exist between dev and production? (staging, pre-prod, canary)

Current state:

• 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?

Infrastructure and capabilities:

• Do you have rollback capability, and how long does a rollback take?
• Can you do staged/canary deployments?
• 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?

Team and communication:

• Who is on-call during and after releases?
• How are stakeholders notified, and is there a release communication channel?
• How are release notes generated?

---

Core Principles

1. Release confidence comes from evidence, not feelings

"I think it's fine" is not a go/no-go criterion. Evidence means: all CI pipelines green, smoke tests pass on staging, performance budgets met, no open P0/P1 bugs. If you can't point to data, you're not ready.

2. Smoke tests are the last safety net, not the only safety net

Smoke tests catch catastrophic failures. They are not a substitute for thorough testing throughout the development cycle. If your smoke test suite is the only thing between you and production, you have a process problem upstream.

3. Staged rollouts reduce blast radius

Deploying to 100% of users simultaneously means 100% of users are affected by any bug. Staged rollouts (canary, percentage-based, ring-based) let you catch issues when they affect 1% of users instead of all of them.

4. Rollback criteria must be defined BEFORE release

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.

5. Every release is a learning opportunity

Post-deployment verification isn't just about catching bugs. Track what went well, what was slow, what was stressful. Improve the process continuously.

---

Go/No-Go Checklist

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-.md or a tracked issue) so sign-off is auditable.

Automated Checks (Must Pass)

• [ ] All CI pipelines green — Unit tests, integration tests, E2E tests, type checking, linting
• [ ] Smoke test suite passes on staging — Critical user journeys verified in the staging environment
• [ ] No open P0/P1 bugs for this release — Check issue tracker, filter by milestone/label
• [ ] 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)
• [ ] Security scan clean — No high/critical vulnerabilities in npm audit / Snyk / Dependabot
• [ ] API contract tests pass — No breaking changes to public APIs
• [ ] Visual regression tests pass — No unintended visual changes
• [ ] Accessibility checks pass — axe-core scan shows no new violations

Manual Checks (Verify Before Go)

• [ ] Feature flags reviewed — Document which flags are enabled/disabled in this release; confirm flag states for production
• [ ] Monitoring and alerts configured — New features have corresponding alerts (error rate, latency, business metrics)
• [ ] Rollback plan documented and tested — Written procedure exists; rollback has been practiced on staging
• [ ] Database migrations tested — Tested forward migration; backward migration verified if schema change is reversible
• [ ] Third-party dependency changes reviewed — New or upgraded external dependencies checked for breaking changes
• [ ] Release notes prepared — Changelog updated, stakeholder-facing summary written
• [ ] On-call engineer identified — Named person is available and has context on the release contents
• [ ] Communication plan ready — Stakeholders know the release is happening; support team briefed on changes
• [ ] No conflicting releases — Other teams aren't deploying simultaneously
• [ ] Deploy window confirmed — Not deploying during peak traffic or before a weekend (unless continuous deployment)

Risk Assessment

• [ ] Change scope categorized — Small (config change, copy update), Medium (new feature, refactor), Large (architecture change, migration)
• [ ] Blast radius estimated — What percentage of users could be affected if something goes wrong?
• [ ] Revert complexity assessed — Can this be reverted in 2x baseline for 5 min | Auto-rollback |

| P95 latency | >3x baseline for 5 min | Auto-rollback | | Health check | 3 consecutive failures | Auto-rollback | | Crash rate (mobile) | >0.5% | Auto-rollback | | Error budget | >50% burned in 1 hour | Auto-rollback |

Manual Rollback Triggers

These require human judgment but should have clear guidelines:

• Customer-reported critical issue — Multiple users reporting the same problem
• Data integrity concern — Evidence of corrupted or incorrect data
• Security vulnerability discovered — Active exploitation or high-severity CVE
• Monitoring blind spots — You realize you can't monitor a critical metric for the new feature
• On-call engineer judgment — The on-call engineer always has authority to trigger a rollback

Rollback Procedure

**Step 1: Decide (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.

---

## Done When

- Go/no-go checklist completed with evidence for each item and stored as a versioned artifact (e.g. `RELEASE-.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)

## Reference Files (in `references/`)

- **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.

## Related Skills

- `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.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [petrkindlmann](https://github.com/petrkindlmann)
- **Source:** [petrkindlmann/qa-skills](https://github.com/petrkindlmann/qa-skills)
- **License:** MIT
- **Homepage:** https://qa-skills.com

Install and usage instructions live in the source repository linked above.