Automated Configuration Testing, the Agile Infrastructure Enabler
Updated on April 10, 2017
by Alan Sharp-Paul
OK, 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 Development with 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 UpGuard can help you become more agile with your infrastructure and configuration create a free UpGuard account.
Misconfigurations are an internal problem that emanate from within the IT infrastructure of any enterprise; no hacker is necessary for massive damage to occur to digital systems and stored data. And the problem is pervasive, with Gartner estimating anywhere from 70% to 99% of data breaches result not from external, concerted attacks, but from internal misconfiguration of the affected IT systems.