One of my client’s CHEF developers recently contacted me about an issue that he saw in his unit testing.  The week before, I had given my version of a CHEF boot camp for infrastructure teams and had stressed the need for testing code.  This developer decided to retrofit some of his current cookbooks to focus on testing and validation.  As part of the boot camp, I provided a fully branded generator cookbook to help standardize on some of the toolkits.  I always include a Rakefile to streamline things like lint, syntax, and unit testing.

The developer said that he ran the rake tests and rubocop threw a syntax error and he wanted to check it with me.  We solved the issue quickly and it was a simple omission of a ‘do’ call.  I decided to go ahead and start to check the code since I was in the WebEx already.  Then I saw the issue and it reminded me why peer reviewing code is always a good idea.  You see, his code was fine and the testing was solid but in having an extra set of eyes review the code, I saw a big problem.

I will set the stage.  The recipe is a remediation for a compliance audit scan.  This homegrown remediation replaced a configuration file for the system.  The chosen file corresponds to the OS version and only if it was RedHat 5.x or 6.x.  Simple enough though I saw a few things that could be improved in the handling.  The recipe would copy the correct version to a temporary file and then replace the file completely.  I stopped dead in my tracks when I realized that the first step was to delete the file from the node but only replace it if the correct version could be found in the cookbook_file.  We discussed the best ways to handle this and even test the behavior.  We added a platform and version check into the process to in place update the file instead of jumping to multiple steps.  We even added an error handler if the platform and version was incorrect.

In the DevOps world, we do not typically rely on entire Quality Assurance departments or lengthy qualification processes.  In fact, we typically push the code into production as soon as possible.  The downside is that we could push valid and tested code but introduce a bug that could cause irreparable harm to our environment.  Here are a couple of things to think about in preparation for your next peer review

• Comment your code: If you decided to add a step, then document why.
• Call out unusual actions:  Justify why your method, function, or script needs to do it a certain way.
• Use your TODO comments:  In Building a Solid Foundation articles, I discussed how I use TODO blocks in my code as placeholders for potential code improvements.  I also use them as place to remind me why I should replace what the code does now.

Peer reviews are more than just validating your code.  It is also a great time to share experience, training, and even learn new tricks.

Interested in more?  Take a look at our Building a Solid Foundation series to learn more tips and tricks