Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

From monitoring to automated testing, Jesse Reynolds, Puppet


Published on

Don't have time to write automated tests for your infrastructure code? Don't see the point? Or don't know where to start? This talk is for you.

Now we're writing code to manage our infrastructure with tools like Puppet we are effectively developing software. One of the wonderful aspects to this is that we have the world of software development quality best practices to draw on in order to achieve a high rate of change while not compromising on reliability. Writing tests for infrastructure code, and having them execute automatically as part of a continuous integration pipeline, is a key element to this and is the focus for this talk.

But how do you get started on this? What are some tools to help? How should we think about this problem? This talk will provide an overview of the different types of tests that can be written, from small unit tests to integration and acceptance testing. It will focus on integration testing where existing monitoring checks can provide a useful starting point.

After this talk attendees will:

* better understand the value of automated tests for infrastructure code
* be motivated to write tests and implement CI pipelines to execute these tests automatically
* know how to get started with some suggested tooling

Published in: Technology
  • Be the first to comment

From monitoring to automated testing, Jesse Reynolds, Puppet

  1. 1. From Monitoring to Automated Testing of your Infrastructure Code Jesse Reynolds, Puppet Virtual Puppet Camp Australia, April 2020
  2. 2. @jessereynolds Principal Professional Services Engineer
  3. 3. Infracode?
  4. 4. Writing tests has been a best practice in software engineering for a while now... • syntax & lint • unit • integration • acceptance
  5. 5. Infrastructure code is software, so you should write tests for it too
  6. 6. “Reasons” to not write tests…
  7. 7. "It takes too long to write tests"
  8. 8. "Who is going to run them anyway?"
  9. 9. Why bother?
  10. 10. Let me tell you a story…
  11. 11. There was this bank.
  12. 12. Both classes get applied.
  13. 13. The IP addresses are not determined correctly.
  14. 14. All machines now have and that’s not how you TCP/IP* *unless you’re Cloudflare
  15. 15. What went wrong?
  16. 16. What could have been done to prevent this? • Code review? • Unit testing? • Integration testing? • Acceptance testing?
  17. 17. Testing to the rescue!
  18. 18. Unit or acceptance testing? “I’ve decided code unit tests aren’t worth the trouble and end state testing is easier for most people to grasp. Have just written my first resource extension for InSpec yesterday and am off and running.” - a sysadmin near you.
  19. 19. OK, what do we need?
  20. 20. Provision a machine.
  21. 21. Apply your code to the machine.
  22. 22. Execute the tests.
  23. 23. Examine the exit status. Zero good. Non-zero bad.
  24. 24. The test harness Time to make some choices
  25. 25. Beaker
  26. 26. Test Kitchen
  27. 27. kitchen-ansible
  28. 28. Serverspec
  29. 29. describe interface('eth0') do its(:ipv4_address) { should match /10.0.3./ } end
  30. 30. Could you re-use your monitoring checks for infacode CI testing?
  31. 31. Rspec
  32. 32. Rspec
  33. 33. You could dream of going on holiday.
  34. 34. Demo
  35. 35. Thank you for listening! @jessereynolds Questions? What’s your org doing?
  36. 36. Image acknowledgements - Base Jumping in Idaho - Nelson Lakes National Park