ASI

Software Configuration Management Overview

In software development it is critical to maintain a historical trace of the changes your software programs go through and what code is being moved to what environment.  Software developers (programmers) need the ability to go back in time whether it is recent or in the past, to a specific version of the code if necessary.  Even Test Engineers implementing test automation scripts have the same need.  This is only possible when using a version control tool wrapped in process.  This document is a simple overview and explanation of the key principles involved in implementing a simple yet effective Configuration Management process.

Configuration Management encompasses four key principles in software development:

1. Process Control
2. Version Control
3. Build Management
4. Release Management

Process Control
We begin with Process control because without Process and Procedures you will be working in a chaotic environment where things are done at random and you have no ability to revert to early changes in a code base.  Some people resist Process as they think it is too restrictive and doesn’t enable them to get the “job done”.  A solid process will enable people to work efficiently and in a “controlled environment” so that changes are not lost and easily accessed if needed.  Process does NOT have to be restrictive, annoying or time-consuming.  A properly structured process should be “no big deal” and work procedures should execute smoothly.

This Process should define the tools used and how code is moved across environments.  This process should be defined, documented and the tracking of code versions implemented across environments should be tracked (ideally in a tool).  Surprisingly it doesn’t take a lot of effort to implement a solid process and enable you to “mature” your software development process which helps you climb the Capability Maturity Model (CMM) levels.  I have implemented simple processes that have enabled me to pass sophisticated process audits conducted by Ernst & Young without any deficiencies on the first audit.

Processes can be as complex as you want but I discourage that as the more complex, the more effort it is to implement and easier for people to find excuses not to use it.  Keep it Simple so that it will be used!  It can be automated or manual – my current process is a mix with a lot of manual process but with some scripts to help with deployments.

Process begins with documentation!  Document your process and make the process known.  If you can’t easily explain the process then there will be a definite problem with implementing it.  With the documentation should be some simple workflow diagrams to provide a simple visual of process – some people are more visual and understand things quicker by looking at a diagram.  You can use a simple tool like Powerpoint or get more advanced with a tool like Visio.

Now you need some tools to finish the process…

Version Control
Version control is simply the ability to track specific versions of code that is being developed.  A developer will “commit” changes to the Version Control repository to save specific points in time with what the code was like.  By doing this a developer has the ability to go back in time and grab a specific version of the code in case it was decided a specific code change was not needed or all together wrong and the developer wants to start over again – this is the easiest and most sophisticated way of doing this.  The process of saving (“committing”) specific versions of code and then grabbing a specific version is known as “check-in” and “check-out”. Each time someone needs to edit a file, they check it out for exclusive editing and then check it back in to the repository when finished, thus creating a new version.

When using Version Control you can also do the following tasks:

• Roll back to a previous version of a specific file
• Compare two versions of a file
• Provides a locking mechanism so that no one else can modify the file while you are making your changes
• Create branches so that multiple developers can be developing different code at that same time
• Ability to move specific file versions from one environment to another (Dev to QA to Staging to Production)

Build Management
This part of the process can be either manual, automated or a hybrid of some automation with some manual processes – this is what I currently implement.

The term “Build Management” is defined by Wikipedia as:

     “Software build management is the defined and controlled process of delivering the right artifacts efficiently.”

What is important here is that you need to define and control what versions of software are being moved from environment to environment – and most importantly what is being tested by the software testers is the same code being pushed to Production.

Build Management Process:

• Trunk – A typical process is to begin with a base foundation of a code base.  This is known as the “Trunk” and is representative to what is actually in your Production environment.
• Branch – A developer will request a “branch” which is a copy of the “trunk” for the developer to work in.  Numerous “branches” can be created so that multiple developers can work on various projects at the same time without stepping on each other.  This is important when one project will be delivered to Production before another project; this enables the developers to work independently of each other.  A “branch” can then be provided to the testing team to be verified for its functionality (typically Functional Testing and Regression Testing are applied to a branch).  This “branch” can easily be moved to a secure QA environment for testing.  Multiple projects can be handled and tested independently this way.
• Staging Release – when a group of projects have been tested and ready to be tested at the “System/Integration Testing” level, then the verified “branches” will be merged into a transitional version of the code base that would ideally be deployed to Production.  This naming convention can be anything.  In our environment we first create a “Candidate Release” which is all the branches merged into a single code base (the “future trunk”) and tested in the QA environment (remember this process brings all the code modifications together in one code base so now the testers can conduct “System/Integration Testing”, “Performance Testing” and a final “Regression Test”).  Once this has been certified, we then create a “Stable Release” (which is a copy of this Candidate Release) for deployment to the Staging environment and ultimately the version that is moved to the Production environment.
• Trunk update – finally once the Production environment has been updated with the new code base, the “trunk” needs to be updated as the “trunk” is always representative of the code base in Production.  So this code needs to be “merged” to the trunk.  Now all existing branches being worked on that have not been deployed to Production yet need to be updated with the “trunk” in order to stay current.

“ALWAYS PROTECT THE TRUNK!”

Release Management
Release management is the execution process of the Build Management Process and the Process of moving code from one environment to another.  It is critical that security be implemented here as only a restricted few individuals should have the ability to merge code and have server access to move code from one environment to another.  Without this you lose all control as anyone would be able to move whatever version of code to another environment without anyone knowing.  This can not only create major issues in code, but can make debugging a Production issue a nightmare and then when someone follows the actual process and moves new “controlled code” to Production they will end up replacing the code that bypassed the process because it was never merged to the trunk properly and gets lost.

Software Configuration Management Tools
I currently use the Open Source Tool “Subversion (SVN)”.  We use this in a Linux environment and primarily version control the following types of files: PHP, Javascript, HTML, and jpg images (however there are many other files under our configuration management tool but this is the majority of files we manage.

Open Source Tool:

• Subversion (SVN)