Software Configuration Management

Steven J Zeil

Last modified: Nov 30, 2020
Contents:

Abstract

Over time, a software system can exist in many versions:

Software Configuration Management (SCM) is concerned with all of these.

Some of the tools we have already looked at (build management, version control) can help. But in SCM we need to look at the strategic application of those to the management of many different software versions.

1 Problems Addressed by SCM

1.1 Codelines and Baselines

1.1.1 Codelines and Baselines: Example

 

A baseline merges components that we have written (a version out of our codelines) with versions of 3rd party components that we employ.

1.1.2 Baselines

2 Environment Management

Coping with the different environments in which the software may need to be installed and/or built.


Example: the ODU Extract Project

Metadata extraction system, needed to support


Third Party Libraries

 

Baselines may involve multiple 3rd-party libraries.

Luckily, there’s automated support for this aspect of SCM, which we will cover separately.

3 Build Management as an SCM Activity

 

3.1 Baselines Managed by Build Manager

3.2 Simpler Project Structure

In current practice,

4 Version Control as an SCM Activity

We’ve spent time looking at version control already.

We have lots of flexibility in terms of

SCM challenges us to think strategically about how to exploit that flexibility.

4.1 Codelines == Branches

 

5 Change Management

 

5.1 Making Decisions

In large organizations, changes are approved by a Change Management Board.

E.g., the team working in an exploratory branch has demonstrated an attractive new feature.

5.2 Change Propagation

Even in smaller projects, the issue of change propagation across code lines needs to be kept in mind.

 


 

5.3 Merge Requests

Open source projects often have a structure of

Typically, the main release branches can only be modified by the core developers.

5.3.1 Everybody has their own branches

Remember that, in the git distributed model,

5.3.2 Contributors…

 

  1. Create their own branch from one of the release branches.
    • This is more or less automatic in git anyway.
  2. Edit the code to add a feature of fix a bug.
  3. Commit their changes in their branch.
  4. Send a “merge request” to the core developers identifying the branch containing their work and indicating the issue they were working on.

5.3.3 Core developers…

 

  1. Accept the merge request.
  2. Check out their own copy of the relevant release branch.
  3. Merge the changes from the contributor’s branch into that release branch.
  4. Run tests and quality checks.
  5. If the contributor’s contribution is approved, pushes those merged changes into the central repository.