25-2 · Chapter 25 · 5 min read

Infrastructure Changes Need Code Review, Just Like Application Code

You have a server running in production. Someone on your team needs to open a new port for a monitoring tool. They log into the cloud console, find the

Infrastructure Changes Need Code Review, Just Like Application Code

You have a server running in production. Someone on your team needs to open a new port for a monitoring tool. They log into the cloud console, find the security group, add the rule, and save. No one else knows this happened. Three days later, the security team runs an audit and finds an open port that should not be there. No one remembers who opened it or why.

This scenario plays out in teams that treat infrastructure changes differently from application code changes. The same team that requires pull requests, peer reviews, and approvals for a one-line bug fix in their app will let someone SSH into a server and change configuration files directly. The inconsistency creates risk, confusion, and unnecessary firefighting.

Why Infrastructure Changes Deserve the Same Rigor

When you write infrastructure as code, you store your server configurations, network rules, database settings, and deployment definitions in Git. These files describe exactly how your infrastructure should look. A change to these files can have consequences just as serious as a change to your application code.

Consider what happens when someone modifies a firewall rule. A single misconfigured port can expose customer data to the internet. A wrong database instance size can cause performance degradation or unexpected cost spikes. An incorrect load balancer setting can take your entire application offline. These are not hypothetical risks. They happen regularly in teams that skip review processes for infrastructure changes.

The problem is not that people make mistakes. Everyone makes mistakes. The problem is that when infrastructure changes happen without review, the mistakes go unnoticed until something breaks. And when something breaks, there is no record of what changed, who changed it, or why.

How Pull Requests Work for Infrastructure

If your infrastructure is defined as code in Git, the review process works exactly like it does for application code. Someone creates a branch, makes their changes to the infrastructure files, and opens a pull request. Other team members review the changes, leave comments, request improvements, or approve the change. Once approved, the change gets merged into the main branch, and the pipeline applies it.

This process is not new or complicated. It is the same workflow that development teams have used for years. The only difference is what is being reviewed. Instead of reviewing application logic, you are reviewing configuration definitions.

What to Check During Infrastructure Review

When you review an infrastructure pull request, you are looking for several things.

First, does the change make sense for the requirement? If someone is opening a port, do they actually need that port? Is there a more secure alternative? Does the change align with what the team agreed on?

Second, is the configuration correct? Check the syntax. Verify that the port numbers, instance sizes, and network CIDR blocks are accurate. Look for security rules that are too permissive. A rule that allows traffic from 0.0.0.0/0 to port 22 is almost always a red flag.

Third, is the change consistent with other environments? If your staging environment uses a specific instance type or a particular database size, the production environment should not suddenly use something completely different without a documented reason. Inconsistencies between environments are a common source of deployment issues.

Fourth, does the change follow your team's naming conventions and tagging standards? Consistent naming makes it easier to understand what resources are for and who owns them. Tags help with cost allocation and resource management.

The Historical Record

Every approved and merged pull request becomes a permanent record of what changed, who changed it, and when. This historical trail is invaluable when things go wrong.

Imagine waking up to find that your production application is unreachable. You check the recent changes to your infrastructure repository and see a pull request that modified the load balancer configuration two hours ago. You can immediately see what changed, discuss it with the person who made the change, and decide whether to roll back or fix forward.

Without this record, you would be guessing. You would ask around the team, check chat logs, and look through cloud console activity logs. The process takes longer and is less reliable. The pull request history gives you a direct answer.

Addressing the Speed Concern

Some teams resist infrastructure reviews because they think it slows things down. They argue that infrastructure changes need to happen quickly, especially during incidents or urgent updates.

The reality is that the time spent on review is almost always less than the time spent recovering from an unreviewed change that broke production. A five-minute review can prevent a two-hour outage. The math is straightforward.

For urgent changes during incidents, you can adapt the process. Some teams use a post-incident review model where the change is applied first to restore service, and the pull request is created and reviewed afterward. The key is that the review still happens, and the change is still documented. The process bends for emergencies but does not disappear.

What Comes After Review

Once the infrastructure change passes review and gets merged, the work is not done. The pipeline needs to show what will actually change before applying it. This is the plan step. The pipeline compares the desired state defined in your code with the current state of your infrastructure and shows the differences. Only after reviewing the plan and confirming it looks correct does the pipeline proceed to apply the changes.

This plan step is critical. Even with thorough code review, the plan can reveal unexpected effects. A change that looks correct in the code might produce a plan that deletes and recreates resources, which could cause downtime. The plan gives you one last chance to catch problems before they reach production.

Practical Checklist for Infrastructure Pull Requests

Does the change match the actual requirement or request?
Are all values correct (ports, instance sizes, CIDR ranges)?
Are security rules as restrictive as possible while still allowing necessary traffic?
Is the change consistent with other environments?
Does it follow naming and tagging conventions?
Is there a plan output showing what will change before apply?

The Takeaway

Infrastructure changes deserve the same review process as application code changes. The consequences of a bad infrastructure change are often more severe and harder to diagnose than a bad code change. Pull requests provide a structured way to catch mistakes, enforce standards, and maintain a historical record. The time you invest in reviewing infrastructure changes is time you will not spend debugging production outages caused by unreviewed configuration changes. Treat your infrastructure code with the same care you treat your application code, and your production environment will thank you.