Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
Software development practices &
Infrastructure as Code - how well do they
work together ?
Introduction
Infrastructure as Code has become key in the cloud native era.
It’s a rapidly evolving area with lots of nois...
Key differences
with IaC
Time
Much longer to see the effect of a change
Needs more discipline around diagnostics
1 step re...
A note about tools
The approaches we’ll talk about don’t rely on any particular tooling.
Pipeline structure
Distinct Stages
Focus on high value feedback as soon as possible
Group tests by stage
E.g. in this stag...
Test Driven Development
Delayed feedback
Slow tests make it hard for humans to keep focus & context
Tempting to do more ch...
Growing Object-Oriented Software, Guided by Tests
Steve Freeman and Nat Pryce
Drift Detection
Our Infrastructure as Code must be applied to something
Apply some terraform, deploy a helm chart etc
The ...
Summary
IaC feedback often orders of magnitude slower than traditional
software development
Implications sometimes non obv...
Resources
Concourse CI
Terratest
Growing Object Oriented Software, Guided by Tests
DORA State of DevOps research
Accelerate
THANK YOU
Nächste SlideShare
Wird geladen in …5
×

Software development practices & Infrastructure as Code - how well do they work together ? Jon Barber

23 Aufrufe

Veröffentlicht am

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.

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Software development practices & Infrastructure as Code - how well do they work together ? Jon Barber

  1. 1. Software development practices & Infrastructure as Code - how well do they work together ?
  2. 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. 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. 4. A note about tools The approaches we’ll talk about don’t rely on any particular tooling.
  5. 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. 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. 7. Growing Object-Oriented Software, Guided by Tests Steve Freeman and Nat Pryce
  8. 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. 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. 10. Resources Concourse CI Terratest Growing Object Oriented Software, Guided by Tests DORA State of DevOps research Accelerate
  11. 11. THANK YOU

×