Release Gate Review (QA)

Release Gate Review (QA)

1. 01

   Freeze the release branch and record the exact commit hash under review

   Tag the build so any rollback points to a known artifact rather than a moving branch head. Note the hash in the client's delivery log.

2. 02

   Confirm every environment variable and secret exists in the target environment

   Missing keys are the most common cause of a green build failing on first production request. Diff the staging and production variable lists before promotion.

3. 03

   Run the full automated test suite against the release candidate, not the mainline

   A passing suite on main proves nothing about the tagged build. Capture the run ID and attach it to the release record.

4. 04

   Verify rollback works before you need it

   Trigger a rollback on staging and time it. DeployHQ and Railway both expose one-click or single-command rollback paths; confirm the client's stack has an equivalent and that someone on the retainer knows where it lives.

5. 05

   Gate risky changes behind a feature flag rather than a deploy decision

   FeatureFlags.app and similar flag layers let a team ship code dark and enable it per client or per cohort. This separates the release event from the exposure event, which shortens incident response.

6. 06

   Get written client sign-off on the change window and the rollback owner

   Name one person on the agency side and one on the client side. Ambiguous ownership during a failed release is what turns a 20-minute incident into a weekend.

7. 07

   Publish a one-page release note to the client channel within 24 hours

   List what shipped, what changed for end users, and what to watch. This is the artifact that justifies the retainer when nothing breaks.