16.2 Development Strategy

This section describes the ClearCase issues to be resolved before development begins.

Project Manager and ClearCase Administrator

In most development efforts, the project manager and the system administrator are different people. The user name of the project manager is meister. The administrator is the vobadm user, who creates and owns the monet and libpub VOBs.

Use of Branches

In general, different kinds of work is done on different branches. The Release 1.0 bug fixes, for example, are made on a separate branch to isolate this work from new development. The FIX team can then create patch releases that do not include any of the Release 2.0 enhancements or incompatibilities.

Because the MIN team will produce the first baseline release on its own, the project manager gives the main branch to this team. The MAJ team will develop new features on a subbranch, and will not be ready to integrate for a while; the FIX team will fix Release 1.0 bugs on another subbranch and can integrate its changes at any time.

Each new feature can be developed on its own subbranch, to better manage integration and testing work. For simplicity, this chapter assumes that work for new features is done on a single branch.

The project manager has created the first baseline from versions on the main branches of their elements. But this is not a requirement; you can create a release that uses versions on any branch, or combination of branches.

Figure 51 shows the evolution of a typical element during Release 2.0 development, and indicates correspondences to the overall project plan (Figure 50).

Figure 51 Development Milestones: Evolution of a Typical Element

Creating Project Views

The MAJ team works on a branch named major and uses this config spec:

The MIN team works on the main branch and uses the default config spec:

The FIX team works on a branch named r1_fix and uses this config spec:

For the MAJ and FIX teams, use of the auto-make-branch facility in Rule (3) and Rule (4) enforces consistent use of subbranches. It also relieves developers of the task of creating branches explicitly and ensures that all branches are created at the version labeled R1.0.