Four-eyes principle for deployments: enforcing approvals technically

Goal

Catch errors and misuse that a single person, or a single agent acting with that person's permissions, could introduce before they reach production, without making the process depend on trust and memory.

Prerequisites

A version control and CI system that supports rules per branch and per environment: GitHub offers protected branches and environments with "Required reviewers"; GitLab offers approvals for deployments ("Deployment approvals"). At least two people with review permissions. Deployment that runs only from CI and only from the main branch.

Steps

1. Protect the main branch: forbid direct pushes, require at least one approval, dismiss approvals when new commits are pushed (GitHub: "Dismiss stale pull request approvals when new commits are pushed"), and register the CI status checks as required.
2. Rule out self-approval: the person who creates the change proposal does not approve it themselves. For sensitive paths (deploy scripts, infrastructure, permissions), require a second, named group via a code owners file.
3. Set up production as its own environment with an approval requirement, so that the deploy job waits until an authorized person approves it. This is separate from code review, because the timing and context of a release are a decision of their own.
4. Close the bypasses: administrators are subject to the same rules ("Do not allow bypassing the above settings"); deploy credentials exist only in CI, not on workstations.
5. Define an emergency path that defers the principle rather than breaking it: an emergency deployment requires a second person on the phone, is marked as such, and is reviewed retroactively no later than the next working day.
6. Check regularly: who has review permissions, which rules were bypassed according to the audit log, and which approvals came so quickly that nobody can have read the change.

Expected result

Every change in production can be traced back to two people: the author and the approver. A compromised workstation or a misdirected agent cannot ship a build on its own.

Limits and test basis

The principle verifies that someone looked, not how thoroughly; rubber-stamp reviews undermine it, and only a review culture and spot checks help against that, not tooling. Two people working together can circumvent it; logs and separation of roles help against that. The settings named here follow the cited GitHub and GitLab documentation; no claim is made about the effect on error rates.