Test-Driven Change – TDD for your infrastructure

Test Driven Development (TDD) is a common practice for software development, in which you write your tests before writing your code. Then you run the tests and they will fail. Then you implement the feature and the test passes. Then you write another test. Then run and fail. Then implement the feature. Then tests passes again. You repeat this process many times. Good developers are already familiar with TDD and do it on their daily-work. But what about sysadmins? How do they test their work? Is it possible for a sysadmin do TDD?

Here’s a small tip of how a sysop could get real benefits doing TDC (Test Driven Changes) to their environments. Matthias Marschall described how to do TDD in Ops world in 3 simple steps:

  1. In your monitoring system (Nagios, Zabbix, etc), write a service that monitors the problem you are trying to solve, and make sure the service shows red on your dashboard.
  2. Implement the configuration change, and have the your CM – Configuration Manager (Puppet, Chef, CfEngine, etc) roll it out to your test system.
  3. Once the service shows green on your dashboard, have your CM roll out the change to production.

So, in infrastructure world, your Test Suite is all the rules you setup in your monitoring tool. Once all your tests are green, you can “refactor” your system. If you break something, some of your tests should fail so you will know what should be fixed.

Leave a Reply

Your email address will not be published. Required fields are marked *