Highley Recommended, Inc.

NAVIGATIONENGINEERING POLICIES

CM Home
CM Resources
Getting Started
Config. Spec.
CM Procedures
Scripts
Triggers
CM Plan
ClearCase Best Practices
Merging
ClearCase FAQ

Reference Documents

ClearCase User's Manual
The Capability Maturity Model - Section 7.6, Software Configuration Management (SEI)
Software Configuration Management Plan
ClearCase Basics
ClearCase Best Practices

Tools

Configuration Management for our products will use Rational´s ClearCase product. Builds will be done using Clearmake, or, in the case of emergency Gnu Make (with -force flag enabled). All tools critical for development (compilers, etc.) will be kept under configuration control as detailed in the Software Configuration Management Plan.

Roles and Responsibilities

Configuration Manager - Writes and updates CM-Procedure on a per project basis, implements procedures as needed using the tools described.

Software Engineering Manager - Enforces procedures, makes decisions to release, updates team on project status.

Developers - Follow established procedures, make recommendations to Configuration Manager for process improvement.

DVT - Follow established procedures, make recommendations to Configuration Manager for process improvement.

Development Procedure

For the purposes of this document we will consider development in two phases; initial development and verification bug fixes.

Initial Development - During the initial development phase, all activity will occur off of a "project branch". For the first release of the product this project branch is called "release1". Developers will individually branch to add their code, or will work jointly on feature level branches.

Anyone may check in code to a project branch, however, certain responsibility to not break the build is assumed by engineers checking in code to this branch. It is recommended that prior to checking in files to the branch, the developer test the build with the latest code on the project branch.

Labels are the responsibility of the engineers at this point. If an "official" build is required, the Configuration Manager will label and test the build, and check it into the release branch where it will be made available to DVT.

Developers have the responsibility to follow our ClearCase Best Practices.

Verification Bug Fixes - After the decision to release is made, the project branch is merged into the Main branch. As needed, "bug-fix branches" may be created off the main branch, with the name of the problem report that they are fixing, for instance:

pr_0456

The developer responsible for the bug fix will merge the bug-fix branch back into the main branch, but will not complete the merge by checking the files in.The developer will 'resolve' the problem report in PR-tracker before sending a report to the configuration manager with the following information:

  1. The problem report that has been fixed.
  2. The names of the files that were editted to fix this problem.
  3. The name of the bug fix branch.
  4. The name of the view in which the files were merged.

The configuration manager will then check in the files and update the problem report with the correct version number. A build will be run after all the files are checked in. This build will be labeled with a correct release label. The object files will be checked into the "\release" VOB and the release will be announced to DVT for testing.