When developing projects of any size large enough to require more than one or two participants, without a method to ensure consistency, it can be easy to introduce regressions into the software. Whenever there are revisions to code, without a process in place, code can become fragmented and difficult to use and understand. There may be multiple different versions of the same software in various states. Bugs that had previously been fixed can easily become reintroduced if the wrong version of software is worked on. Worse, if the software has forked into simultaneous versions, it can be nearly impossible to determine which is the most recent version.

Software configuration management, or SCM, is a set of policies, procedures, and methods for organizing development into a consistent process. SCM is designed specifically for software with different developers, possibly in different locations. 

It enables people to work on different aspects of the software without interfering with each other, and end up corrupting the original copy. It provides several built-in mechanisms, ranging from automated testing to versioning to help maintain code and project quality. 

Why is Software Configuration Management important?

To get an idea of the reasons for Software Configuration Management, it may be helpful to examine the sort of things that can occur without it. Here are a few examples:

Concurrent development 

Say you have more than one developer working on the same file at the same time. Neither is aware that the other is working on the file, and while they may be working on different segments, when it comes time to commit the files, it is possible for the second person to accidentally overwrite the work done by the first person; they are both using the same file and the system simply takes the most recent one, resulting in all of the work done by the first person to be lost. 

For any piece of software larger than small vanity projects, there are often multiple people working on software. Teams can often be located in different geographical locations, and it can be difficult to communicate from one person to another at all times.

Buggy, untested code

If there is nothing in place to make sure that new code does not break any existing code, changes may inadvertently cause issues in other parts of the application. While a diligent developer may attempt to perform their own integration testing, bugs can be easy to miss, and when found later on in the process (such as in production!) it can be difficult to track their origin. 

Unclear versioning

If a large application goes through any major revisions, or if there are multiple versions of this software,  there may be multiple running versions in use, some of which have outdated code. There is no standard acceptable test or baseline; the code is a mess and functions poorly at best.

Cost Control

Any of the above flaws can result in increased cost as troubleshooting or fixing messes that can occur with a poorly organized workflow system can be extremely expensive.

Beyond these obvious pitfalls, there are a number of other reasons why SCM can be crucial for software development.

Stakeholder Coordination

As mentioned earlier, keeping all stakeholders on the same page is important. By creating a well-structured software management system, roles can easily be combined and/or coordinated. In an Agile organization, SCM is a key component in ensuring that people can not only work within their own areas of expertise, but also to be able to consistently share information and code with others on the team if there is a need to pick up the slack anywhere.

Changing Requirements, product schedule, etc.

If there are any changes in the requirements to the software, it makes best sense for there to be a clearly established set of policies in place. If the schedule of a project changes, this needs to be communicated and controlled across the entire application to all teams.

Who are the Stakeholders?

Configuration Manager

The configuration manager oversees identifying each of the configuration items and ensuring that that all participants follow the SCM processes. Any changes to the SCM process need to go through the Configuration Manager who makes all decisions regarding any modifications to the plan.

Project Manager

The project manager ensures that the project is developed along a preset time-frame. He or she monitors progress on the project and is responsible for being aware of any potential problems or conflicts that might occur as a result of the SCM procedures and initiate any requests for changes. 

Developer

The developer is responsible for changing code to ensure that workflow in automated processes remains consistent to the overall goals of the SCM. Any code conflicts that arise are the responsibility of the lead developer. 

Auditor

Auditors monitor the SCM process and ensure that software remains consistent throughout versions, and follows all policies.

Users

Users, while not directly in the flow of development, should have a basic understanding of the key terms and versioning systems to ensure they are using the right version of the software.

What are the components of SCM?

Baseline

The baseline is an accepted working state of the software. It refers to the most recent up-to-date stable version.

It is the formally accepted version of a software configuration item, and can only be modified through change control procedures. All baselines are considered to be stable and releasable. Different types of baselines are divided into functional, development, and product baselines.

Mainline

This is the main working area for software in development. It is made up of a copy of the baseline but may not be as stable.

Version Control

This refers to the system wherein different versions of the software exist. Each can have its own baseline, but version control ensures that development follows along the correct path and if there is forking of features into different branches, that they can be independently supported.

For example, versions 1.7 vs 2.2 are kept separate. 1.7 may have been built after 2.2, but is dependent on the baseline for version 1 and not 2. 

Workspace Patterns

Workspace patterns are where development occurs. Typically, patterns are divided up into private workspaces, which are copies of the mainline, where developers can work on code without interfering with the functionality of the baseline or with other developers. Other patterns exist for automating various testing modes, including smoke, unit, and integration testing.

Codeline Policies

Codeline policies are the rules and guidelines for the use of the code. These will typically include guidelines for how often code is checked in, how much testing is required to be performed on code, and who oversees code check-ins.

Codeline Patterns

Codeline patterns, often referred to as branches (in git, for instance), are used when there’s a risk that any development work could result in the mainline becoming corrupted. Branches, while often considered a developer’s friend, should be limited in their use, as too many can increase the chances of conflicts occurring.

When working with codelines, there are a number of best practices. These include: 

  • Limit the number of codelines.
  • Test early and often
  • Integrate early and often
  • Use tools for test automation, build, integration (mabl, Vagrant, Jenkins)

 

What are the Tasks Involved in SCM?

Configuration Identification

One of the first steps in SCM is to create a record of all items that need configuration. The relationship between each of these items is identified, and an infrastructure is created for maintaining multiple levels of control. A software configuration management plan is created.

Software Configuration Management Plan

During this period, the scope of the system is defined, and a naming convention and versioning system is established. Sets of procedures to identify when items should be backed up are created. 

Individual roles are defined, and a set of policies are put into place for change control. The tools which are to be used are defined in this period, and a database for keeping records of all configuration information is created. 

Change Control

Change Control is the method for defining how changes are made. They include procedures to ensure quality/consistency.

This process controls any changes and handles how changes are committed to repository and/or merged with master baselines. Changes are checked in and evaluated against the rest of the system to ensure that everything will continue to work properly. Change control manages changes, making any items in the configurations available at any point during the software lifecycle. 

Configuration Status Accounting

Configuration Status Accounting keeps records of all changes, identifies and defines all items in software config, and monitors the status of any requests for changes. The accounting process lists and tracks all changes since last baseline, while tracking all progress toward the next baseline.

One of the most important features is that it allows access to previous versions for testing purposes.

Audits and Reviews

Regular audits and reviews of code occur throughout the SCM process. During audits, all changes are reviewed to ensure that they comply with initial requirement documents, and also with the process.

These audits perform regular checks to make sure all procedures are being followed, and make sure everything in config status accounting is being adhered to (compliance with statuses), with the overall goal of maintaining completeness and consistency.

Reporting

SCM also considers the importance of documentation, to provide accurate status and any important information about configuration data to all stakeholders in the process. These can include:

  • Administration guides
  • User guides
  • FAQs
  • Release Notes
  • Memos
  • Installation Guide
  • Configuration guide, etc

What Tools are used?

Good Software Configuration Management processes involve making use of various tools available to make the tasks more efficient, effective, and easier. Below are a few examples of the types of popular tools.

  • Configuration Management (e.g. Ansible, CFEngine, Puppet)
  • Source code repository (e.g. Git, Mercurial)
  • Build tools (e.g. Jenkins)
  • Documentation (e.g. Wikis)
  • Artifact repository (e.g. Maven, Ivory, Docker) 
  • Testing (e.g. mabl, Selenium)

Summary

While the process may seem complicated and can seem like the creation of an additional level of work on top of the already involved coding process, in projects of any size, some form of SCM is crucial. Solid procedures go a long way toward ensuring a solid project. The work involved in setting up SCM procedures may front-load a project, however it may serve to make sure that everything runs much more smoothly, with fewer conflicts down the road. For those of us with any experience working without it, SCM is something we recognize as an absolute necessity in development, particularly if more than one or two people are involved.