From Monitoring to Automated Testing of Your Infrastructure Code
summary
Argues that infrastructure code needs integration/acceptance tests that run in CI, shows how to spin VMs, apply Puppet/Chef/Ansible and assert state so regressions are caught before deployment. Reuses existing monitoring checks as a low‑friction on‑ramp. Demonstrates tools: Test Kitchen, beaker, and test frameworks like serverspec (and mentions bats), and recounts a failure where conflicting Puppet classes left hundreds of machines offline—tests would have caught the combination before it hit production.
AI-written summary · about
chapters (18)
- 0:00Start
- 1:53Writing tests has been a best practice in software engineering for a while now...
- 3:01Infrastructure code is software, so you should write tests for it too
- 6:33What went wrong?
- 7:24What can be done to prevent this happening again?
- 8:34Testing to the rescue!
- 9:08OK, what do we need?
- 9:55Provision a machine
- 10:32Apply your code to the machine
- 11:06Execute the tests
- 11:28Examine the exit status zero good non-zero bad
- 12:23The test harness
- 20:19It takes too long to write
- 21:15Who is going to run them anyway?
- 22:24New team member joins
- 22:39You can actually go holiday
- 23:45Could you re-use your monitoring checks for infacode Cl testing?
- 25:13What's your organisation doing?
related talks
32mWe Still Need to Talk About Infrastructure Testing
05mProgramming your Infrastructure
46mImplementing Infrastructure as Code
01h 21mTest Driving your Rails Infrastructure with Chef
06mIgnite: Programming your infrastructure
46mThink of your infrastructure as code
22mMoving Fast Together: Test-Driven Infrastructure
42mInfrastructure as Code - Lessons learned from Dev to Ops