Emma Button, COO @ nubeGO, shares thoughts from her talk on IaC at DevOpsCon Berlin 2019.
Earlier this month I spoke at DevOpsCon in Berlin on the topic of Infrastructure as Code (IaC) and the lessons we can learn from agile software development techniques.
My talk at DevOpsCon centred around four agile themes:-
Simplicity – the art of maximising work not done
Quality
Technical Excellence
Purpose and a Shared sense of Ownership
The slides are available on SlideShare and you’ll see that I spent quite some time talking about quality practices such as unit testing, static code analysis and behaviour-driven testing using the Given-When-Then notation.
I’ve shared my thoughts on IaC linting and Terraform Unit Testing over on my personal blog so today I thought I’d highlight some of the fantastic questions I was asked after my talk at the conference in Berlin.
Should I group my infrastructure code alongside the application code in the same repository?
I think my default answer is No. During my talk I spoke about how the logical separation of your infrastructure code doesn’t necessarily follow the same separation as your application code. So unless your infrastructure code templates exactly map to services then you probably want to keep the IaC separate from application code.
If I have tests for shared platform components such as networking and security, should I run them for every application that uses that shared platform?
Ideally, yes. If you are concerned that re-running platform tests for every application that uses the platform will delay the CI timeline then perform risk based selection of a few platform tests to run each time – this helps to ensure that the platform is in a known good state for an application to run.
Aren’t infrastructure tests so much slower than application code tests? How do you keep on top of this and make sure they execute quickly?
The nature of infrastructure automation tests does tend to mean that their execution time is longer than application unit tests. This is because the tests have to get the infrastructure resources into their desired state before the tests can run, and many of the checks and controls take longer than code-level checks.
When you select which tests to run against your system, concentrate on the ones that offer the most value and protect against the most common or most impactful issues. Regularly evaluate your list of tests to ensure that they are adding value, and if they’re not then remove them. Expect the value of your automation tests to change over the lifetime of a project.
Would you encourage an entire enterprise organisation to select a single tool or technology for continuous integration and testing?
Err… No. Next question? Seriously, I don’t encourage the enforcement of any mandatory tool or technology at full enterprise level unless there are very strong financial reasons to do so. Opt instead for overarching policy and guidance and allow teams to experiment to find the right tools for them to achieve their goals.
Specialist nubeGO Cloud Consultants and DevOps Engineers can help you to define and shape your Infrastructure as Code strategy and implementation, please contact us to find out more about our Cloud consulting, engineering and training offerings.