Getting Started with TDI

Behavior and test driven infrastructure (TDI) allows system administrator (operations) the same benefit developers have gained with TDD (Test Driven Development) and BDD (Behavior Driven Development), minimizing risk, building confidence, and maintaining focus.

But before TDI can be a reality, the first step is to start by looking at infrastructure as code. When we look at infrastructure as code we can leverage configuration management (CM) tools. This provides us with many benefits: repeatability, scalability, automation, agility, and reassurance. It resolves many of the anti-patterns commonly seen in system administration: manual provisioning of systems, manual documentation that is incomplete or outdated, and a myriad of custom scripts in an attempt to overcome other anti-patterns.

But configuration management does not prevent bad infrastructure code that is poorly created and maintained. Poor code will ultimately lead to a lack of confidence in the code and only few people will understand it. Then implementing changes will be unnerving, as there will be an unknown risk of a catastrophic side effect.

Test and behavior driven development provides a framework to cope with an ever changing environment. It provides protections and warning against unintended side effects by continuously testing for the desired behavior. And it encourages readable, maintainable code with continuous reiterations to small behavior specific code. Treating infrastructure as code now allows these same benefits to be applied to the infrastructure with TDI.

There are some consideration to take into account before implanting TDI. TDI requires a culture shift in how the infrastructure perceived and the methodology in how it is handled. Documentation of the environment's requirements is needed; this will further the burden of implementation, if it does not already exist. And of course there is the administration of the TDI infrastructure itself.

TDI helps ensure the ability to administer the infrastructure in the future. TDI encourages small specific changes that are continuously being tested against their desired behavior. This methodology reduces risk by keeping changes in scope, revealing design flaws, and producing maintainable code. Ultimately this creates trust: trust to implement change safely, trust that what is being delivered meets the client's need, and trust to continue the process. Additionally, the need for manual documentation lessens as code itself becomes the core of the information. All this allows for better planning.

Treating infrastructure as code allows us to leverage test driven development to achieve continuous integration (CI) of our infrastructure configuration. I will cover CM and go over a CI workflow in TDI, including the methodology, components, and stages.

Topics will include:

• Anit-patterns of Operations (System Administration)
• Configuration Management (CM)
• Benefits
• Shortcomings
• The Promise of Test Driven Infrastructure (TDI)
• Principles of Test Driven Development (TDD)
• Principles of Behavior Driven Development (BDD)
• Continuous Integration (CI) Workflow
• Tools
• Source Control Management (SCM)
• Configuration Management (CM)
• Continuous Integration Server (CI)
• Walkthrough of the process
• w/ Git, Jenkins, and Chef
• The Challenges of Change
• My Experience with Making the Shift
• Continuous Deployment (CD)