No ownership or CODEOWNERS — the repository without a reviewer map

A repository that ships infrastructure changes to production without CODEOWNERS is a repository where “anyone can review anything”. That sentence sounds collaborative and it is - it is also the precise failure mode that produces a junior engineer merging a database password change with approval from a frontend teammate who did not realise they were the only reviewer.

Four signals that ownership is missing

A code review on a production-impacting change is functioning correctly when four signals are present:

• The reviewer is named in CODEOWNERS for the touched paths. Not “anyone with merge rights”.
• Branch protection requires review from Code Owners. The forge refuses to merge until an owner has approved.
• Sensitive paths have mandatory co-owners. A production Terraform directory has the platform team as primary owner and the security team as mandatory co-owner.
• A test PR verifies the wiring. Touching an owned path with a non-owner approval produces a blocked merge.

flowchart LR
    A["PR opened"] --> B["forge reads CODEOWNERS"]
    B --> C["owners assigned"]
    C --> D{"branch protection on?"}
    D -->|"yes"| E["owner approval required"]
    D -->|"no"| F["owners assigned only"]
    F --> G["any two reviewers count"]
    E --> H["merge allowed"]
    G --> H

If any of these signals is missing, ownership is documentation rather than a control.

Why CODEOWNERS alone is not enough

Part XXXI covers this in detail; the version that applies to infrastructure repositories is sharper. A CODEOWNERS file is plain text in the repository. The forge reads it when a pull request is opened and uses it to assign reviewers. Without the matching branch protection setting - “Require review from Code Owners” on GitHub, codeowner_approval_required on GitLab, branch permission on Bitbucket - the assignment is a suggestion, not a gate. Two non-owner approvals satisfy a generic “two approvals” rule, and the change lands.

# CODEOWNERS - infrastructure monorepo
*                           @platform/platform-infra
/terraform/                 @platform/platform-infra
/terraform/prod/            @platform/platform-infra @security-team
/k8s/prod/                  @platform/platform-infra @sre-oncall
/ansible/prod/              @platform/platform-infra
/runbooks/                  @sre-oncall
/docs/incident/             @security-team @sre-oncall

The file is data. The pattern is symmetric: every layer that needs special handling (production paths, incident documentation, security-sensitive assets) lists its owners in the file. Branch protection then refuses to merge until each listed owner has approved.

How to verify the wiring

A CODEOWNERS file that has never been tested is a hypothesis. The verification is a pull request that should be blocked:

1. Open a PR that touches a CODEOWNERS-owned path.
2. The PR’s reviewer list should include the listed owners.
3. Approve from a non-owner account.
4. The merge button should be disabled with the message “Review from Code Owners required”.
5. Approve from an owner account; the merge button enables.

If step 4 does not block the merge, the wiring is broken and the file is documentation.

Production discipline

1. CODEOWNERS is the first governance file committed. Before the first Terraform module, before the first pipeline definition.
2. Branch protection requires review from Code Owners. “Two approvals” is not a substitute; the two approvals must include the listed owners.
3. Production paths have mandatory co-owners. A security team or SRE on-call co-owner on every production path is the cheapest segregation-of-duties control.
4. The wiring is verified by a test PR every quarter.

Cross-course references

• This course, Part XXXI (CODEOWNERS) covers the file format, the path patterns, and the forges that interpret it.
• This course, Part XXXII (BranchProtection) covers the gate that CODEOWNERS plugs into.
• This course, Part X (ConflictResolution) covers the case where owners are unavailable and a release is blocked.
• Terraform for Production Sysadmins Parts IX-XII cover ownership patterns for state-bearing modules.

Quiz