Applying sound coding practices when testing infrastructure
Just as a big benefit of TDD, is that your component design improves; writing tests while designing and building systems - rather than afterwards - forces you to improve your designs. A component that is difficult to test in isolation, is a symptom of design issues.
These are my reflections, lessons learned and brief summary of chapter 9 of Infrastructure as Code and is part of the Infrastructure as Code series.
Design your components to be small and focused, e.g. installing an application runtime (.NET, JRE, ...) onto a server and then ensuring that it (dotnet, java) is available on the path.
When it comes to testing, consider taking steps to syntax check and lint your infrastructure code, before you ask your cloud provider to provision resources for you. This will save you time and, money and headaches:
- Syntax checking: Execute a dry run (terraform validate, aws cloudformation validate-template, using arm-tt) on your infrastructure code to quickly get feedback when you've made a typo in your code.
- Linting: Ensure you're folling established organizational practices and identifying potential security vulnerabilities by utilizing a tool such as tflint, CloudFormation Linter, cfn_nag, tfsec and checkov.
When you finally want to provision your infrastructure, you'll want your infrastructure isolated from other unrelated infrastructure. Therefore, aim for an ephemeral environment that is provisioned from scratch and then removed after testing is completed. Once that is built, look for way to optimize it by having parts of it built outside of the build cycle (e.g. the teardown - you don't need to wait for that to validate your test; have a separate process deal with it). If you have properly componentized your infrastructure, you should soon be able to stand on your own shoulders by having pieces of infrastructure depend on other pieces of successfully provisioned and deployed pieces, thereby speeding your testing up even further.
Implement your test orchestration in a separate script or tool from your CI pipeline and have your CI pipeline pass in a minimum of configuration parameters to keep your orchestration loosely coupled.
Comments