Process
Release approval process for software teams
A working release approval process answers four questions for every release: who decides, what they decided, under which conditions, and where the decision is recorded. Most teams answer the first informally, the second implicitly, and skip the third and fourth entirely. That works until it does not.
The four roles
- Decision authority. The single named person who accepts or rejects the release on behalf of the business.
- Product owner. Confirms scope and accepted conditions match what was committed.
- Tech owner. Confirms readiness, observability, and rollback capability.
- Recorder. Often the same as the tech owner; responsible for ensuring the decision is captured immutably.
The four steps
- Propose. Draft the release with included scope, excluded scope, and known limitations.
- Review. Product and tech owners confirm conditions. Anything contested is resolved in writing, not in chat.
- Decide. The named authority accepts or rejects. Acceptance attaches all listed conditions to the record.
- Lock. Once finalised, the record is immutable. Edits become new versions; deletions require explicit, attributed reasons.
Where the process usually breaks
Approval drifts to whoever is loudest in standup. Conditions get summarised instead of itemised. The record lives in a doc that gets edited months later. The fix is not more process: it is a registry that enforces attribution, conditions, and immutability by design.
Stop relying on Slack threads as proof
Dockbase implements this process as a structured registry. Propose, review, decide, lock: with the audit trail captured automatically.