Mandatory Reviewers: Enforcing Human-in-the-Loop Reviews

Previously in this course, we explored Branch Protection Rules: Securing Your Main Branch on GitHub, where we learned how to prevent direct pushes to main and enforce that automated status checks pass before merging. While automated tests catch bugs, they don't catch logic errors, architectural flaws, or maintainability issues.

In this lesson, we add the "human-in-the-loop" requirement by configuring mandatory reviewers. By the end of this article, you will be able to enforce a workflow where code cannot reach production without at least one peer approval, ensuring your CI/CD process remains robust and collaborative.

The Case for Human-in-the-Loop Reviews

Automated pipelines are excellent at validating syntax, running unit tests, and checking for security vulnerabilities. However, they lack the context of your business requirements. A test can pass perfectly while implementing a feature that introduces a security back-door or violates your team's architectural standards.

By requiring pull request reviews, you create a social contract where developers are accountable to one another. This "human-in-the-loop" approach isn't just about catching bugs—it's about:

1. Knowledge Sharing: Team members learn how different parts of the system work.
2. Consistency: Ensuring new code follows the established patterns in the codebase.
3. Risk Mitigation: Providing a final "sanity check" before code deployment.

Configuring Mandatory Reviewers

To enforce this, we return to the GitHub Branch Protection settings. We are building upon our existing configuration that already guards the main branch.

Step-by-Step Configuration

1. Navigate to your repository: Go to your GitHub repository on the web.
2. Access Settings: Click the Settings tab.
3. Branch Protection: Select Branches from the left-hand sidebar, then click Edit next to your main branch protection rule.
4. Enable Review Requirements: Check the box that says "Require a pull request before merging".
5. Require Approvals: Within that section, check "Require approvals" and set the number to at least 1.

Once enabled, the "Merge pull request" button will remain grayed out until a collaborator approves the changes, even if all your Pull Request Integration: Protecting Main with CI status checks are green.

The Human-in-the-Loop Workflow

When you enable mandatory reviews, your Developer productivity: Master the art of pull request batching strategy becomes even more important. You aren't just shipping code; you are initiating a conversation.

The Lifecycle of a Protected Pull Request

1. Submission: The developer opens a PR. The CI pipeline triggers automatically.
2. Review: A peer reviews the code, leaves comments, or requests changes.
3. Iteration: The original author addresses feedback and pushes new commits.
4. Approval: The peer grants approval.
5. Merge: Only now does GitHub enable the merge button.

Hands-on Exercise: Enforce the Gate

1. Configure: Follow the steps above to require 1 approving review on your main branch.
2. Test: Create a new branch, make a small change to your README.md, and open a Pull Request.
3. Verify: Observe that even after the CI status checks pass, you cannot merge the PR.
4. Complete: Ask a collaborator (or use a secondary GitHub account) to approve the PR. Watch the merge button turn green.

Common Pitfalls

• Blocking Your Own Merges: If you are the sole contributor, you might find it annoying to wait for reviews. In professional settings, consider using "Allow specified actors to bypass" only if absolutely necessary, but try to maintain the discipline of having a human review every change.
• Stale Reviews: GitHub has a setting to "Dismiss stale pull request approvals when new commits are pushed." Enable this. It ensures that if a reviewer approved a version of the code, but you later added a massive, risky change, that approval is wiped, forcing a re-review.
• The "Rubber Stamp" Problem: When you make reviews mandatory, teams sometimes just click "Approve" without reading. Encourage a culture of meaningful feedback rather than just clearing the checkmark.

FAQ

Q: Can I require specific people to review the code? A: Yes, if you use GitHub Organizations, you can require reviews from specific teams (like a "Senior Engineers" team).

Q: What if a test fails after the review? A: The merge is still blocked. The human approval and the automated check are two independent "gates." Both must be open simultaneously to merge.

Q: Does this slow down delivery? A: It adds a small amount of time, but it significantly reduces the cost of "rework" caused by bugs reaching the main branch. In the long run, it actually speeds up your deployment velocity by reducing production incidents.

Recap

We have successfully integrated a mandatory human gate into our CI/CD pipeline. By combining the automated validation we built in earlier lessons with the manual oversight of peer reviews, we've created a "Double Gate" system:

• The Machine Gate: Ensures the code is technically sound and passes tests.
• The Human Gate: Ensures the code is useful, secure, and maintainable.

Up next: We will secure our supply chain by adding Dependency Scanning to our pipeline, ensuring the libraries we rely on don't contain known vulnerabilities.