Release Sign-Off Process: Who Approves and How
Sign-off is the point at which a release stops being one person's opinion and becomes a shared, recorded decision. A good process is short, explicit and impossible to fake.
A release sign-off is a recorded decision by a named person that a release may proceed. It exists because releases carry consequences for people other than those who build them, and those people should be able to say yes or no before the change reaches them.
The process fails in two opposite ways. In the first, there are too many approvers, each with a partial view, and the release waits on the slowest. In the second, sign-off is a formality: someone is asked, nobody answers and the release goes out. A good process avoids both by asking few people, asking for specific decisions and treating silence as no decision.
Choose the approvers
Ask the people who carry a consequence if the release goes wrong and who hold information the release owner does not. Typical roles are listed below. You will not need all of them for every release.
- Engineering lead: the change is technically sound and the tests are meaningful.
- Product owner: the scope matches what was agreed and the behaviour is acceptable.
- Quality assurance: the test evidence supports shipping.
- Security: the change has been reviewed where it touches sensitive areas.
- Operations or on-call: the team can run and, if needed, reverse the change.
- Support: they have been told and have what they need.
Scale the process to the risk
A text change and a change to payment processing should not need the same approvals. Define two or three tiers. A routine tier might need only the engineering lead. A standard tier might add the product owner and quality assurance. A high-risk tier adds security or operations, and perhaps a senior approver. State the criteria for each tier so that the release owner does not choose the tier that is most convenient.
This parallels the distinction used in IT change management between pre-approved routine changes, changes that need review, and emergency changes. See the guide to IT change management for the longer treatment.
Ask for a decision, not an acknowledgement
Each approver should give one of two answers, approve or reject, and a comment. Avoid a third state that means "seen." Seen is not a decision, and it allows a release to look approved while no one has committed.
Ask at the right time. If you ask too early, the approver is signing off on a promise. If you ask too late, you create pressure to approve because everything else is finished. The best moment is when scope is frozen and the evidence is available, with enough time to act on a rejection.
Atlas lets you choose Request sign-off, pick the people who must agree, and have each approve or reject with an optional comment. Each person asked is notified. A single request may ask at most 20 people, and a short list is better.
Make the record trustworthy
- Only the person asked can decide. A release owner who can approve on behalf of others has an approval process in name only. In Atlas, only the person who was asked can approve or reject their own sign-off.
- An approval applies to what was reviewed. If the scope changes materially after approval, ask again. In Atlas, asking the same person again resets their earlier decision to pending.
- Decisions carry comments. A rejection with a reason is the most useful artefact the process produces.
- The record is kept. Approvals, who gave them and when should be readable years later, for audit or for the review of an incident.
Handle a rejection
A rejection is not a failure of the process. It is the process working. The release owner reads the reason, decides whether the concern can be resolved, and either fixes the issue and asks again or takes the release off the schedule.
Do not ask a rejecting approver to reverse their decision without new information. Pressure of that kind teaches approvers that rejection is pointless. Atlas lists a rejected sign-off as a blocker in plain words, and the release cannot move to Released while it stands, unless a workspace owner or administrator overrides it with a recorded reason.
Common mistakes
- Asking for sign-off in a chat thread, where it cannot be found again.
- Including approvers who cannot judge the release and sign to be polite.
- Allowing approvals to carry over to a materially different release.
- Having no deputy, so that a holiday stops all releases.