Agile Build Promotion: Navigating the Ocean of Promotion Notions

our project, the next question will be how to implement that using our SCM or version control tool. There are a multitude of different implementations that recur in practice, and different tools seem to support (or even prefer) some implementation approaches more strongly than others. The items undergoing the “promotion” range from versions to workspaces, branches/codelines, and labels/tags. The most commonly recurring “patterns” are as follows:

• Version Promotion (Promoted Versions)
• Promotion Workspaces
• Branch Promotion (Promoted Branch)
• Promotion Branches (Promotion Branching)
• Label Promotion (Promoted Label)
• Promotion Labels (Promotion Labeling)

Version promotion (promoted versions)

This may be the best known of the promotion implementation approaches. It was popularized by some of the earlier version control tools like CCC and PVCS. Individual file versions are assigned attributes corresponding to their promotion level.

For example, if our promotion levels were named {Private, Team, QA, Customer, and Failed} then each file version would be associated with at most one of these promotion levels. When a set of versions progressed thru a new promotion milestone, those versions would be “promoted” to the next level by changing their promotion-level attribute to the next value in the progression (e.g., from “Private” to “Team”, or from “Team to “QA”).

In theory, every time a file is checked-out and then back in, it starts over again at the initial promotion level. So you can always tell which files on the “tip” of the codeline are “fresh” and which ones are more “mature.” You can also easily discern if all the files on the tip of the codeline are all at the correct promotion level prior to releasing.

This seems fairly straightforward, and some version control tools assume this particular approach and make it available “out of the box.” If you have to implement it yourself though, it can be cumbersome to apply/update the attribute for all affected versions, or to even identify all the affected versions. Some would also argue it can be confusing to keep track of which versions are the “current” ones to use.

Promotion workspaces
This is quite possibly the oldest of the promotion implementation approaches, dating back to when source-code version control and related tools were in the “stone age” and a “version control tool” was only slightly more than a backup/restore mechanism. One of the earliest published examples is from the IBM OS 360 project [4] where “source-code libraries” were stored in so-called “vaults”: one for development, another for integration/test, and a third for release/distribution.

In more modern times, a workspace (or sandbox) would be used to represent several of the promotion levels, especially those that corresponded to a distinct level of integration and test. Code would be “promoted” by merging it and checking it in to the next “promotion workspace” in the progression.

This approach is also straightforward, and doesn’t have the drawback of having to apply a named “promotion level attribute” to every version. It does suffer the overhead of having to copy/merge versions from workspace to workspace, often even if not all the versions changed. Furthermore, workspaces aren’t necessarily “first class” entities in a version-control system, so it may be difficult to know what promotion-level a version corresponds to without knowing which promotion workspace it came from, and whether or not the other promotion workspaces have the same or different version of that file.

Promotion Workspaces are often well suited for promotion levels that correspond to distinct levels of integration and/or ownership, particularly when combined together with some of the other approaches. (For example, it can sometimes make sense to have a separate branch and workspace for a particular promotion level.)

Branch