So, it’s the big day. Your new software application is ready to move into production. It’s been tested and re-tested, bugs fixed, documentation created, users trained (sometimes!). You will install the software and never need to touch it again, right?
Well, anyone who has worked in software development unfortunately knows that is not necessarily reality. New software that has been rolled out to end users invariably means two things:
- Bugs you didn’t know about
- Changes (affectionately called “enhancements”)
But I’m writing about configuration management – so what is that about? Configuration management (CM) is actually kind of a big thing, not just for software but for hardware and other IT-related “stuff” like servers, desktop computers, routers, storage, and the like. It all boils down to:
- Figuring out what you have and recording it somewhere
- Controlling who can make changes
- Keeping a record of the changes you’ve made
When you’re doing this for hardware, it’s kind of like keeping inventory. You want to know what you have at your starting point (the baseline) and you want to keep your inventory current. In addition, you want to prevent just anyone from making changes, for a lot of reasons.
Software CM and Version Control
For software, the basics of CM are the same, but there are some added goodies. Software tends to change over time. In addition, your software is likely to be in a couple of different states at any given point in time. For example, there’s your production code, which is the code that everyone is actually using. To prevent against any unforeseen “disasters” like server outages, storage corruption, etc., you will want a backup copy of that production code. You can store this backup in a managed environment using a version control system. This is (more) software that provides a way to store your code in an organized way and keep track of different sets (or versions) of the code.
When you use a version control system for your developed software, you can:
- Establish a workflow for review, approval, and incorporation of changes (the control part)
- Trace all changes to your baseline system (usually created with the first production deployment) even when several developers are working on the code at the same time
- Control who has access to the code, and the types of changes they can make
- Use automatic identification features (usually a numbering system) that are provided to track the progression of changes to each area of your code. The formal name for this is configuration identification
That last bullet means that you can have several different versions of any part of your code and still be able to understand what you have. This helps when you are making a lot of enhancements that need to be tested separately before they are moved into production. It also means that if a new software bug is introduced, you have a way to trace back and find out which change in the code caused the bug. At that point, the code change can be rolled back to the working version while the bug is investigated and (hopefully) fixed.
To really do this right, there are also a couple of other things you will need to do:
- Audit your configuration once in a while; compare what you have in your software environments with what is stored and identified in your version control system
- Create a report of your audit findings
There’s one last thing to mention: Overall, software CM saves you money. This happens because having organized and versioned code goes a long way towards preventing mistakes, re-work, and duplicated effort between multiple developers. The documentation provided by a version control system provides an automated means of communication between members of a development team, meaning fewer misunderstandings about who is working on what. All of this adds up to better productivity and cost savings.
You can probably figure out that the best time to start software configuration management is at the beginning of development. If you haven’t done that, though, it’s not too late. There are some great open source systems out there, as well as many that will require an investment. Find a system, decide on a specific date/time, get your code organized, suspend any changes temporarily, and place all the code pieces into your version control system. With this baseline, some coordination, and a bit of effort, you can manage your code and be confident that changes are controlled and documented.