A race track is built to accommodate a certain class of race car.  It provides a path in which a race car can travel around to start and finish a race.  The track is built as a permanent facility designed with materials and formation to ensure the track is easily maintainable and to enable that class of race car to travel in a reliable manner.  It is also important to build the track in a way that allows the race cars to reach their peak performance. 

What does this have to do with configuration management (CM)?  The race track is a lot like a CM infrastructure needed by product team to support the building of product.  The race car is a lot like the CM tasks that are executed to help the project race to the release finish line.

CM Race Track at the Product Level: Deployment

CM at the product level is the infrastructure race track that must be built to support lean and efficient engineering for the project.  When establishing CM infrastructure, it is recommended to have a separate CM effort that is independent from the engineering project whose goal is to use the CM infrastructure to create a set of deliverables known as a project release. Another goal is to complete the CM infrastructure in time for the engineering project to use (servers, tools, code repository, build processes, training, etc).

It is advisable for the product owner to provide the CM professional(s) with lead time to build an appropriate CM infrastructure for the product so that when project work starts, a functional set of CM procedures and technology are available to control that work and get it down the race track with speed and reliability.

We can think of CM at the product level as a focus on building and deploying the CM race track infrastructure for maintainability, reliability, and performance.  CM, at this level, does not directly involve getting a project release out to market, but involves CM tasks focused on building the infrastructure and processes that can support an engineering project.  The key areas of focus of CM at the product level include:

·         Assessing a product’s CM needs

·         Selecting a CM technology best suited for the product

·         Defining an product level CM Plan that ensures maintainability, reliability, and performance

·         Establishing a CM system and environment for the product

·         Establishing CM processes for the product (e.g., check-out/check-in, build, release, change control, problem management, etc.) that are built for performance and reliability

·         Performing CM training for those that work on the product

CM Race Car at the Project Level: Execution

CM occurs at the project level as well, focusing on what tasks must occur to deliver a release package. This usually involves check-out/check-in, build, package, and migration tasks and also includes change control and issue tracking tasks. These CM tasks fit nicely in an engineering project plan and most occur in the development and release phases of the project.  How effective these CM tasks are at the project level, depends on how well built the CM infrastructure is.

At this level, the CM tasks help a project to create and deliver a release to the marketplace.  At the project level is where we can hone the CM infrastructure as we drive the CM race car tasks to help get the release out.  We can identify where the CM infrastructure can be improved through the continuous use of the CM infrastructure (e.g., procedures, tools, etc.) via CM tasks to the benefit of the projects.  The key areas of focus of CM at the project level include:

·         Getting CM tasks into the project plan

·         Base-lining the code for the new development

·         Establishing the appropriate branching structures

·         Building/compiling the code

·         Creating a release package with deliverables

·         Conducting change control board (CCB) meetings

Automation

A key to deploying a CM race track is making as many of the processes as lean as possible, therefore reducing the steps programmers and CM professionals need when interfacing with the CM infrastructure.  One answer is automation.  Any process that is operational, meaning the steps are run again and again, can be automated.  This is particularly important for product teams that are using agile methods, although all methodologies will benefit from automation.  Some benefits to automation are:

·         Making actions less error-prone for improved reliability

·         Eliminating idle time for more lean processes

·         Making things more maintainable and repeatable

·         Making it easier to improve existing processes

Summary

In our lives, we are typically very busy. It is important to maximize the output of any task we perform. By focusing on building a CM race track infrastructure with maintainability, reliability and performance, we can derive the most benefit to the product team. This is particularly important in the lives of CM professionals who are inundated with work requests.  The more we build the infrastructure for maintainability and reliability, the more CM professional can focus on other work like automation and the more the product team can ensure what they are building is what they intended to build.  The more we build the infrastructure for performance, the more we can help the team more quickly get to their release finish line!

References

1) Chapter 6, “6.3  Automate, Automate, Automate for Agile”, p112-114 of “Adapting Configuration Management for Agile Teams” by Mario E. Moreira, 2010, John Wiley & Sons, Ltd Publishing

2) Chapter 1, “4. Examining the Target Levels”, p3-5 of the “Software Configuration Management Implementation Roadmap” by Mario E. Moreira, 2004, John Wiley & Sons, Ltd Publishing.