Build and Release Baselining Strategies

An important aspect of any overall build and release process is to automatically baseline sets of build inputs and outputs to maintain traceability and repeatability. Note that I am using the term baseline here as a generic term to refer to either Base ClearCase labels or UCM baselines. A baseline can be applied at a number of different points in time:

• Before a build is carried out Different components or directories can be baselined, and the build can select the appropriate combination of these baselines to perform a "system"-type build.

• Immediately before a build is carried out The build process can apply a baseline to indicate the exact set of versions going into the build.

• After the build has been carried out The build process can apply a baseline to indicate the exact set of versions that were built. Usually the build also initiates some form of unit or smoke testing before the baseline is applied.

The point at which you baseline really depends on personal preference. My preference is to baseline after the build and testing have been carried out. This way, you know that this baseline is of some agreed-on quality.

One question that often comes up is whether you really need to apply labels or baselines for Private and Integration Builds as well as Release Builds. Well, Private Builds have no particular need to baseline or label other than as a development checkpoint. For example, perhaps a developer wants to identify his own inputs to the build process or share a set of elements with other developers. The case for baselining or labeling Integration Builds is less clear. If you are conducting Integration Builds on a regular basissay, every 20 minutes as part of a continuous integration processbaselining or labeling every 20 minutes is somewhat of an overhead. Also, these builds are essentially throwaways. The only important Integration Build is the last one! However, what if you want to automate the process of recommending baselines via UCM? You need some baseline to recommend so that developers can rebase against it. Where will this baseline come from? Do you have to create it manually? Chapter 7, "CruiseControl Best Practices," looks at strategies for achieving this, but for now I will assume that there is potential to baseline or label any type of build.

The "type" or maturity of the baseline to be applied obviously depends on the build that is being carried out. You need some way to distinguish between good and bad Integration Build and Release Build baselines. With Base ClearCase you can indicate this either by the name of the label or by using attributes, and with UCM you can use the baseline promotion levels. The remainder of this section discusses the process of creating both.

Mixing Base ClearCase and UCM Project Structures

It is possible to mix Base ClearCase and UCM project structures in the same environment. Since UCM "builds on top of" Base ClearCase, it still exposes the underlying branches and labels. If one team is still working in Base ClearCase, you can in theory import any labels that they create on a regular basis and turn them into UCM baselines. Similarly, if "full" UCM baselines are created, not incremental, Base ClearCase users can see those baselines. In reality, this particular mix of project structures should be seen as a short-term exercise, because you can lose a degree of traceability as baselines are mapped between environments.

Applying Base ClearCase Build Labels and Attributes

For Base ClearCase labels, a standard, well-known convention is for the label name to be in uppercase. However, another less-well-known but often-followed convention is for the label name to include its "type" or maturity. For example, the following label names can be used (where XXX is the variable part of the label name):

• XXX_BLD indicates a Private Build label.

• XXX_INT indicates an Integration Build label.

• XXX_REL indicates a Release Build label.

Which convention you follow is not as important as following it consistently. This is more likely if the labeling process is automated. You will see how to achieve this using Ant in Chapter 5 and CruiseControl in Chapter 7. To apply a label across a set of elements, you first create a label type, and then you create instances of the label across the elements you specify. For example, to apply an Integration Build label across a directory structure, you would carry out the following commands:

>cleartool mklbtype -nc RATLBANK_01_INT >cleartool mklabel -recurse RATLBANK_01_INT . >cleartool lock lbtype:RATLBANK_01_INT

This example assumes that you are at the root of your build directory structure. Note that once the label type has been created, the label can be freely applied and even moved to different versions by using the -replace argument to the mklabel command. I do not recommend moving labels except in special circumstances, because you inevitably lose a degree of traceability.

Another way of indicating a label's maturity using Base ClearCase is to use attributes, which in ClearCase are name-value pairs. For example, you could create an attribute called PromotionLevel and allow it to have a value of BUILT, TESTED, or RELEASED. Attributes can be attached to most Base ClearCase objects; therefore, you can attach the PromotionLevel attribute to the label. Subsequently, at the same time you apply the label, you also could apply the attribute, as shown in the following:

>cleartool mkattype -nc -enum \"BUILT\",\"TESTED\",\"RELEASED\" PromotionLevel >cleartool mkattr PromotionLevel \"BUILT\" lbtype:RATLBANK_01_INT

This example creates the attribute type and sets the PromotionLevel attribute to the value BUILT on the RATLBANK_01_INT label.

Once a unique label has been applied, you can go back in time and find all the elements selected by any previous label. For example, to select all the elements in a view that has been labeled with RATLBANK_01_INT, the config spec could be modified as follows:

element * RATLBANK_01_INT

The combination of Base ClearCase labels and attributes is in fact similar to how UCM baselines work, as described next.

Applying UCM Baselines

You could use UCM baselines in the same way as Base ClearCase labels; however, if you did, you would not be using their capabilities to the fullest. UCM baselines are usually created across one or more activities and can be either incremental or full. The difference is that an incremental baseline is placed only across the elements that have changed as part of the activity, whereas a full baseline is placed across all the elements in a component. Consequently, it is recommended that full baselines be created for Release Build baselines. The other difference is that UCM baselines have a promotion level. This gives you capabilities similar to using attributes with Base ClearCase. For example, to apply a baseline across a set of activities and promote the baseline to the level BUILT, the following commands could be carried out:

>cleartool mkbl -full -nc RATLBANK_01_INT >cleartool chbl -level BUILT RATLBANK_01_INT@\RatlBankProjects

In this example, a baseline called RATLBANK_01_INT has been created. The promotion level for a new baseline is INITIAL. In this example the baseline is promoted to the level BUILT using the chbl command. Normally, you would not carry out the promotion right away. Instead, you would probably run through a build process, and only if the build worked would you promote the baseline. In fact, I automate this process with Ant in Chapter 5. The out-of-the-box set of baseline promotion levels is REJECTED-INITIAL-BUILT-TESTED-RELEASED, although you can change this to any sequence of names you want.

With UCM, you also get the additional capability of composite baselines and baseline naming templates, both of which were discussed earlier when the JavaTools directory structure was created. As an example of these capabilities, to apply a composite baseline across the set of changed components, you could issue the following command:

>cleartool mkbl -full -all -nc 01_INT

If the baseline naming template was set up to create a baseline of the form COMPONENT_BASENAME, for the RATLBANK component, the baseline RATLBANK_01_INT would be created. It would also create a new baseline in the composite baseline component to refer to this new baseline (for example, RATLBANK_BL_01_INT).