Automated Configuration Testing, the Agile

Infrastructure EnablerOK, so I probably just closed out 100 games of Bulls**t Bingo in the title of this blog post

but I’ll stand by it. You want actual agility in what you do? You need a safety net. That

safety net is automated testing.

I’ll be honest, most of my experience in this regard comes from my background as a

developer. When I started out, a fresh faced graduate at a funds manager in Sydney, I

didn’t know much about testing at all. Sure, I tested my code, but they were half arsed

tests. I hadn’t even heard the phrase “Unit Testing”. I got by though. I wasn’t an amazing

technologist but I wrote pretty good code and quality wasn’t something I worried about

day to day.

Without being able to put it into words at the time though I did come to learn that quality

by no means enabled agility. Quite the opposite in fact. Lines and lines of code that

worked well became sacred sites. Don’t touch it! It works! In some cases it was better to

be stuck with crappy code that needed fixing. At least you were given license to have at

it.

It was only much later when I got into Rails and started using Behaviour Driven

Developmentwith cucumber and rspec that I realised what I’d been missing. When every

feature you’ve coded is backed by tests you don’t just get quality, you get freedom, you

can be agile. You’re not afraid of refactoring you know is necessary. You can move

quickly, iterate fearlessly. That thing you always felt held you back, testing, is now super

charging your work.

The same applies in the configuration space, and there are even more factors in play.

Configuration is a shared responsibility, with vested interests in development,

operations, security and beyond. The chance of a change here breaking a configuration

there is greatly increased. Worse still, whilst issues with code are more often than not

clear to all through their functional impact, a lot of issues with configuration are hard, or

even impossible, to detect. Take security or compliance considerations. How often are

they cast aside in the interests of simply getting something to work?

On top of that configuration is far more likely to be altered directly in production by

sysadmins, especially during a serious incident where a company is bleeding money.

Without automated testing how sure could you be that those quick fixes haven’t affected

something else? If you want that ability to be agile, to be able to react quickly with

confidence then you need testing.

We automate our config though, you say. We have Puppet! We use Chef! That’s great,

but what are those manifests and recipes? They’re code. And from one dev to another,

you gots to test your code.

If you’re interested in finding out more about how ScriptRock can help you become more

agile with your infrastructure and configuration hit the Get Started button at the bottom

of the page.