Configuration Automation - A Maturity Model


Published on

Are you diving into automation without a safety net? Be careful automating what you can't test

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Configuration Automation - A Maturity Model

  1. 1. Configuration Automation – aMaturity ModelIt’s been really interesting to watch the dramatic uptick in activity around the automationspace the last year or two. I don’t need to go into too much detail on the benefits thatautomation offers here, consistency and scalability are two of the more prominent thatcome to mind. What has struck me though is that it feels like the way that companies aregoing about it is missing a key step.In the Enterprise we are used to hearing about maturity models. The Capability MaturityModel (CMM) for processes (originally software processes) being one of the mostcommon. One of the key things you learn with maturity models though is that whenprogressing along them it is critical that you don’t skip levels. That is the point of it beinga “maturity” model. You grow through each stage, building on what you already have.You can move quickly through a stage but if you try to skip one you are destined forfailure.When looking at an IT automation implementation at a high level you can argue that it issimply a case of moving from manual deployment of systems to automateddeployments. For a fuller picture though I believe that you need to take validation, ortesting, into account. If I were to illustrate the maturity model, or roadmap if you will, forIT automation I would do it like this:
  2. 2. So why automate testing before automating your deployment? Think about it this way.What do you need to do before you start automating your systems? You need to gatheryour requirements for automation. Now you can gather them the classic way in adocument of some sort but how much utility do you get from collecting them this way?Take a leaf from the book of software developers and test driven development andgather your requirements as tests instead. Why? There are multiple benefits:1. If your requirements are executable you have test driven automation and you cantrack your progress with your automation implementation. How are we doing? Well howmany tests are passing?2. Your tests live on and become the safety net for your automations ongoing.Remember, automations are code too and they will have bugs. If you support them withseparate tests then you can guarantee their quality.3. You reduce vendor lock in for your automations. It is a much less risky task to switchfrom Puppet to Chef, for example, if you have an independent set of configuration teststo validate your migration.So, not only is automated configuration testing a natural step on the road to fullautomation, it has multiple additional benefits.How you automate your configuration testing is up to you. If you are comfortable with aparticular scripting solution or testing framework then that is fine although portability andcollaboration can suffer. Remember, configuration is something that multiple teams have
  3. 3. a stake in, from development, operations, security and even testers themselves. If youare serious about bulletproofing your automations through testing you may want toconsider a more fit for purpose configuration testing solution… oh yeah,ScriptRockHowever you implement though the mere exercise of doing so prepares you forautomation. Whilst tempting to ignore it is always time well spent.