Approvals for risky actions

A protected project does not let one person replace or remove it on their own. Deploys, rollbacks and deletions become requests that someone else approves.

What is gated#

Only the three actions that replace or remove what is live are gated. Everything else is reversible, and gating reversible things trains people to click Approve without reading — which is worse than not gating at all.

Turning it on#

Open the project and mark it protected. This needs the project.protect permission, which Owner, Admin and DevOps have by default.

The flow#

1. Someone requests a deploy, rollback or delete.
2. The project shows as waiting for approval, and the request appears for people who can approve it.
3. An approver reviews and approves or rejects.
4. On approval, the action runs. On rejection, nothing happens.

Both the request and the decision are recorded in the audit log, including who asked and who approved.

Who can approve#

Anyone with permission for the underlying action — someone who could have done the deploy themselves. The point is a second pair of eyes, not a separate approver role.

When it gets in the way#

If approvals are slowing down a project that does not need them, take the protection off that project rather than working around it. A protected project that everybody has learned to rubber-stamp is worse than an unprotected one, because it looks like a control and is not.