branch or codeline. When the branch/codeline is promoted, it means all versions of all the files on the tip of the codeline have progressed to the next integration level. This can be implemented very efficiently, often by associating an attribute or meta-data with the codeline name. It has somewhat limited use, however, as it cannot be used if only a subset of files on the codeline need to be promoted. The branch is treated as the unit of encapsulation for the set of files and versions that are promoted together (the same behavior that makes it efficient also limits its applicability). 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. It can be weak at providing traceability to (and reproducibility of) earlier states of the codeline corresponding to previous promotion levels.
Promotion Branches (Promotion Branching)
This is becoming an increasingly popular approach, as version control tools provide better support for quick and easy branching in a project-oriented fashion, rather than per-file. Each promotion branch corresponds to a promotion level in the promotion lifecycle. When a set of versions is to be promoted from one level to the next, they are merged, often copy-merged, from the current promotion branch to the next promotion branch in the promotion lifecycle.
As with branch promotion, promotion branching uses each branch as a unit of encapsulation. This time, however, the promotion branch doesn’t represent a set that is promoted together. Instead, it represents a consistent set of versions, all at the same promotion level. The major drawback of this approach should be (hopefully) obvious. It can require additional branching and merging for work that doesn’t represent true parallel activity, and require additional time for copy-merging files whose contents didn’t change between promotion levels. Despite this drawback, a promotion branch can still be extremely appropriate when it corresponds to a transition that is another level of integration and, hence, 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 incompatibly different codeline policies, as recommended in the best-practice “Branch on Incompatible Policy” . In some circumstances, even when parallel development isn’t required, if two different groups of people want to use the same codeline, but have very different needs regarding codeline volatility/stability, integration frequency, and access control, it can be more productive to give them each their own codeline.
Label Promotion (Promoted Label)
Label Promotion associates a promotion level with a label or tag and, thus, with all the file versions referenced by the labeled configuration. Since a label can span versions of different files across multiple branches, so can label promotion levels. As with branch promotion, label promotion transitions an entire configuration of files to a new promotion level in one fell swoop. Label promotion is appropriate when an entire build passes from one promotion level to the next without modification. No modifications are necessary and no new label is needed. As such, 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. If a label would have to be created only for the sake of having a promotion-level (and otherwise wouldn’t be needed), then label promotion can be very inefficient in such cases.
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