Concepts: Promotion Method
Topics
As the project progresses and the completeness and stability of baselines improve,
"promotion levels" can be used to characterize the baseline in terms
of its completeness or stability. Promotion levels and other baseline attributes
should be defined as appropriate to meet the needs of the individual project,
although you'll typically find that a common set of definitions can be reused
in many different projects. Here's an example of promotion levels that might
be appropriate to use:
- Integration Tested
- System Tested
- Acceptance Tested
- Production Delivered
In this example, the levels are sequenced to reflect the relative progression
in completeness and stability of the software over time. Note that while the
software will usually progress forward through these levels, it can also regress
in terms of completeness or stability. The act of changing the promotion level
of a baseline in the former case is called promoting and in the latter case
demoting the baseline.
On occasion, the configuration manager may need to demote a baseline by changing
its promotion level to one that is lower in the promotion level order. For example,
the integrator may discover a a major bug in a newly created baseline. To prevent
developers introducing this bug into their development workspaces, the problems
with the baseline can also be more clearly indicated by adding a label to the
the baseline such as "rejected".
The recommended baseline represents a system configuration that has achieved
a specific promotion level. A baseline becomes part of the set of recommended
baselines when it is promoted to a certain level, for example, "Acceptance
Tested". Promotion levels can be used in project development policies.
For example, a policy on a project could be that a given baseline is considered
"recommended" when it reaches a particular promotion level. This policy
helps to ensure that developers rebase their workspaces whenever a baseline
passes an acceptable level of completeness and stability.
|