The Build Tools Directory Structure

One of the most important tasks for enabling automated Software Build and Release Management is making sure that everyone is using the same versions of the build tools. By build tools I mean any build scripts, build programs, or third-party libraries, including all the tools I identified in Chapter 2, "Tools of the Trade." The best way to achieve this is to version-control the build tools in exactly the same way as you would any other software development asset. There are essentially two ways to create this structure:

• Consolidate all the build tools into a single high-level directory structure.

• Create a separate component directory for each tool.

These approaches are illustrated in Figure 3.1. The advantage of creating a separate directory for each tool is that with ClearCase you can label or baseline at both a high level (across the complete VOB) and a lower level (across a tool directory). This allows you to be more flexiblefor example, selecting a previous version of an individual tool for debugging or testing purposes.

Figure 3.1. JavaTools directory structure

Note that your own structure doesn't have to match Figure 3.1 exactly. I am using it as a common reference point and to illustrate where the different tools can be installed. The remainder of this section discusses how to create the structure for the second approacha separate component directory for each tool. For the sake of clarity, the build tools VOB I will be creating is called JavaTools.

The exact process to create this directory structure depends on whether you are using Base ClearCase or UCM. It can be carried out through either the ClearCase graphical user interfaces (GUIs) or the command line. For the purposes of illustration, I will step through the sequence of Windows command-line actions required to carry out this configuration. I will reinforce this by illustrating how some of the same operations can be achieved using the GUIs. I'm not saying that the command line is better or worse than the GUIs; it's simply easier to explain and be complete in this form. Also, because of the portable nature of the command line, these instructions can be easily mapped to different platforms, such as Linux or UNIX.

To create ClearCase views and VOBs, I use existing ClearCase storage locations. A storage location is essentially a network-viewable disk area, such as a Windows share or UNIX network file system (NFS) mount point that ClearCase has designated for data storage. On Windows, the Storage Location wizard usually runs after the installation process and creates the storage locations for you (you can check using cleartool lsstgloc). I will assume that the following storage locations exist:

• ccstg_d_vobs For storing ClearCase VOBs. This might map to the physical disk location D:\ClearCase_Storage\VOBS.

• ccstg_d_views For storing ClearCase views. This might map to the physical disk location D:\ClearCase_Storage\Views.

By referring to storage locations, the text for each of the ClearCase commands is reduced and consequently also is more portable. Finally, the sample command lines make use of snapshot views; this is solely to allow them to be applicable to both Full ClearCase and ClearCase LT. It doesn't indicate whether one type of view is better than another.