Being a product focused on GitOps as a practice for infrastructure automation, I thought it would be a good idea to explore the core postulates of GitOps: IaC, code reviews, and CI/CD. 

This article will go deeper into how to perform infrastructure code reviews regardless of whether you implement GitOps or not. It is necessary that you use IaC, though.  

Creating a culture where code changes go through a pull request is crucial for a successful infrastructure automation process. Only after the pull request is reviewed and validated, you merge it into the main branch that triggers the CI/CD pipeline. This means that the code on the main branch is always clean and ready for deployment. 

A proper code review process diminishes the chances of bad code getting released into production. It's also common to use automated tools for code reviews, like code linters, static code analysis, security tools, etc.

The benefits of code reviews for infrastructure 

Code reviews are essential for good code quality.

The most obvious benefit is discovering bugs and misconfigurations that can cost you a lot if found in production. Some additional benefits from infrastructure code reviews are:

• Code reviews give more insight to developers since at least two people understand how the code works and why a change was implemented.  
• Code reviews are an excellent way for developers to learn from their more experienced peers, which is even more true for infrastructure code. 
• Additionally, it's a great way for developers to show their experience in some areas that they haven't before. Finally, having different personalities and tech mindsets under one roof enables the company to find creative solutions to problems. 
• On the other hand, code reviews give more control over the infrastructure code to operations. For example, when developers make changes to infrastructure code and create a pull request, it enables senior DevOps engineers and security experts to review that code against standard best practices, defined criteria, and security measures.  
• As a result, code reviews are excellent means to emphasize company values across the whole team. They can spread the message of how code should be written, configured, and documented and what considerations need to be taken. Eventually, this will help set up the mind map of someone coding the infrastructure code. 

Questions to ask when performing an infrastructure code review

I find that having a lightweight question list to go through when performing code reviews helps stay focused and objective. So here are 5 simple questions I ask myself when reviewing infrastructure code changes:

1. Does the infrastructure follow the well-architected framework?
2. Does the code follow the least privilege access principle? Do we give the resource more permissions than's required?
3. To which extent can we configure the infrastructure? Is there room for better configurability so the infrastructure can be reused?
4. What are the scaling capabilities of the new resources involved? How will the system react if there is a failure? Have we ensured quick recovery in case of failure?
5. Is there something that's still not automated and requires manual setup in the cloud? We always tend to have 100% automation.

These questions help cover the essential aspects of the infrastructure lifecycle: architecture, security, configuration, scaling, and automation.

Enhance your workflow with automated code reviews

Manual code reviews can become ineffective if there are some common tasks that you need to go through each time. These are great candidates for automation. Automated code quality checks enable DevOps engineers to set up some guardrails to prevent malicious code from getting to the Git repository and beyond. 

These are some code review tasks you can consider automating: 

• Implement smell detection rules in linters to detect syntax errors and bad coding practices
• Run security unit tests on Terraform and CloudFormation
• Integrate automated checks in CI/CD to verify changes post-deployment
• Setup checks for your running cloud environments against compliance violations

It's a good idea to have a mixture of automated and manual code reviews. A few recommendations for linters be: cfn_nag - an open source linting tool for CloudFormation templates, and tfsec - security scanner for Terraform code. Another great tool is prowler which enables you to perform security best practices assessments, audits, incident response, continuous monitoring, hardening and forensics readiness. As a SaaS alternative, Snyk is also a great tool for infrastructure as code security.

Conclusion

Being able to test infrastructure and configuration as you do with application code is one of the most significant benefits of IaC.

IaC itself is considered as a common language between developers and operations, which gives infrastructure code reviews the means to open up discussions related to infrastructure code quality and security. 

Infrastructure code reviews require you to go through a different question set than application code reviews. Here you need to think about the architecture and whether it follows best practices, whether the infrastructure is automated as much as possible, and to which extend you can make it configurable. You also need to take into consideration the possible security misconfigurations and potential vulnerabilities. And of course, you need to review how the system will perform if there is a failure and whether there are recovery mechanisms in place. 

Try following these questions next time you have an IaC code review. And always remember that code reviews are an empathy practice. Don't just go around giving negative feedback - it doesn't help in any way. Instead, try to encourage critical thinking by asking the right questions out of the coder.