The UCM process

When you decide to adopt UCM as the process for your development effort, as a project manager you are in charge of setting up the environment, referred to as the UCM project, and maintaining the shared work areas.

The UCM project is put in place after creating the VOBs that contain the files and directories that make up the development effort.

A UCM project contains one shared work area and typically multiple private work areas.

The shared work area is the data repository, called the VOB, that holds the project's source files. Private work areas allow developers to work in isolation.

When developers are ready to submit their work, they deliver the sources from their private work area to the shared work area. This action makes their contribution to the project accessible to other developers. As a project manager you are responsible for maintaining the project's shared work area.

In a UCM project, work typically progresses as follows:

1. HCL VersionVault administrators create the VOBs.

   HCL VersionVault Administrators create the VOBs that will contain all the files and directories that represent the development effort, such as a new product release.

2. Project managers create the UCM project.

   As project manager, you create a UCM project and identify an initial set of components as a starting point, called a baseline. A component is a group of related directory and file elements, which are developed, integrated, and released together. A baseline represents a version of one or more components.

3. Developers join the UCM project.

   Developers join the project by creating their private work areas and populating them with the contents of the project's baselines.

4. Development is ongoing.

   Developers create, or are assigned, activities, and work on one activity at a time. An activity records a set of files that a developer creates or modifies to complete a development task, such as fixing a bug. The set of files associated with an activity is known as a change set.

5. Developers deliver work to the shared work area.

   When developers complete activities, they build and test their work in their private work areas. When developers create a successful software build in their private work area, they share their work with the project team by performing deliver operations. A deliver operation merges the work from the developer's private work area to the project's shared work area.

6. Release engineering builds the product.

   Periodically, the delivered work from developers is integrated by building the project's executable files in the shared work area. This work is typically done by an an individual in the development group who is assigned to build the product.

7. Project managers create new baselines.

   If the project builds successfully, as a project manager you create a new set of baselines. In a separate work area, a team of Quality Engineers performs more extensive testing of the new baselines.

8. Project managers promote specific baselines that reflect a particular project milestone.

   Periodically, as the quality and stability of baselines improve, as a project manager you adjust the promotion level attribute of the baselines to reflect appropriate milestones, such as Built, Tested, or Released. When the new baselines pass a sufficient level of testing, you designate them as the recommended set of baselines

9. Developers adjust their private work areas to the latest available baselines.

   Developers perform rebase operations to update their private work areas to include the set of versions represented by the new recommended baselines.

   Developers continue the cycle of working on activities, delivering completed activities, and updating their private work areas with new baselines.