|
|
Baseline 2 has been released internally, and further testing has found only minor bugs. These bugs have been fixed by creating new versions on the main branch (Figure 57).
Figure 57 Final Test and Release
Before it is shipped to customers, the monet application goes through a validation phase:
All editing, building, and testing is restricted to a single, shared view.
All builds are performed from sources with a particular version label (R2.0).
Only the project manager has permission to make changes involving that label.
All labels must be moved by hand.
Only high-priority bugs are fixed, using this procedure:
The project manager authorizes a particular developer to fix the bug, by granting her permission to create new versions (on the main branch).
The developer's checkin activity is tracked by a ClearCase trigger.
After the bug is fixed, the project manager moves the R2.0 version label to the fixed version and revokes the developer's permission to create new versions.
In a view with the default config spec, the project manager creates the R2.0 label type and locks it:
cleartool mklbtype -c "Release 2.0" R2.0@\monet R2.0@\libpub
Created label type "R2.0".
Created label type "R2.0".
cleartool lock -nusers meister lbtype:R2.0@\monet lbtype:R2.0@\libpub
Locked label type "R2.0".
Locked label type "R2.0".
The project manager labels the \main\LATEST versions throughout the entire monet and libpub development trees:
cleartool mklabel -recurse R2.0 \monet \libpub
<many label messages>
During the final test phase, the project manager moves the label forward, using mklabel -replace, if any new versions are created.
At this point, use of the main branch is restricted to a few users: those who performed the merges and integration leading up to Baseline 2 (see Merging from the major Branch). Now, the project manager asks vobadm to close down the main branch to everyone except himself, meister:
Z:\> cleartool lock -replace -nusers meister brtype:main
Locked branch type "main".
The main branch is opened only for last-minute bug fixes (see Fixing a Final Bug.)
The project manager creates a new shared view, r2_vu, that is configured with a one-rule config spec:
Z:\> cleartool mkview -tag r2_vu \\nt_svr\public\integ_r2.vws
Created view.
Host-local path: nt_srv:c:\public\integ_r2.vws
Global path: \\nt_srv\public\integ_r2.vws
Z:\> cleartool edcs -tag r2_vu
element * R2.0
This config spec guarantees that only properly labeled versions are included in final validation builds.
The project manager places a trigger on all elements in the monet and libpub VOBs; the trigger fires whenever a new version of any element is checked in. First, he creates a script that sends mail (for an example script, see Notify Team Members of Relevant Changes).
Then, he asks vobadm to create an all-element trigger type in the monet and libpub VOBs, specifying the script as the trigger action:
cleartool mktrtype -nc -element all -postop checkin -brtype main ^
-exec "ccperl \\neon\scripts\notify_manager.pl" r2_checkin@\monet r2_checkin@\libpub
Created trigger type "r2_checkin".
Created trigger type "r2_checkin".
Only the VOB owner or a member of the ClearCase administrators group can create trigger types.
This section demonstrates the final validation environment in action. Developer arb discovers a serious bug and requests permission to fix it. The project manager grants her permission to create new versions on the main branch, by having vobadm enter this command.
Z:\> cleartool lock -replace -nusers arb,meister brtype:main
Locked branch type "main".
arb fixes the bug in a view with the default config spec and tests the fix there. This involves creating two new versions of element prs.c and one new version of element opt.c. Each time arb uses the checkin command, the r2_checkin trigger sends mail to the project manager. For example:
Subject: Checkin \monet\src\opt.c by arb
\monet\src\opt.c@@\main\9
Checked in by arb.
Comments:
fixed bug #459: made buffer larger
When regression tests verify that the bug has been fixed, the project manager revokes arb's permission to create new versions. Once again, the command is executed by vobadm:
Z:\> cleartool lock -replace -nusers meister brtype:main
Locked branch type "main".
The project manager then moves the version labels to the new versions of prs.c and opt.c, as indicated in the mail messages. For example:
Z:\> cleartool mklabel -replace R2.0 z:\monet\src\opt.c@@\main\9
Moved label "R2.0" on "prs.c" from version "\main\8" to "\main\9".
After the labels have been moved, developers rebuild the monet application again, to verify that a good build can be performed using only those versions labeled R2.0.
When the final build in the r2_vu passes the final test, Release 2.0 of monet is ready to ship. After the distribution medium has been created from derived objects in the r2_vu, the project manager asks the ClearCase administrator to clean up and prepare for the next release:
The ClearCase administrator removes the checkin triggers from all elements by deleting the all-element trigger type:
cleartool rmtype trtype:r2_checkin@\monet trtype:r2_checkin@\libpub
Removed trigger type "r2_checkin".
Removed trigger type "r2_checkin".
The ClearCase administrator reopens the main branch:
cleartool unlock brtype:main
Unlocked branch type "main".
|
|
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |
