So, along with DevOps, Continuous Delivery, Microservices Architecture and LEAN, one of the other terms/ideas that’s quite popular at the moment is the idea of “Infrastructure as Code”. Basically, the term alludes to the fact that when a hosting/cloud provider gives you a set of API’s to their services, you can programmatically define your “infrastructure”, including things like networking, firewalls, servers etc… (which were previously in hardware and therefore harder to automatically configure) and the connections and relationships between them.
However, the question then becomes, “If Infrastructure is now code, can all of the methodologies (TDD, BDD, defensive coding, XP etc…) developed for Software engineering be applied to Infrastructure code? And if so, what does it look like to write TDD infrastructure code?”.
Probably one of the easiest issues to tackle is the question of how do we test infrastructure code (easy because it’s more or less “monitoring” and we’ve been doing that for ages). In researching options for testing, there seem to be three which stand out as contenders with a focus on testing infrastructure:
- Serverspec (ruby tool, uses Rspec like test definitions)
- Goss (like Serverspec, but written in Go, calls itself a “server validation” framework)
- BATS (seems to be more focused on testing Bash scripts)
In addition to stand-alone testing tools, the big three configuration management tools (Ansible, Puppet, Chef) all have sections on how to integrate testing into your lifecycle (e.g. https://docs.ansible.com/ansible/test_strategies.html)
My own personal view is that the tools used should be separate enough, so that you’re able to run the infrastructure tests/server validation on it’s own. With the ultimate aim being to be able to integrate them into your monitoring infrastructure (e.g. something like cucumber-nagios).
Therefore, when writing an application, you should be writing the “smoke tests” in parallel, which serve as a codified version of your app’s dependencies and also as the template to answer the question “what do we need to monitor to ensure that the application stays up?”.