Grant Fritchey

16 March 2021

Code Review and DevOps

Almost every time I teach a class on DevOps, one of the questions that comes up is:

How do we do code reviews in this automated process?

There are actually a number of answers to this question. Let’s walk through a few.

Source Control

If you’re automating your deployments, I don’t think I’m going out on a limb to say you almost certainly have your code in source control. So, if you want to review the code, source control is a great place to start. In fact, it’s probably the best place to start. You can easily run a report on a given database to find all the changes made since the last time you did a review. Whether you want to review the code weekly, daily or hourly, you can find all changes easily thanks to source control. Best of all, you can look at the changes as they occur. You don’t have to wait until the deployment is accomplished.

Further, if you capture the change scripts used to deploy to production (a very good practice to get into), you can always review those scripts in order to understand what changed. Yes, this is an after the fact review, but it’s still a great way to keep an eye on what’s going on with the servers.

Continuous Integration

In all likelihood, if you’re automating deployments, you have an initial testing mechanism, probably some form of Continuous Integration. Well, this is the first place code gets deployed to from source control. It’s probably an excellent place to see what changes are being made. Further, your CI process probably includes error reporting. Here’s your opportunity to start catching bad code early in the process. Here again, maybe capture the change scripts used to deploy to the CI environment. I wouldn’t advocate for this one a lot, but it is another possible way to get your hands on the code before we get to production.

A Review Step

It’s simple enough in most DevOps tools to add a review step. Just make approval a part of the process. You can easily have any artifact generated for a deployment available in this review step. You can look through the code before it gets to production and still have a fully automated production deployment. If there are other approvals needed within the organization, they can also be incorporated through the same method.

Don’t

I know people who insist that they review every line of code before it gets deployed. Then, you see them open a 10,000 line script, glance at the first few lines of code, validate that it compiles, and they’re done. Frequently, the code review step is there because there is no other testing, no other validation of the code, prior to deploying it to production. If we’ve set up a full CI process, a test environment, and a pre-production or staging environment, they all test the deployments right? If you have further automated testing created, it’s also validating your deployment. Instead of trying to rely on the Mark I eyeball, just rely on the process to do your code review for you.

Conclusion

Now, the full answer is, of course, all of the above. You should be using all these tools and methods to ensure that you can appropriately understand the changes going on with your system. While we want to speed our releases as much as possible, we still want those releases to be reliably safe. Having these processes to ensure a safe deployment, and methods of knowledge about what is being deployed, adds protection to our production environments.