The Base VersionVault process
When you use base VersionVault, the flow of project management tasks follows a path that is similar to that of using UCM to manage a project.
- Project managers set up the project environment.
Setting up the project environment involves the following tasks:
- Create and populate the VOBs.
As a project manager, you are responsible for creating and populating the databases, called VOBs, with the initial collection of file and directory elements.
- Define the branching strategy.
The branching policy is influenced by the development objectives of your project and provides a mechanism to control the evolution of the code base.
A branch represents a linear sequence of versions of one element. Every element has one main branch. In other words, elements contain branches; branches contain versions.
Branches may have one or more subbranches. A subbranch can be used for different lines of development. For example, you can decide to use the main branch for new development work, and a subbranch for defect fixing. Subbranches can also have subbranches.
You also establish naming conventions for branch names to facilitate identifying the type of changes the branches contain. For example, the name rel2.1_main identifies the branches that contain all the code for release 2.1 of your product.
A typical branching strategy is to create an integration branch and multiple development branches. Developers do their work on development branches and then merge their changes to the integration branch so other team members can see them.
Development branches can be per-developer or per-task.
- Create shared views and standard config specs.
As a project manager you will want to control how branches are created when developers check out files. To do this, you create a set of rules for developers. This set of rules is referred to as a config spec.
You also create a view that developers will share. It is a good strategy to provide an integration view for developers to use when they check in work that has evolved in isolation on a private branch.
When using HCL VersionVault on Windows, you may decide to use the View Profiles mechanism to configure views that your project team will use. Using View Profiles promotes a specific model for the effective use of HCL VersionVault.
- Make recommendations for view names.
You may want to establish naming conventions for views to make it easier to associate a view with the task it is used for. Although the GUI-based view-creation tools suggest appropriate names, you may want to use something different. For example, you can require that all view names, called view tags, include the owner's username and the task, such as bsmith_v4.0_bugfix.
- Create and populate the VOBs.
- Project managers implement development policies.
To enforce development policies, you can create metadata to preserve information about the status of the versions, such as labels, attributes, hyperlinks, triggers and locks.
- Define labels.
A label is a user-defined name that can be attached to a version. Using labels is a powerful mechanism. For example, by applying labels you can define and preserve the relationship of a set of file and directory versions at a given point in time in the development lifecycle.
- Define attributes.
Attributes are name/value pairs that let you capture information about the state of a version from various perspectives. For example, you can attach an attribute name CommentDensity to each version of a source file to indicate how well the code is commented, and each attribute can have the value of unacceptable, low, medium, or high.
- Use hyperlinks.
Hyperlinks let you identify and preserve relationships between elements in one or more VOBs. For example, hyperlinks can be used to link a source file to a requirements document.
- Use triggers.
Triggers let you control the behavior of cleartool commands and HCL VersionVault operations by running a specific program or executable script before or after the command runs.
- Use locks.
A lock on an object prevents all developers from modifying it. Locks are useful for implementing temporary restrictions, for example, during an integration period. Locks can also be used to retire objects, such as metadata, elements and VOBs, that are no longer used.
- Define labels.
- Define global types.
This facility makes it easy to ensure that the branch, label, attribute, hyperlink, and element types the global types need are present in all the VOBs your project uses.
- Establish a merging policy.
During the lifetime of a project, the contents of individual elements diverge as they are branched and usually converge in a merge operation. As a project manager you must establish merge policies for your project.
A typical policy is to require developers to merge from the integration branch to their development branch before merging their work into the integration branch.
- Development is ongoing.
Developers do their work on development branches so that their changes do not affect other developers.
- Developers merge work to the integration branch.
When developers complete their work, they build and test their work on their development branch. When their work builds successfully on their development branch, they share their work with the project team by merging it to the integration branch.
- Release engineering builds the product.
Periodically, the delivered work from developers is integrated by building the project's executable files in the integration branch. This work is typically done by an individual in the development group who is assigned to build the product.
- Project managers label the source files.
Project managers label the source files that went into the successful build.
- Developers merge the labeled sources to their development
branches.
Developers merge from the integration branch to their development branches, or adjust their config spec to pick up the labeled versions on the integration branch.