Published on CMCrossroads (https://www.cmcrossroads.com)

Home > Difference Between Configuration Control and Version Control
LaShawn Dorsey's picture

Difference Between Configuration Control and Version Control

Can someone please explain the difference between configuration control and version control?

Angie Dockery's picture

Sorry for the late response but I just had this discusion with a new manager of Software Configuration Management.  I explained it this way (a very simple viewpoint):

Version Control is basic check in and check out of files that may or maynot track the reason or require approval of changes to the files.

Change Contol is tracking,incoprating and verifing only approved changes of files into a baseline.

I know it is a very simple view but it helped her understand the importance in why Change Mangement is important not only in an operation enviroment but in the development process as well.  My view is the most important task a CM has is to protect the baseline and know excatly what is in it.

Pradeep Prabhu's picture

In addition to what Bob mentioned, configuration control applies to service assets as a whole, of which, systems configuration is a subset. In places where configuration baselines are adopted, configurations of the service assets must be within the limits that are recommended in the baselines - so, in a way, configuration control also means that the configurations of the Configuration Items (CI) don't cross above/below the limits defined in the baselines. That way, we ensure that all the assets follow uniform configurations. If and when there is a need to cross these limits, the concerned team must get the approval of Change Advisory Board (CAB) in order to make those changes.  

To be more clear, service assets may include source/version control systems, scripts, infrastructure assets, documents, RFC tickets, SLA documents etc., to name a few. A simple version control baseline might recommend that the tool must have certain standardized branch structure or build configurations etc., so its standardized across all the environments.

Hope this helps!

~ Pradeep

 

Bob Aiello's picture
Bob Aiello replied on August 14, 2013 - 11:37pm.

Hi LaShawn,

this is a great question and I actually reviewed this terminology in my book on CM Best Practices. Years ago there was really very little difference between configuration control and version control. This goes back to when we selected the versions of Cobol programs, copybooks etc for a release. Back then we referred to a baseline of the code as a configuration and, in some sense, it actually was. The technology has changed and the terminology has also evolved.

Configuration control now really refers to setting runtime dependencies and we often discuss "configuring" an application to run. An example would be a JMX control or even more basic - specifying whether you are accessing a QA/UAT or production database. There are lots of jobs out there where you focus on configuration management in the sense of configuring a package to run (actually customizing the runtime experience). This is often done through XML or properties files such as an application server (e.g. WebSphere).

Version control refers to checking in and storing specific versions of the source code and now there is a real difference between configuration control and version control. Years ago the terms were used almost interchangeably although back then (around the 80s and early 90s) we didn't have too many real version control tools. On mainframes we had Panvalet and I think that CA Librarian came soon after.

How about the rest of your CM Historians! What say you?

Bob Aiello
Technical Editor, CM Crossroads
http://www.linkedin.com/in/BobAiello

 

 

1 Comment

Another difference I'd like to mention is third party libraries, and other similar packages, utilized by Development to ccreate their products. Yes, these are virsioned, yet by their versioning, they can cause changes in configurations in order to use them.

Someone needs to keep track of the tools and packages in use, as well as track upgrades to these as they may (and usually do) have an impact on how a given application is built, thus also causing possible changes in the underlying service assets.

- John Howland May 19, 2014 - 11:17am

3 Answers

Bob Aiello's picture
Bob Aiello replied on August 14, 2013 - 11:37pm.

Hi LaShawn,

this is a great question and I actually reviewed this terminology in my book on CM Best Practices. Years ago there was really very little difference between configuration control and version control. This goes back to when we selected the versions of Cobol programs, copybooks etc for a release. Back then we referred to a baseline of the code as a configuration and, in some sense, it actually was. The technology has changed and the terminology has also evolved.

Configuration control now really refers to setting runtime dependencies and we often discuss "configuring" an application to run. An example would be a JMX control or even more basic - specifying whether you are accessing a QA/UAT or production database. There are lots of jobs out there where you focus on configuration management in the sense of configuring a package to run (actually customizing the runtime experience). This is often done through XML or properties files such as an application server (e.g. WebSphere).

Version control refers to checking in and storing specific versions of the source code and now there is a real difference between configuration control and version control. Years ago the terms were used almost interchangeably although back then (around the 80s and early 90s) we didn't have too many real version control tools. On mainframes we had Panvalet and I think that CA Librarian came soon after.

How about the rest of your CM Historians! What say you?

Bob Aiello
Technical Editor, CM Crossroads
http://www.linkedin.com/in/BobAiello

 

 

Pradeep Prabhu's picture

In addition to what Bob mentioned, configuration control applies to service assets as a whole, of which, systems configuration is a subset. In places where configuration baselines are adopted, configurations of the service assets must be within the limits that are recommended in the baselines - so, in a way, configuration control also means that the configurations of the Configuration Items (CI) don't cross above/below the limits defined in the baselines. That way, we ensure that all the assets follow uniform configurations. If and when there is a need to cross these limits, the concerned team must get the approval of Change Advisory Board (CAB) in order to make those changes.  

To be more clear, service assets may include source/version control systems, scripts, infrastructure assets, documents, RFC tickets, SLA documents etc., to name a few. A simple version control baseline might recommend that the tool must have certain standardized branch structure or build configurations etc., so its standardized across all the environments.

Hope this helps!

~ Pradeep

 

Angie Dockery's picture

Sorry for the late response but I just had this discusion with a new manager of Software Configuration Management.  I explained it this way (a very simple viewpoint):

Version Control is basic check in and check out of files that may or maynot track the reason or require approval of changes to the files.

Change Contol is tracking,incoprating and verifing only approved changes of files into a baseline.

I know it is a very simple view but it helped her understand the importance in why Change Mangement is important not only in an operation enviroment but in the development process as well.  My view is the most important task a CM has is to protect the baseline and know excatly what is in it.
©2011-2013 TechWell Corp.