Base ClearCase consists of a set of powerful tools to establish an environment in which developers can work in parallel on a shared set of files, and project managers can define policies that govern how developers work together.
UCM is one prescribed method of using ClearCase for version control and configuration management. UCM is layered on base ClearCase. Therefore, it is possible to work efficiently in UCM without having to master the details of base ClearCase.
UCM offers the convenience of an out-of-the-box solution; base ClearCase offers the flexibility to implement virtually any configuration management solution that you deem appropriate for your environment.
Base ClearCase uses branches to enable parallel development. A branch is an object that specifies a linear sequence of versions of an element. Every element has one main branch, which represents the principal line of development, and may have multiple subbranches, each of which represents a separate line of development. For example, a project team may use the main branch for new development work while using a subbranch simultaneously for fixing a bug.
Subbranches can have subbranches. For example, a project team may designate a subbranch for porting a product to a different platform. The team may then decide to create a bug-fixing subbranch off that porting subbranch. Base ClearCase allows you to create complex branch hierarchies. Figure 1 illustrates a multilevel branch hierarchy. As a project manager in such an environment, you need to ensure that developers are working on the correct branches. Developers work in views. A view is a work area for developers to create versions of elements. Each view includes a config spec, which is a set of rules that determines which versions of elements the view selects.
Figure 1 Branching Hierarchy in Base ClearCase
As project manager, you tell developers which rules to include in their config specs so that their views access the appropriate set of versions.
UCM uses branches also, but you do not have to manipulate them directly because it layers streams over the branches. A stream is a ClearCase object that maintains a list of activities and baselines and determines which versions of elements appear in a developer's view. In UCM, a project contains one integration stream, which records the project's shared set of elements, and multiple development streams, in which developers work on their parts of the project in isolation from the team. The project's integration stream uses one branch. Each development stream uses its own branch. You can create a hierarchy of development streams, and UCM creates the branching hierarchy to support those streams.
As project manager of a UCM project, you need not write rules for config specs. Streams configure developers' views to access the appropriate versions on the appropriate branches.
As the number of files and directories in your system grows, you need a way to reduce the complexity of managing them. In UCM you use components to simplify the organization of your files and directories. The elements that you group into a component typically implement a reusable piece of your system architecture. By organizing related files and directories into components, you can view your system as a small number of identifiable components, rather than one large set of directories and files.
Both base ClearCase and UCM allow you to create baselines. UCM automates the creation process and provides additional support for performing operations on baselines. A baseline identifies the set of versions of files that represent a project at a particular milestone. For example, you may create a baseline called beta1 to identify an early snapshot of a project's source files.
Baselines provide two main benefits:
The ability to reproduce an earlier release of a software project
The ability to tie together the complete set of files related to a project, such as source files, a product requirements document, a documentation plan, functional and design specifications, and test plans
In base ClearCase, you can create a baseline by creating a version label and applying that label to a set of versions.
In UCM, baseline support appears throughout the user interface because UCM requires that you use baselines. When developers join a project, they must first populate their work areas with the contents of the project's recommended baseline. This method ensures that all team members start with the same set of shared files. In addition, UCM lets you set a property on the baseline to indicate the quality level of the versions that the baseline represents. Examples of quality levels include "project builds without errors," "passes initial testing," and "passes regression testing." By changing the quality-level property of a baseline to reflect a higher degree of stability, you can, in effect, promote the baseline.
In base ClearCase, you work at the version and file level. UCM provides a higher level of abstraction: activities. An activity is a ClearCase object that you use to record the work required to complete a development task. For example, an activity may be to change a graphical user interface (GUI). You may need to edit several files to make the changes. UCM records the set of versions that you create to complete the activity in a change set. Because activities appear throughout the UCM user interface, you can perform operations on sets of related versions by identifying activities rather than having to identify numerous versions.
Because activities correspond to significant project tasks, you can track the progress of a project more easily. For example, you can determine which activities were completed in which baselines. If you use the UCM-ClearQuest integration, you gain additional project management control, such as the ability to assign states and state transitions to activities. You can then generate reports by issuing queries such as "show me all activities assigned to Pat that are in the Ready state."
A key part of managing the configuration management aspect of a software project is establishing and enforcing development policies. In a parallel development environment, it is crucial to establish rules that govern how team members access and update shared sets of files. Such policies are helpful in two ways:
They minimize project build problems by identifying conflicting changes made by multiple developers as early as possible.
They establish greater communication among team members.
These are examples of common development policies:
Developers must synchronize their private work areas with the project's recommended baseline before delivering their work to the project's shared work area.
Developers must notify other team members by e-mail when they deliver work to the project's shared work area.
In base ClearCase, you can use tools such as triggers and attributes to create mechanisms to enforce development policies. UCM includes a set of common development policies, which you can set through the GUI or command-line interface (CLI). You can set these policies at the project and stream levels. In addition, you can use triggers and attributes to create new UCM policies.
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |