Release Readiness: The Go/No-Go Checklist Before You Ship

Release readiness is a go/no-go decision made against a fixed checklist, not a feeling that the release is probably fine. Before you ship, these must be green: critical journeys pass in CI, migrations are reversible, performance holds under load, security and accessibility checks are clean, monitoring is live, and the rollback is rehearsed. One named person says go or no-go, and every accepted risk is written down.

If you would rather have a team run this each release, see how RAITHub would test this near the end. The rest is the checklist, so your own team can run it.

What is a release readiness checklist, and why go/no-go?

It is the set of gates that decide whether a build is safe to put in front of users. Framing it as go/no-go matters: a checklist you "mostly" pass is not a gate, it is a wish. Each line is a pass or a fail, and a fail means you either fix it or make a recorded, named decision to ship anyway. This mirrors how Google's SRE book treats releases: a release is cut from "the last continuous test build that successfully completed all tests", and changes to the release process should be "intentional, rather than accidental" (Google SRE Book, Release Engineering).

What does the whole go/no-go list look like on one page?

Seven gates, each with a bar to clear. If you only have an hour before a release, this table is the decision.

Gate	Bar to pass (go)	No-go if
Tests	The full suite is green; critical journeys and tenant-isolation tests pass	Any critical test is red or skipped
Data and migrations	Migrations replay from empty and are backward compatible for one release	A migration drops or renames a column the old code still reads
Performance	Key endpoints hold their latency threshold under realistic load	P95 on a revenue route is over budget
Security	Dependency and OWASP smoke checks clean; no secrets in the build; access rules enforced	A known high-severity issue on a reachable path
Accessibility	Keyboard path through critical journeys works; automated scan clean	A critical journey cannot be completed by keyboard
Monitoring	Error tracking, alerts and a health check are live and routed to a person	No alerting on the new release
Rollback	The previous release can be redeployed; the rollback has been rehearsed	Rollback is untested or the database cannot go back

This is a release gate, not a launch checklist for a first go-live; for that fuller list see the pre-launch QA checklist. The two share DNA, but release readiness runs on every release, so most of it should be automated.

Which tests must be green before a release?

The ones whose failure would cost customers or money the same day, plus the regression suite. A green pipeline is necessary but not sufficient: confirm the critical set actually ran, because a skipped job in GitHub Actions reports success and will not block a merge "even if it is a required check" (GitHub Actions: using conditions to control job execution).

• Sign-up, sign-in and the core action complete end to end.
• Payments pass in test mode: success, decline, refund and a webhook replayed twice that changes the account once.
• Tenant-isolation and role tests pass, for a SaaS. These are the SaaS-specific gate, and the test pyramid for a SaaS shows why they belong in the API layer.
• The full regression suite is green before deploy, not only the selected subset from the pull request.

Wiring these as required CI gates, so a red result blocks the release on its own, is the subject of how RAITHub tests software.

How do you gate data, migrations and rollback together?

Treat the database as the hardest thing to undo, because it is. Make schema changes backward compatible for at least one release, so the previous code still runs against the new schema and a rollback is just a redeploy.

• Replay every migration on an empty database in CI. If the schema cannot be rebuilt from code, a hand-edited table is hiding somewhere.
• Add columns first, remove old ones a release later. Never rename or drop in the same release that stops using a field.
• Rehearse the rollback. Redeploy the previous build to staging and confirm it runs against the new schema. A rollback you have never run is a guess.
• Keep a backup and know its restore time. That restore time is your real recovery figure.

Recovering from a migration that already broke production is a different job; that playbook is in a database migration broke production.

What performance and security bars belong in a release gate?

A codified latency threshold and a short security smoke check, both pass/fail so they can block automatically. For performance, k6 thresholds "are the pass/fail criteria that you define for your test metrics", and the test exits non-zero if the system misses them, failing the CI step (k6 thresholds). A typical gate is 95% of requests under 200 milliseconds and under 1% failing on the key route. For pages, hold the "good" Core Web Vitals thresholds on web.dev: LCP 2.5 seconds or less, INP 200 milliseconds or less, CLS 0.1 or less at the 75th percentile.

The security bar at release is a smoke check, not a full audit: no secrets in the build, dependency scan clean of known high-severity issues, access rules enforced on protected routes, and basic OWASP checks on new endpoints. Note the honest limit: this is application-level checking against OWASP guidance, not a CREST- or PCI-certified penetration test, and it produces no compliance attestation. If a release needs one, that is a separate, certified engagement. For accessibility, the release bar is a keyboard path through each critical journey and a clean automated scan; a full WCAG 2.2 AA audit is separate and does not certify legal compliance.

Who makes the go/no-go call, and how do you record a risk?

One named person owns the decision, with the signals in front of them. A committee that all nod is nobody deciding. When a gate fails and you still choose to ship, write it down as a decision, not a silence.

No-go gate failed: accessibility scan flags low contrast on the billing page.
Decision: SHIP. Severity low, no journey blocked.
Owner: Priya. Fix committed for the next release (TICKET-482).
Date: 2026-10-09.

"Shipping with known issue X, owner Y, fix by date Z" is a managed risk. An unrecorded gut-feel override is how the same bug ships three releases running.

How do you turn the checklist into automated gates?

Anything you check on every release belongs in CI, not in a spreadsheet. The manual list should shrink to the few things a machine cannot do.

• Automate: the test suite, migration replay, the performance threshold, the dependency and accessibility scans, and the post-deploy smoke tests. These become required checks that block a bad release on their own.
• Keep manual: the rollback rehearsal, the screen-reader pass, a real low-value production payment after launch, and the go/no-go decision itself.

Measure whether it is working with outcome metrics, not the length of the checklist: change failure rate and recovery time should fall as the gates mature. The two DORA measures to watch are defined in the DORA four keys, and the steady-state process around each deploy is in regression testing on every deploy.

Buy, build or hire?

Option	What you get	Choose this when
A CI or release tool	Required checks, deploy gates, rollback buttons	You have engineers to define the gates; the tool enforces them
Freelancers or crowdtesting	A manual pass before a big release	You need extra eyes for one release, not a repeatable gate
An in-house QA or release owner	Someone who owns the go/no-go and the gates	You ship often and can keep one person busy full time
A managed QA team (QAaaS)	A team that builds the gates, runs the checklist and reports each release	You want release readiness enforced without hiring or managing testers

How RAITHub would test this

RAITHub turns a release readiness checklist into gates on your pipeline and runs the manual residue each release.

• Scope: make the critical tests, migration replay, a performance threshold and the security and accessibility smoke checks required gates; write the post-deploy smoke set and a rehearsed rollback; define the go/no-go record.
• Ways to buy it: a monthly QA plan, a fixed-price one-off audit such as a pre-launch audit, or a dedicated QA team that RAITHub manages and bills monthly. Not staff augmentation; testers stay managed by RAITHub.
• Timeline: fixed in the written quote after a free audit, based on your pipeline and release cadence.
• What you receive: gates, tests and playbooks in your repository, a rollback runbook, a weekly report, IP assigned to you and an NDA as standard.
• The honest limits: security checks are application-level against OWASP guidance, not a certified penetration test; accessibility checks do not certify legal compliance; RAITHub is not SOC 2 or ISO 27001 certified.

Proof is the measured test counts on platforms RAITHub built: 1,024 tests on PropDesk, 750+ on TheSkinProof (the founder's own venture, not a client), 530+ on Sundor Skin, and 400+ on this site. See the pre-launch QA service and the QA as a Service hub, then book the free 15-minute technical audit.

Documentation checked on 9 October 2026.

Frequently asked questions

What is a release readiness checklist?

A fixed set of go/no-go gates you check before shipping: tests green, migrations reversible, performance within budget, security and accessibility checks clean, monitoring live and a rehearsed rollback. Each line is a pass or fail, and a fail means fix it or record a named decision to ship anyway.

Who should make the go/no-go decision?

One named person, with the gate results and the signals in front of them. A single owner decides faster and more accountably than a committee, and every accepted risk should be written down with an owner and a fix date.

How is release readiness different from a pre-launch checklist?

A pre-launch checklist is a one-time, fuller list for a first go-live. Release readiness runs on every release, so most of it should be automated into required CI gates, leaving a short manual list such as the rollback rehearsal.

What makes a release a no-go?

A red or skipped critical test, a migration that is not reversible, a performance regression on a revenue route, a known high-severity security issue on a reachable path, a critical journey that fails by keyboard, or an untested rollback.

Can the whole checklist be automated?

Most of it. The test suite, migration replay, performance threshold, dependency and accessibility scans and post-deploy smoke tests become required gates. The rollback rehearsal, screen-reader pass and the go/no-go decision stay manual.

Does passing the checklist mean the release is certified secure or compliant?

No. The security and accessibility checks are smoke checks against OWASP guidance and WCAG 2.2, not certified audits, and they produce no compliance attestation. A tender or legal sign-off needs a separate, certified engagement.