In all projects that I have been involved with that have had input from an outside consultant the question has been asked about what sort of Configuration Management we were using. In none of these cases has the consultant been able to define Configuration Management. So what is it?

  • 4
    Honestly just Google it, first two results are relevant Wikipedia entries that explain all about it. – Jeremy Dec 1 '10 at 0:27
  • The link: en.wikipedia.org/wiki/Software_configuration_management. Good question though. – Jon Onstott Dec 1 '10 at 0:49
  • 2
    I've read that wikipedia page, and to be honest I think it was written by the same "consultants" that Henry is referring to... – Dean Harding Dec 1 '10 at 1:20
  • Ah yes, the buzzword. Brings back memories from my enterprise days. – Jason Baker Dec 1 '10 at 2:02
  • @Dean Harding Exactly! – Henry Dec 1 '10 at 19:47

What Software Configuration Management (SCM) is boils down to answering the following:

  • What source files where used to make our end product?
  • What has changed from the last time we made our end product?
  • Why did we change it?

This in turn can grow to a quite large and ugly "process". The process issues are why most developers eyes glaze over at the mention of SCM, as this means tracking source files, defects and requirements; then tying it all together so you can audit changes (This is an Ideal world from a management point of view as it gives a good manager tools to better see what resources he needs where.)

This is different from ITIL Configuration Management which is actually software asset tracking, what software is running where (which server/ workstation) and what is the setup for that software.

In other words your consultant more then likely wants to know is how YOUR company/development group answers the three questions at the top of my answer.

  • 1
    The most recent time this came up I said we use svn, Trac and Hudson. It was clear from the look on the consultants face that he hadn't heard of any of this. So I showed him how our requirements registry feeds into Trac, how Trac integrates with svn, how Hudson auto builds and deploys everything and the guy listed configuration management as a project risk. – Henry Dec 2 '10 at 8:15

Configuration Management encompasses "everything else" that's not directly related to writing code. So it's how you manage releases, how you manage and triage bug reports and feature suggestions, how you perform your builds and so on. It often also includes how your source code is managed (e.g. what version control you use, branching strategies, how you [possibly] manage multiple concurrent "releases" etc).


Configuration Management has meant a lot of things over time. I consider it more important to administrators or operations than directly to developers. When your an operations person trying to keep servers up and running you worry about setting up machines, managing their configuration, and keep it running. If you just log into a computer and start installing software, and changing config files on a machine you're not managing that configuration. What happens if that machine dies? What happens if someone goes on that machine and changing a config file and everything starts to freak out? What if you need to start up another machine configured exactly like the one that's running? Can you do it?

Without a configuration management strategy you can't. And that's why it's important. It's all about repeatability. Developers approach repeatability differently than operations people do so we care about repeating different things.

There are some great open source tools that help you do this: Chef, Capistrano, Cook, and even SVN. Why should SVN just be used by developers? Check in your config files, scripts you use to configure machines, and track their versions. Those parts of your organization are vital to keep it running. You don't want to loose those.

Your Answer

