Version Control vs. Configuration Management

Overview

Let's start with some definitions to provide a baseline for the discussion. Here is a general definition for configuration management:

• Configuration management is a system, set of processes or tools that document all of the components comprising a larger entity. Configuration management enables those entities to be built and replicated reliably, using a list of the associated components and an understanding of any dependencies. As a discipline, configuration management has been used successfully in a wide variety of applications from software development to complex manufacturing environments.

Whereas version control is related to configuration management, it focuses specifically on change and time. Here is a general definition:

• Version control is a process that documents a baseline for a component or module and also stores all revisions or changes to that component in a database for later use. Version control capabilities typically yield the ability to reproduce the precise state of a component at any point in time.

So one could make the case that configuration management provides an overall process for how pieces of a complex system fit together. Version control provides both the ability to show how all of the pieces in that complex system have changed over time as well as the ability to restore to a state at a specific moment. As such, version control is an important part of a configuration management application.

Configuration Management for the Application Infrastructure

Most recently, configuration management and version control are being applied to managing the set of elements that comprise the application layer in enterprise IT. And the application of these disciplines is occurring for all of the right reasons. Consider the application layer in an enterprise IT data center. It usually is composed of application servers, Web servers, databases and middleware most often sourced from different software vendors. While that ‘best of breed' approach opens the door for flexibility, it also ushers in a great deal of complexity in how those various software elements are configured, updated or changed and deployed throughout the application lifecycle. Each software element in the stack has many different configuration files, each with literally hundreds of parameters to set, tune and control. There are many different elements comprising the application layer and many, many instances of these applications-multiples in production and others for development, quality assurance, support, disaster recovery, just to name a few. If you calculate the number of individual settings or configuration parameters across all elements in the application layer and all phases of the lifecycle, you will be looking at numbers in the tens of thousands. This could be reasonably managed with manual methods if the environments were configured once and then left alone-a "set it and forget it mode." However, our experience and survey research show that change occurs rapidly in these environments, with some companies using more than 15 people to make over 400 configuration changes monthly. Manual methods no longer apply.

Key Requirements for Application Configuration Management

Managing change in that environment is the kind of problem that is well suited to automation. Applying automated configuration management and version control to the IT application infrastructure environment must include:

• Discovery. Gather individual configuration parameters or settings across all of the infrastructure software elements and organize them in a database for follow-on use.
• Change Modeling. Once these settings are stored in the database, a configuration management tool could then be used to model the interactions among the various configuration parameters. Very often, business owners and IT people experience the frustrating situation where a change is introduced in one area and that change causes an unforeseen disruption in another area. The subtle interdependencies among the configuration settings usually cannot be detected by someone inspecting the environment and can only be brought to the surface through an automation solution.
• Change Policy Control and Standardization. These standards are used to create templates for individual elements of the application layer (for example, the standard configuration of a given application server) or for the entire application stack (a standard build for application server, Web server, data base and middleware).
• Audit and Reporting. The discipline of configuration management should also enable automated change reporting. As changes are made in configuration settings, these reports can be logged with results tabulated and presented for IT audit purposes.

In short, IT managers should take the following steps when considering the automation of configuration management and version control:

• Assemble all of the component level information into a centralized repository;
• Provide a view into the dependencies among the various configuration items;
• Impose policy control over how changes are proposed, tested and implemented;
• Deliver detailed tracking and reporting; and
• Allow changes to be reversed when proposed changes have unexpected consequences.

Key Version Control Features and use cases

The role of version control in this setting would be to provide a critical "safety net" for the change process included in the configuration management environment outlined above. While configuration management would explicitly regulate the change process, the entire process would be enriched with versioning features. Generally, this would imply that all changes are recorded in such a way that earlier versions of the configuration settings could be "reconstructed" and installed. This would have obvious value for situations where changes are made, deployed and then later found to have undesirable impact on performance or stability. But such features would also yield value for both IT compliance audits and disaster recovery situations. As auditors probe the integrity of systems related to revenue transactions, they may need to test the actual system environment that was in place around various sets of transactions. A robust version control capability embedded into the configuration management would conceivably allow the IT team to reinstate an exact copy of the application infrastructure at any desired time. Additionally, this capability would have clear benefits for reinstating infrastructure in a disaster recovery setting. Some critical aspects of the version control capability would include:

• "Automatic" vs. "Explicit" Versioning. A snapshot can be taken in fundamentally two different ways: 1) automatically, every time a change is made; or, 2) explicitly after a certain set of changes have been instituted and a change set has been created. Both approaches are valid, though the automatic approach has obvious benefits in that it records every change without requiring intervention.
• Level of Versioning. Versions can also be created for the individual settings or parameters or for configuration files. Once again, the former approach is superior because it records all changes at a very fine-grained level. With this approach, you can build up to a file-based version, but if you only record changes at the file level, you will not be able to drill down easily to find individual changes.
• Roll-back Capability. In order to be truly useful, the configuration management solution must have the ability to isolate a version (either by level or by date and time) and then reintroduce those settings into the application infrastructure. This is alternately referred to as "roll-back" or back-out in ITIL® language.

Summary

Configuration management solutions can play a critical role in managing change for enterprise IT organizations focused on the application infrastructure level, now that these solutions have been successfully implemented at the network and server layers. With sufficient features to address the essential requirements for discovery, change modeling, change policies and IT audits, a version control capability will expand the value of the configuration management solution through its ability to rebuild the business-critical infrastructure for performance, stability, disaster recovery and compliance reasons.

Jim Hickey Vice President, Marketing mValent.  Jim Hickey joins mValent with over 20 years of software marketing and sales experience with emerging and growing companies. Immediately prior to joining mValent, Hickey spent six years with Authentica, providing executive leadership in marketing, business development and sales. Jim has also had executive marketing and sales positions at Omtool and Xyvision and is a former strategy consultant with global consulting giant, Booz-Allen & Hamilton. Jim has an MBA degree from the Stanford University Graduate School of Business and a BA degree in Economics from Harvard College.