Brad,
RE: Your reply to my email to CCIUG about use of UCM's "projects".
Thanks for your ideas on how to use ClearCase (CC) 4.0's Unified Change
Management's (UCM) projects. I'll keep your advice in mind as we press on
with UCM. As I said, we've just started to prototype it use.
Yes, Rational's CC 4.0 manual's do, ever so briefly, touch on creating a
UCM "project" that essentially has sub-projects, each of which is itself a
UCM "project". However, they did not explain it or automate it "in a
straightforward way". Even for project-to-project merges, they only
provide some quick and dirty scripts that the user can be modify to
facilitate the project-to-project merges. Thinking optimistically, I
figured that implied that a later CC release would provide more
user-friendly mechanisms to create a shallow hierarchy of UCM projects. I
also figured that it implied that Rational didn't want to lead me into
making a mess of things by using this initial release of UCM to fake out a
project hierarchy.
NOTE: After having read the UCM-related portions of the ClearCase manuals,
I'm very impressed by UCM and I'm very enthusiastic about using it.
I agree with your set of criteria for identifying what to use a project
for. Additionally, I find that the things that I identify as a "project"
are "coherent group of change-activities" that pack tightly into one
overall project schedule. The life spans of the project's activities and
the activities principal milestones are all closely related. In fact, so
far, I'm finding that I weight this "shared-schedule" criterion at about a
9 out of 10, and that the combined weights of all other criteria are only
about 1 out of 10. My "shared-schedule" criterion is probably functionally
the same as your criterion that "all (activities are) performed toward the
same purpose and end-result". However, as guide to identifying a
"project", I prefer to think "schedule", rather than "purpose".
You also made some good corrections to my use of the term "activity". I
definitely need to re-visit the related manual sections. You correctly
pointed out that:
You could conceivably have a stream-per-developer and each developer
might use
their stream to develop and deliver more than one activity.
In fact, straightforward use of UCM will almost certainly result in a
developer using his/her development stream for more than one atomic
activity, and probably working on them in parallel. I like that design.
Even though their development view will hold versions that they've modified
in support of several activities, ClearCase sorts out (and records) the
"change" set for each activity. Nice. I said "parallel", but note that
that doesn't mean "and at the same time". The developer's modifications to
any one version (checkout-modify-checkin) should (from a Release Engineer's
standpoint) all be for one, and only one, of the activities that they're
using their development view to work on. You can't "set" to more than one
activity at a time, which is probably as it should be.
Thanks,
Dan
Dan Rickhoff
Centigram Communications Corp.
91 East Tasman Drive
San Jose, CA 95134
Tele: 408 432-2764
Fax: 408 428-3827
From: Brad Appleton <bradapp@enteract.com> on 02/03/2000 04:34 AM GMT
Please respond to Brad Appleton <bradapp@enteract.com>
To: ClearCase Users Group <cciug@Rational.Com>
cc: (bcc: Dan Rickhoff/US/Centigram)
Subject: Re: [cciug] UCM process - Use of "projects"?
On Wed, Feb 02, 2000 at 05:36:28PM -0800, Dan.Rickhoff@centigram.com wrote:
> We've just started thinking about how to use ClearCase 4.0's Unified
Change
> Management (UCM) to manage our "procces". One of the first questions
that
> comes up is: How should we use UCM's "project" objects.
Use a project to organize any coherent group of change-activities
all performed toward the same purpose and end-result *and* which
require frequent integration/coordination that demands multiple
baselines/baselevels be created.
If you only need one baseline/baselevel at the end, you can get away
with a single development stream. If, sometime between the completion of
the first activity and the last activity there is going to be parallel
effort with concurrent access to one or more files and/or a need to
create intermediate named stable configurations (baselines or baselevels)
then use a project.
So go right ahead and use a project for organizing work towards a major
release, and/or for a major feature or feature-set and/or for a specific
point release, or for a formally specified work contract, and/or for
any number of things.
UCM *does* in fact currently support the notion of projects having
subprojects - which is exactly what you seem to want. Granted the support
is not yet full-blown, but the first release of UCM does support the
notion of a follow-on project (a kind of subproject) and also supports
inter-project rebase operations from the parent project integration stream
to the follow-on project integration stream. It does not (yet) support
inter-project delivery from the child int-stream to the parent int-stream,
but this is easily done by hand with findmerge and/or the merge-manager
when it's time to resync or retire a subproject into its parent.
Hence there is no restriction to using only one level of projects in
your hierarchy, hence no need to be forced to use lone streams for all
subprojects. You can use bona-fide projects for subprojects and rebase
a child stream from its parent, but you do need to hand-deliver form
the parent back to the child (which really isn't that difficult).
> If, in a straightforward way, UCM provided us a hierarchy of "projects",
It does indeed provide the ability to create such a hierarchy.
> then every "activity" above would be a UCM "project".
Well - except for the bottom level activities, which would be activities.
Perhaps the 2nd from the bottom could be development streams or activities
at your discretion (or they could be subprojects too if you wish).
> To save ourselves from ourselves, UCM offers (in a straightforward way)
> only two levels of "activities":
Don't equate UCM streams with UCM activities. streams and activities
are very different but closely related things. A stream may be used for
a single activity, or it may be used for several activities. You could
conceivably have a stream-per-developer and each developer might use
their stream to develop and developer more than one activity.
But development streams don't allow parallelism, they can only be used
for one activity at a time. So a stream can be used to group multiple
sequential activities, but not multiple parallel activities.
Whether you use them for single activities or for multiple sequential
activities is up to you. Anything intended to group multiple parallel
activities should be a full-fledged UCM project, and you can use the
follow-on project mechanism to organize them into a hierarchy.
-- Brad Appleton <bradapp@enteract.com> http://www.enteract.com/~bradapp/ "And miles to go before I sleep." -- Robert Frost - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 00:23:01 EDT