Composite baselines in component-oriented projects

In component-oriented projects, significant savings can be realized by modeling subsystems with composite baselines. For example, projects that integrate the subsystems can rebase to a single baseline to configure a subsystem (see the following figure).

When composite baselines are used to model subsystems, they are logical components built of smaller components. The components used in constructing a subsystem are either shared (read-only) or modifiable (they contain the work particular to that subsystem). The important property of the shared components is that they are non-modifiable. If a subsystem requires changes to a shared component, that requirement can interfere with the ability to share that component. The modifiable, custom components store the code that is needed to integrate the shared components and to provide the unique functions of the subsystem.
Figure 1: Composite baselines representing subsystems

Project Y is configured with composite baseline E.BL1. Composite baseline E.BL1 has member baselines AC.BL1, BCD_BL1, and E_BL0. Baselines C.BL3 which is contained in AC.BL1, and C.BL1 which is contained in BCD.BL1 have shading; the other baselines are plain. An extra baseline, Cx.BL3, appears outside the hierarchy and is marked Override.

Project Y is composed of the custom component E and the components AC and BCD, which both share component C. It does not matter whether baseline E.BL1 is a product, a .DLL, a lower-level library, or another component.

In the composite baseline E.BL1, a component-oriented approach to development can be more prone to baseline conflicts than a release-oriented approach. The frequency of baseline conflicts depends on the following factors.
  • The number of shared components
  • The processes in the development organization
  • The coordination among the different teams developing subsystems

The more closely the teams that produce each component coordinate their work, the less likely conflicts will occur.

If development teams need complete freedom in selecting baselines of the components that they use, conflicts are more likely. Conflicts occur because of the difficulty in ensuring that a random baseline of one component, for example, AC, will work with a random baseline of another component.

Baseline E.BL1 can be considered as consuming baselines AC.BL1 and BCD.BL1. However, it is not a true producer and consumer relationship. Composite baseline E.BL1 is not using the AC.BL1 baseline; it is using AC.BL1 plus the override, baseline Cx.BL3 (see the figure). Therefore, baseline E.BL1 is not actually using the product of project X. The X project does produce AC baselines, but, in a situation with conflicts, the baseline is a guideline rather than a rule for projects that need the AC component.

If these subsystems were in a release-oriented organization, composite baselines would represent a tight coupling of baselines, for example, baselines A.BL1 and C.BL3 shall be used to make baseline AC.BL1. But in a component-oriented organization, composite baselines represent a looser coupling, that is, baselines A.BL1 and C.BL3 should be used to make baseline AC.BL1. But the project integrator can chose to override the coupling between baselines. Therefore, in a component-oriented organization of projects, a composite baseline is more of an indication of the components that should be used to create a subsystem rather than a requirement to use them.

Therefore, selecting a baseline override in a component-oriented organization needs to be careful and deliberate. Project integrators need to be aware that, in selecting a baseline override, they are changing the decisions made by the project that produced the component. There might be specific reasons why the BCD component is compatible with the C.BL1 baseline, for example, a different baseline could cause the component to fail. Often, using a descendant of baseline C.BL1 is successful, but the selection of override baselines is not restricted in the DevOps Code ClearCase® environment. There is no guarantee of the relationship between baseline C.BL1 and the override baseline Cx.BL3.

As the time approaches for a component to be completed, the use of baseline overrides can be destabilizing to a product, because they can represent significant code differences. These differences can be managed by coordinating the work of the projects that produce each subsystem. As the time for completing a component approaches, the teams can agree on the lower-level components so that conflicts are reduced.