Annotated Summary of the Patterns

A brief summary of each pattern from the original SCM Pattern Language published in Software Configuration Management Patterns, with some brief notes.

Mainline

Minimize merging, and keep the number of active code lines to a manageable set by developing on a Mainline.

Mainline is similar to Trunk Based Development in spirit, but doesn’t preclude short lived branches

Active Development Line

Keep a rapidly evolving code line stable enough to be useful by creating an Active Development Line.

An Active Development line can be a branch of your main line. I tend to favor an main line development model.

Private Workspace

Prevent integration issues from distracting you, and from your changes causing others problems by developing in a Private Workspace.

This is relatively trivial now in environments that have good dependency management and either no system level dependencies or the ability to work in an isolated context (containers, Python Virtual Environments, etc).

Repository

Set up a new workspace by populating it from a Repository that contains everything that you need.

Repository could also be called “one step set up.” The goal it to make it easy to set up a consistent development environment from a basic development machine. Automation is a bit part of it, along with some basic information in a README.

Private System Build

Check to see that your changes will not break the build by doing a Private System Build before committing changes to the Repository.

This seems pretty basic, yet I still encounter scenarios where people use a pull request CI build to build and test. Local builds and unit tests improve cycle time.

Integration Build

Ensure that your code base always builds reliably by doing an Integration Build periodically.

Agile, Continuous Integration, and Continuous Deployment were gaining traction as ideas at about the time that the SCM Patterns book came out, and those concepts fit in with Integration Build. Had they been more widely used at CI and CD would have been patterns in the SCM language at the time. CI belongs in the Pattern Language.

Third Party Code Line

Manage vendor code by using a Third Party Code Line.

Task Level Commit

Organize source code changes by task-oriented units of work.

The short version of this is to commit often with coherent bits of work, and clear commit messages.

Codeline Policy

Create a Code line Policy to help developers decide when to check in code to a codeline and what procedures to follow before a checkin on each code line.

This is key when you have multiple code lines. Having fewer code lines and having all but the main line be short lived is central to applying the pattern language in an agile environment.

Smoke Test

Ensure that the system still works after you make a change by running a Smoke Test.

As written, Smoke Test was a basic automated integration test that covers basic functionality. It surprised me how often I’d seen code with apparently good automated unit test coverage of the hard stuff break on basic steps after a change.

Unit Test

Verify that a module still works after you make a change by running a Unit Test.

While you’d hope that everyone unit tests, not everyone unit tests effectively. Unit test, are a core part of how you keep a code line active and agile.

Regression Test

Ensure that existing code doesn’t get worse as you make other improvements by running a Regression Test.

Much like Smoke Test, Regression Tests is a basic integration test that gives you confidence that you didn’t break anything. It may or many not be a complete regression suite, though the pattern talks about slow regression tests running in a CI type environment so that you aren’t blocked – because you expect it to work, right?

Private Versioning

Use Private Versioning to allow you to experiment with complex changes locally, yet still be able to take advantage of the features of a version control system.

A DVCS like git gives you this implicitly by letting you create branches and versions without pushing to the server, so this pattern has become part of the standard syntax for version management systems.

Release Line

Maintain released versions without interfering with your current development by establishing a Release Line.

Unless you truly have a working Continuous Delivery Process the a Release Line is the one long lived branch that you might want to have. This is where you can do emergency path releases and the like if you can’t incorporate changes into a new release. In practice this need not be a branch you create in advance, in a system like git you can simply create a tag, and branch if there is a change needed.

Release-Prep Code Line

Stabilize a code line for an upcoming release while also allowing new work to continue on active code lines by doing the stabilization work on a Release-Prep code line.

If you have a good agile process and using Continuous integration with reasonable automated testing, this may not be necessary. But some places still feel a need to “stabilize” their code before release, while doing new development. This is pattern is compensatory, but not to be encouraged. If you need to do this, you probably need to improve your test automation.

Task Branch

Have part of your team perform a disruptive task without forcing the rest of the team to work around them, using a Task Branch.

A Task Branch can be used in a number contexts. As originally written, it was about collaboration in a subtask. It can also cover work by one person on a task. The key with any branch is that it is short lived.