Release Candidate Sign-off Workflow
Distribute one candidate to staged sign-offs from QA, security, product, and operations, tracking each as a gate before final tagging.
Objective
Convert scattered opinions into an explicit sign-off checklist where each role approves the same artifact or blocks with a reason.
Environment
- A deployable release candidate artifact
- Named owners for QA, security, product, and operations
- A shared checklist or issue tracking the release
Steps
1. Publish the candidate once
Build a single RC artifact from the tag and register it in the release checklist as the only object under sign-off.
Expected state: Every reviewer references the same artifact hash, not their own local build.
2. Stage the sign-offs in order
Run QA verification first, security scan second, product acceptance third, and operations deploy rehearsal last, so each stage inherits a pre-verified candidate.
Expected state: Each gate records pass or block with evidence links, and a block halts the queue.
3. Collect evidence per gate
Require each sign-off to attach its evidence: test run IDs, scan reports, acceptance notes, or rehearsal logs.
Expected state: No gate is marked approved without an artifact-backed reference.
4. Handle blocks with reruns
When a gate blocks, fix on main, cherry-pick a new RC, and restart the sign-off chain from the gate that blocked, keeping earlier passes valid only if the change is provably scoped.
Expected state: The checklist shows which approvals carried over and which were rerun for the new hash.
5. Tag final on full approval
Promote the RC to the final tag only when all gates are green on the same hash, and record the sign-off set in the release metadata.
Expected state: The final release metadata lists each approver, gate, and evidence link.
Decision points
Restart all gates on a new RC or only from the blocking one?
- Full restart
- Scoped carry-over
Scoped carry-over when the cherry-pick touches one area with the blocking team confirming scope; full restart for anything crossing boundaries.
Who can waive a gate?
- Nobody
- Release manager with written rationale
Allow a documented waiver by the release manager for low-risk timing issues, but never for security gates.
Expected outcome
A release where every stakeholder approved the exact artifact that shipped, with evidence attached and reruns traceable per gate.
Verification
The release metadata enumerates all gates as approved on the shipped hash, and any evidence link resolves to a run against that same hash.
Sign-off on the artifact, not on the idea
Opinions like looks good to me drift into noise when they attach to branches instead of artifacts. The workflow binds every approval to one artifact hash, staged so each reviewer inherits a verified candidate, and the final tag ships only the hash everyone actually approved.
RC2 sha256:9f21c... gates:
QA PASS run #4821 (regression 412/412)
Security PASS scan 2026-10-21 (0 high)
Product PASS acceptance notes v1.8
Ops PASS rehearsal log (staging deploy 11m)
------------------------------
FINAL TAG v1.8.0 -> sha256:9f21c...
RC3 (fix for QA block) sha256:44be0...
QA PASS run #4837 <- rerun
Security CARRY (confirmed in-scope)
Product CARRY
Ops RERUN (deploy touched)Evidence or it did not happen
An approved checkbox without a run ID is a liability: when something breaks post-release, the question becomes who verified what, and opinions are not auditable. Requiring evidence links makes each gate falsifiable and each approval defensible months later.
Scoped carry-over keeps reruns cheap
Restarting every gate for a one-line fix burns a day of reviewer time and teaches people to wave changes through. Rerunning from the blocking gate, with the affected teams confirming scope, keeps rigor where it matters and speed where it does not.