Agile Build Promotion: Navigating the Ocean of Promotion Notions

also work well together in combination with promotion branches: Promotion branches can be used for promotion transitions that correspond to a new level of integration, and label promotion can be used to avoid what would otherwise be unnecessary copy-merging from branch to branch. Thus, for a given labeled configuration that spans multiple branches – the version of a file in the configuration indicates the corresponding level of integration for that version and the promotion level of the label indicates the corresponding level of testing. (Of course combining promotion strategies together adds to the complexity of the overall promotion model implementation.)

Promotion labels (promotion labeling)
Promotion Labels are almost identical to Version Promotion. In fact Promotion Labels can be regarded as a form of version promotion where a label is used to make the association between a version and its corresponding promotion level.

Promotion labels share the same drawbacks as Version Promotion. Labeling the configuration of files and versions to be promoted can be very time-consuming for a large project (even when fully automated). And because it is common to name the promotion label only after the promotion level (and not include context information in the promotion label name), it can’t be easily used when multiple projects/codelines are in fact which may each have different versions of the same file at the same promotion level at the same time for different projects. However, some like the fact that it lets them see all the labels for each promotion level on each version so they can easily audit to see if a level was “skipped”.

Make it Lean and Agile
So how do we take a “big picture” approach regarding how to keep our promotion schema “agile” and in accordance with the principles of lean thinking and lean programming/development [6][7][8]? We start by keeping it simple (KISS) and eliminating any unnecessary and redundant promotion levels and promotion mechanisms:

• Don’t use promotion branches where it doesn’t already make sense to branch
• Don’t use label promotion where it doesn’t already make sense to create a label
• Try to avoid unnecessary copy-merging
• Let the promotion structure and mechanism “emerge” from necessary usage; don’t try to force-fit a particular model or mechanism

Those guidelines may seem obvious, but can often be easy to forget when concentrating on a particular promotion lifecycle and/or its implementation. If we look at some of the patterns from the SCM patterns book [2], we can actually see that the skeleton of a basic promotion model is present, without having attempted to explicitly define or impose a particular promotion lifecycle or implementation:

• Task Branch, Active Development Line, and Release Line can each correspond to a kind of promotion branch (as can Release-Prep Codeline, which might correspond to a QA Release build while the Release Line corresponds to a more formal Customer Release Build). And each such codeline may warrant it’s own integration workspace.
• An Active Development Line may be distinctly separate from a Release Line when the two codelines have different sets of users with incompatible policies
• Integration Test and Integration Build can (when necessary) correspond to two different promotion levels for the same label and/or branch

In general, applicability of the various promotion mechanisms is as follows:

• Either a task-branch or a tool’s built-in “task-based development” mechanism is suited for promotion of a change-set.
• Branch Promotion is appropriate to use for promotion-transitions that are “all or nothing” for the entire codeline, and when the codeline is primarily referenced by its “tip” (and not some previous state of the codeline)
• Promotion Branching is appropriate for a transition that is another level of