Just last week, the BACCIUG met and had a presentation on UCM. When it
came to questions, I think this one was the most often asked. In
general it seemed that most people where thinking on how to further slow
down the delivery process...
The Rational representatives commented that they plan to generalize the
pull model pretty soon, perhaps even in 4.1.
Meanwhile, I would like to use this occasion to argue for perhaps thinking
the other way - how to speed up delivery and propagation of delivery.
>From a strict control perspective, it makes sense to make delivery as hard
as possible, but from an overall efficiency point of view, you must
consider how badly other developers need the changes that are waiting to
be delivered.
Postponing delivery can slow down development by a lot, as developers wait
for prerequisites before starting their own changes, or as developers have
to resolve complex merges arising because developers got a "head start"
over some changes that turn out to be prerequisites.
ClearCase savy developers of course have the option of merging in changes
awaiting delivery prior to the delivery, but then must contend with
possibly invalid code if the delivery is rejected....
It is this stuff that really makes CM hard to do...
-- cgOn Tue, 22 Feb 2000 Dan.Rickhoff@centigram.com wrote:
> > CCIUG, > > QUESTION: > How can we force UCM to allow only "pull" deliveries to the UCM project's > integration stream? > > One Possible ANSWER: > Use MultiSite to set up a (virtual) site where every project stream (and > its associated branch) is mastered, but at which no development streams are > mastered. > > BACKGROUND: > We are planning to use MultiSite to replicate VOBs between our two > geographically separated sites, San Jose and Rockville, Maryland. We are > also planning to use ClearCase 4.0's Unified Change Management (UCM) at > both sites. > > Consider a particular UCM project whose integration stream (and hence its > associated branch) is mastered at one of the sites, say San Jose. Because > of that mastership, Rockville's developers working on that project cannot > checkin to the project's branch. UCM provides for this case: when a > Rockville developer begins a "deliver" activity, UCM immediately "posts" > that delivery activity for completion by someone at the San Jose site, > i.e., by someone who can actually checkin to the UCM project's branch. > The UCM manuals indicate that the intention is that the "someone" is a > privileged user, either the project's designated integrator or the Release > Administrator. > > As a Release Administrator, I like this. The developers don't decide what > gets checked in on the UCM project's integration branch (its "main" > branch). I perform the checkins, so I can police what gets "delivered". > (Of course, I'm expecting that the developer will have already successfully > "rebased" to the LATEST code set on the project's integration branch. > Thus, the work of the delivery activity consists of accepting trivial > merges.) > > However, employing out-of-the-box UCM, any of San Jose's developers who are > working on the same UCM project can checkin to the project's San > Jose-mastered project-integration branch. When a San Jose developer begins > a "delivery" operation, he/she is not even offered the option to "post" > that delivery activity for completion by someone else (a designated > integrator). UCM nicely guides the developer through the merge from the > developer's development branch to the UCM project's integration branch. > The developer checks in as he/she pleases. > > What's that?!! Developers deciding what gets checked into the project's > integration branch (its "main" branch)!!!. As a Release Administrator, I > don't like that. > > One possible solution: Use MultiSite to set up a (virtual) site where > every project stream (and its associated branch) is mastered, but at which > no development streams are mastered. Thus, whenever a developer initiates > a "delivery" activity, UCM will automatically "post" that activity (the > merge) to someone at the site where the project stream is mastered. We > establish procedures for designating who, at the virtual site, can take up > those delivery activities. > > I'm not necessarily going to implement this "solution". I'd be interested > in the thoughts of other CCIUGers. > > Dan > > Dan Rickhoff > Centigram Communications Corp. > 91 East Tasman Drive > San Jose, CA 95134 > Tele: 408 432-2764 > Fax: 408 428-3827 > > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > > > http://clearcase.rational.com/cciug/mailing_list.html >
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 00:23:23 EDT