Why no change should reach production on its author's word alone, how to require review on GitHub, and why the same record is change-management evidence.
On a small team, the quickest way to ship is to merge your own change. It’s also the easiest way for a mistake to reach production with nobody but its author ever having read it. At BHyve, no change reaches the main branch without approval from a code owner who isn’t its author.
This is why that rule matters, how to set it up so there’s no way around it, and why the same record turns out to be change-management evidence.
The problem: one person can ship a change alone
Without a rule, nothing stands between one laptop and production. Most days that’s fine. The trouble is the day it isn’t: a wrong value in a config file, a migration that changes more rows than it should, a secret pasted into code. Each one is easier to spot from outside than from inside.
It isn’t only about mistakes. If one person’s account or laptop is compromised, whoever holds it can ship whatever they like, as long as nobody else has to approve it.
Why the author is the wrong person to check
- You read what you meant to write. The author knows the intent, so their eyes slide over the gap between the intent and the code. A reviewer only has the code, so the gap is what they see.
- Knowledge spreads. Every review means at least two people know how that part of the system works. On a small team, that’s the difference between one person who can fix it and two.
- Nobody ships alone. With a second approval required, one compromised account or one bad afternoon becomes a change someone else has to agree to. Keeping the person who makes a change apart from the person who approves it is called separation of duties.
The principle: put review on the one path every release takes
A review rule only helps if there’s no way around it. So it belongs on the path every release has to take, not on the path most releases happen to take.
For us that path is simple. Staging deploys from the main branch, and a signed tag promotes the exact image staging ran to production. (Why we release that way is in release by tag.) So a rule on the main branch covers every production release, and there’s no second door to guard.
The rule also says “any code owner other than the author”, not one named reviewer. A single required reviewer becomes a queue, and a queue becomes a reason to make exceptions. With several possible approvers, there’s always someone else who can read the change.
How to set it up on GitHub
- Name the owners. A CODEOWNERS file in the repository lists who owns which files.
- Protect the main branch. Add a branch protection rule or ruleset that requires a pull request before merging, at least one approval, and review from code owners. GitHub doesn’t let a pull request’s author approve it, so the approval always comes from someone else.
- Make approvals cover the latest code. Turn on “Dismiss stale pull request approvals when new commits are pushed” or “Require approval of the most recent reviewable push”. Otherwise an approval given on Monday can cover code pushed on Tuesday that nobody read.
- Require the checks to pass. “Require status checks to pass before merging” means the reviewer reads the change and CI tests it, both before it merges.
- Don’t let anyone skip it quietly. “Do not allow bypassing the above settings” applies the rule to admins too. If you need an emergency path, write it down: who can use it, and how the change gets reviewed afterwards.
- Keep the owner list current. When people join or leave, update CODEOWNERS and repository access.
The same record is change-management evidence
Once review is required, the evidence writes itself. A merged pull request holds the diff, the author, the approver, the timestamps and the checks that ran. A release tag points at a commit, and the commit points back to its pull request. That’s a chain anyone can follow from production to the person who approved the change.
That chain is what change management asks for. SOC 2 is a report from an independent auditor on how a company protects customer data, and its change-management criterion, CC8.1, expects changes to be authorized, tested and approved before they go live. ISO 27001 is a standard for running information security, and its Annex A control 8.32 says changes to information systems should follow change management procedures. I wrote our rule up as change-management evidence for both.
Two things follow. The history you can show starts the day the rule did, so it pays to turn it on early. And a rule is evidence, not a certificate: an auditor decides whether your controls meet the criteria, and change management is one area among many.
What it changed
Every change to the main branch now has a reader other than its author. Review and speed aren’t at odds: we ship about 1.7 production releases a day, and each change still goes through a second pair of eyes.
The questions “who approved this, and was it tested?” now have a link for an answer instead of a search.
The lesson
Review every change because a second reader sees what the author can’t. The evidence is a by-product, not the reason.
For the rest of the pipeline behind the rule, see the CI/CD case study.
Quick answers
- Why should code review be required on every change?
- Authors read what they meant to write, so a second reader catches what they miss. Required review also spreads knowledge of the code and stops any one person or account shipping a change alone.
- Can you approve your own pull request on GitHub?
- No. GitHub doesn't let the author of a pull request approve it, so a required approval always comes from someone else.
- How do I require code review on GitHub?
- Add a CODEOWNERS file, then a branch protection rule or ruleset on the main branch that requires a pull request, at least one approval and review from code owners.
- Does code review count as SOC 2 change-management evidence?
- It can be part of it. SOC 2 expects changes to be authorized, tested and approved before they go live, and a required review with passing checks records all three. The auditor decides what's enough.
- What is ISO 27001 control 8.32?
- Annex A control 8.32 in ISO 27001:2022 covers change management: changes to information processing facilities and information systems should follow change management procedures.