Choosing a Software Configuration Management System Part 2

This is the second in a series of blog posts exploring characteristics of development projects to consider when choosing a Software Configuration Management system.

Variant Management 
It is common for a software system to be used in multiple products.  For example, an app might have a free version for personal use and a more powerful version for corporate deployment.  Thus, there is a free variant and a corporate variant.  They share most of the software but have variant-specific code for each.  The SCM system must provide a way to share common code while isolating variant-specific code.  This must account for past and future releases of the needed variants as well as merging defect fixes forward to the appropriate contexts. 

Component Structures
Any but the smallest of software projects benefits from being organized into a number of components.  A component is typically a set of files that composes a logical group of related capabilities.  A component either depends on other components and/or is depended on by other components in order to construct a complete software system.  Each component may be “owned” by a separate team which is responsible for developing, fixing, and enhancing the component.   

When a set of changes to the component is complete, the owning team shares that version of the component (through a baseline of that component) with dependent software projects, which may or may not decide to adopt the new version in their next product release. 
Maintaining a logical component structure is a powerful mechanism to organize software projects and teams.  It divides a large software system into more manageable pieces, provides clear boundaries for ownership, and makes it easy to share components across multiple projects encouraging reuse. 
 
Distributed Teams 
The larger the team, the more likely it is to be distributed across different geographical locations.  Subsets of the team may work in different offices.  Others on the team may work from home. 

Some SCM systems provide a repository replication mechanism that periodically synchronizes the replicas distributed to the various team locations.  Others provide a client that supports “WAN (Wide Area Network) friendly” access to a centralized repository.  Each model has some advantages and disadvantages.  Some SCM systems support both models and allow mixing and matching solutions depending on the needs of the teams. 
 
Traceability 
There are a variety of types of traceability which serve different purposes.  While most projects benefit from at least some types, they can be essential for others (ex. projects subject to extensive regulation). 
 
Project Lifecycle Traceability 
Project lifecycle traceability allows related artifacts to be traced through much, if not all of the project lifecycle.  For example, a project manager will benefit from being able to trace from a set of requirements to their corresponding tasks in the change management system which would have linkages to the source code versions implementing the requirement and test results validating that the requirement has been satisfied.  The developer responsible for a task can easily request a code review since the task has linkages to the versions that implement the task.  A maintenance engineer can quickly find the versions of files that probably have the defect introduced in a recent patch and will know what tests to run through the task linkages. 
 
Change Traceability 
Change traceability allows the history of changes in the SCM system to be retrieved.  It can typically answer the “Who?”, “What?”, “Where”, and “When” questions of each change.  It may also capture the “Why?” question (especially if there is a linkage to an associated task in the change management system).  Examining the changes in the versions involved (greatly aided by effective compare/diff tools) can answer the “How?” question.  For example, change traceability makes it easy to find the developer that introduced a new feature in an API (Application Programming Interface) in case there are some questions about the behavior.  A lawyer who must provide a list of who contributed to a particular release can generate that from the change history. 
 
Build and Release Traceability 
Authoritative build and release traceability allows a release / build artifact (ex. an executable or shared library in a product release) to be traced back to the versions of files that were used to build that artifact.  If a developer finds that an executable fails today where it worked fine yesterday, they can use the build traceability information to see exactly which versions of files were used to build the executable today that were different from those used to build the executable yesterday.  This can be a significant time saver when trying to track down numerous problems.  

Authoritative build and release traceability can provide huge value for organizations that must be able to prove what they included in a product release due to regulatory or other legal requirements. 
 
Reach out with questions or comments below.