Rational ClearCase UCM
This article includes a list of references, related reading or external links, but its sources remain unclear because it lacks inline citations. (July 2006) (Learn how and when to remove this template message)
UCM is activity based. The activity object is the basis for sharing information between ClearCase and ClearQuest. In ClearQuest, the activity presents itself as a task on the developers “to do list” query. In ClearCase, the activity connects the task with the actual files that need to be changed in order to accomplish the task (the change set). A new baseline consists of the old baseline plus all checked-in activities to date. By looking at the change sets of those activities, it is possible to know every file that was touched in order to arrive at a new baseline.
UCM is also component-based. Units of code that are developed and built together can be kept isolated until time to integrate with the full codeline. Each UCM component can have its own recommended baseline. A set of component baselines can be used to define the fully integrated main product baseline (composite baseline)
UCM is also project-based. Each codeline can have its own custom set of development policies and can spawn new projects by using its final baseline as a jumping off point for future development.
UCM is a layer built on Rational ClearCase to provide additional software configuration management features. These changes include integration with ClearQuest to enforce defect and change tracking with code development through the use of activities. This is part of the Rational Unified Process that describes the lifecycle of change management for IBM Rational's software development process. It also gives integrators ownership of projects and streams to allow policy and feature management by project leaders and release engineers. UCM removes the ability/requirement that users manage a configuration specification for a view. UCM is used and configured via either CLIs or GUIs.
Project Versioned Object Bases store UCM metadata. All UCM structures reside in PVOBs. All the metadata types such as projects, streams, activities, and baselines will be stored in Project VOBS.
Projects group similar components into a code base used to build software. Project policies can be applied to enforce a process for users working within the project.
One or more components can be configured per base ClearCase VOB. A component can be a part of multiple projects and streams, allowing for code reuse.
Streams are created within a project to allow users to work on content simultaneously in isolated environments within views. Code changes are integrated from one stream to another analogously to branches in base ClearCase. A stream also allows for development of several simultaneous releases of a product to take place.
A baseline is applied to a set of components within a stream and serves analogously to labels in base ClearCase. Streams are configured with the help of Baselines, which act as a foundation or root layer for the stream's configuration in UCM clearcase. The baseline holds the UCM Activities. Baselines apply the label on the versions.
A recommended baseline is a set of versions that have been identified as stable. This baseline establishes the current starting point for the project; when a developer rebases or joins a project, this is the baseline that is used as the foundation for the development stream, unless he specifies a different baseline to be used.
Composite baselines are a mechanism for grouping baselines into a collection. One baseline is designated as the composite, and other baselines become members of the composite.
Types of baselines :
- A full baseline is a baseline that you create by recording all versions of all elements below the component's root directory.
- An incremental baseline is a baseline that you create by recording the last full baseline and those versions of elements that have changed since the last full baseline was created.
An element is anything that is checked into ClearCase. Here are some examples of elements: source files, directories, ant build files, make files, text files, and html files.
Element versions can be grouped into an activity change set. An activity can be enforced with ClearQuest checking criteria to allow tight integration of defect tracking with code development.