Infrastructure as Code (IaC) has rapidly become a key part of cloud native engineering. The hard gained experience from writing software can be applied to infrastructure, but fundamental differences means some fundamental approached need to be reconsidered. This talk will explore the implications for test driven development and build pipelines applied to IaC. Jon Barber is an Engineer with Equal Experts. He has been paid to write software for over 30 years, and has spent most of his time recently in the platform engineering space. He’s a keen advocate of XP values and practices, and sees himself more as an engineer than craftsman.

1. Software development practices &
Infrastructure as Code - how well do they
work together ?

2. Introduction
Infrastructure as Code has become key in the cloud native era.
It’s a rapidly evolving area with lots of noise. Knowing what’s
important isn’t obvious.
We can apply the techniques that have emerged from software
development.
But some differences require adaptation.
Trying to apply the techniques as is will be frustrating and could even
lead to abandoning them all together.

3. Key differences
with IaC
Time
Much longer to see the effect of a change
Needs more discipline around diagnostics
1 step removed
The code we write isn’t the final artefact. We have to apply it to
something to get value from it.
Fast feedback loops more important than ever

4. A note about tools
The approaches we’ll talk about don’t rely on any particular tooling.

5. Pipeline structure
Distinct Stages
Focus on high value feedback as soon as possible
Group tests by stage
E.g. in this stage we won’t be using any external systems such as a
kubernetes cluster
High value tests first
For each stage run the high value tests first

6. Test Driven Development
Delayed feedback
Slow tests make it hard for humans to keep focus & context
Tempting to do more changes (larger batch sizes) between test runs
One assertion per test
Arrange phase can take a long time, so multiple asserts per test may
be reasonable.
But remember : make the diagnostics clear

7. Growing Object-Oriented Software, Guided by Tests
Steve Freeman and Nat Pryce

8. Drift Detection
Our Infrastructure as Code must be applied to something
Apply some terraform, deploy a helm chart etc
The changes we make can be changed by something else
AWS console, command line tools, kubectl etc.
Fast detection is key to reducing Mean Time to Recovery (MTTR)
We can use some of out tests for this (synthetic transactions)
Consider adding alerts and monitoring to definition of done.

9. Summary
IaC feedback often orders of magnitude slower than traditional
software development
Implications sometimes non obvious, so evaluate your approaches
regularly and course correct when needed
Context is everything - do what works for you.
The DORA 4 key metrics (see resources slide) can help frame your
decisions.
Fast feedback loops are key

10. Resources
Concourse CI
Terratest
Growing Object Oriented Software, Guided by Tests
DORA State of DevOps research
Accelerate

11. THANK YOU