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. 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 each have different versions of the same file, at the same promotion level, and at the same time for different projects. However, some like the fact that it lets them see all of 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 ,,? We start by keeping it simple 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 , 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. This might correspond to a QA release build, while the release line corresponds to a more formal customer release build. Each 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. It is not some previous state of the codeline.
- Promotion branching is appropriate for a transition that is another level of integration and, therefore, merging would be performed anyway.
- Promotion branching can also be appropriate for a promotion level that corresponds to a change in ownership between two groups that would otherwise require incompatible, different codeline policies.
- Label promotion is particularly well-suited for a promotion level that progresses from a built/integrated or test/QA promotion level to another test/QA promotion level.
 Build Management for an Agile Team ; by Steve Konieczka, et.al.; CM Crossroads Journal, October 2003 (Vol. 2, No. 10)
 Software Configuration Management Patterns: Effective Teamwork, Practical Integration; by Stephen P. Berczuk and Brad Appleton; Addison-Wesley, November 2002
 Beyond Continuous Integration. A Holistic Approach to Build Management (Part 1 of 2) ; by Maciej Zawadski; CM Crossroads Journal, October 2003 (Vol. 2, No. 10)
 The Mythical Man Month: Essays on