The baseline identification principle said that I need to be able to identify what I have to be able to reproduce. The baseline immutability principle said that the definition of a baselined configuration needs to be timesafe: once baselined, the identified set of elements and versions associated with that baseline must always be the same set of elements and versions, no matter how that baseline evolves in the form of subsequent changes and their resulting configurations.
Maybe somewhere in between the baseline identification principle and the baseline immutability principle should be the single configuration principle:
- The Single Configuration Principle would say that a baseline should correspond to one, and only one, configuration.
What does that mean? It means don't try to make a tag or label serve "double-duty" for more than one configuration. This could have several ramifications:
- maybe it implies that "floating" or "dynamic" configurations, that are merely "references", should have a separate identifier, even when the reference the same configuration as what was just labeled. So maybe the identifiers like "LATEST or "LAST_GOOD_BUILD" should be different from the one that identifies the current latest build-label (e.g., "PROD-BUILD-x.y.z-a.b")
- maybe it might also imply that when we use a single label to capture a combination of component versions, that we really want true "
composite" labeling support. This would literally let me define "PROD_V1.2" as "Component-One_V1.1" and "Component-Two_V1.0" without requiring the label to explicitly tag all the same elements already tagged by the component labels - maybe it implies something similar for the notion of a "composite current configuration" or even a "composite codeline" where a product-wide "virtual" codeline could be defined in terms of multiple component codelines
1 comment:
A baseline consists of a configuration, a configuration consists of configuration items, a configuration item consists of (meta-)data elements and an element consists of 1 or more versions.
The Single Configuration Principle not only applies to baselines, but also to lower granularities, until "a baseline corresponds to (0 or) 1 instance of element" (0 is included because a baseline may be a subset of all controlled items). Note that I rather talk about instance than version because (1) versions may not apply to every level of granularity, and (2) versions suggests an order (1, 2, 3, ...) while we also must take parallel (partially ordered) instances into account.
Also the Baseline Immutability Principle is to specific. I rather see the Instance Immutability Principle that says that an instance cannot be changed once it is committed to the CM system. To make a "change" you can only add or destroy instances. This applies to elements, but also to a configuration. So to "change" a system, you add a new configuration consisting of different (possibly new) instances of the elements.
This way the Baseline Identification Principle can be generalized also: every instance is uniquely identified (relative to other instances). Thus a configuration identifier is (in principle) the union of all instance identifiers, and a baseline identifier is nothing more than a short representation of a configuration identifier.
Frank.
Post a Comment