10.2 Implementing Development Policies

To enforce development policies, you can create ClearCase metadata to preserve information about the status of versions. To monitor the progress of the project, you can generate a variety of reports from this data and from the information captured in event records.

Using Labels

A label is a user-defined name that can be attached to a version. Labels are a powerful tool for project managers and system integrators. By applying labels to groups of elements, you can define and preserve the relationship of a set of file and directory versions to each other at a given point in the development lifecycle. For example, you can apply labels to these versions:

• All versions considered stable after integration and testing. Use this baseline label as the foundation for new work.

• All versions that are partially stable or contain some usable subset of functionality. Use this checkpoint label for intermediate testing or as a point to which development can be rolled back in the event that subsequent changes result in regressions or instability.

• All versions that contain changes to implement a particular feature or that are part of a patch release.

Using Attributes, Hyperlinks, Triggers, and Locks

Attributes are name/value pairs that allow you to capture information about the state of a version from various perspectives. For example, you can attach an attribute named CommentDensity to each version of a source file, to indicate how well the code is commented. Each such attribute can have the value unacceptable, low, medium, or high.

Hyperlinks allow you identify and preserve relationships between elements in one or more VOBs. This capability can be used to address process-control needs, such as requirements tracing, by allowing you to link a source file to a requirements document.

Triggers allow you to control the behavior of cleartool commands and ClearCase operations by arranging for a specific program or executable script to run before or after the command executes. Virtually any operation that modifies an element can fire a trigger. Special environment variables make the relevant information available to the script or program that implements the procedure.

Preoperation triggers fire before the designated ClearCase command is executed. A preoperation trigger on checkin can prompt the developer to add an appropriate comment. Postoperation triggers fire after a command has exited and can take advantage of the command's exit status. For example, a postoperation trigger on the checkin command can send an e-mail message to the QA department, indicating that a particular developer modified a particular element.

Triggers can also automate a variety of process management functions. For example:

• Applying attributes or attaching labels to objects when they are modified

• Logging information that is not included in the ClearCase event records

• Initiating a build and/or source code analysis whenever particular objects are modified

For more information on these mechanisms, see Chapter 12, Implementing Project Development Policies.

A lock on an element or directory prevents all developers (except those included on an exception list) from modifying it. Locks are useful for implementing temporary restrictions. For example, during an integration period, a lock on a single object-the main branch type-prevents all users who are not on the integration team from making any changes.

The effect of a lock can be small or large. A lock can prevent any new development on a particular branch of a particular element; another lock can apply to the entire VOB, preventing developers from creating any new element of type compressed_file or using the version label RLS_1.3.

Locks can also be used to retire names, views, and VOBs that are no longer used. For this purpose, the locked objects can be tagged as obsolete, effectively making them invisible to most commands.

Global Types

The ClearCase global type facility makes it easy for you to ensure that the branch, label, attribute, hyperlink, and element types they need are present in all VOBs your project uses. The Administrator's Guide for Rational ClearCase and the Administrator's Guide for Rational ClearCase LT have more information about creating and using global types.

Generating Reports

ClearCase creates and stores an event record each time an element is modified or merged. Many ClearCase commands include selection and filtering options that you can use to create reports based on these records. The scope of such reports can cover a single element, for a set of objects, or for entire VOBs.

Chapter 12, Implementing Project Development Policies, provides more detail on using event records and metadata to implement project policies. Event records and other metadata can also be useful if you need to generate reports on activities managed by ClearCase (for example, the complete history of changes to an element). ClearCase provides a variety of report-generation tools. For more information on this topic, see the fmt_ccase reference page in the Command Reference.