clearcase build cycle analogy?

Currently we are using clearcase for our source management.

We have a child stream off of integ for stabilization, with everyone
deliverying changes to integ.

Every now and then we strike a baseline in the integ and rebase the
stabiliation(stab) stream to that unrecommended baseline, build test and
try to stabilize this build.

When satisfied we strike another baseline, deliver the baseline to
integ, and recommend that baseline.

this way developers are basing their changes off of "sanctioned" builds
instead of whatever happens to be in integ.


Is there any analogy to this cycle in jazz?

You can create 3 streams, stable integration, unstable integration and
stabilization.

You normally deliver to unstable integration. Every once in a while you
create a baseline from what's in unstable integration and deliver it to
stabilization. Then you stabilize the build in stabilization. When it is
stable you create another baseline and deliver it to stable integration.

- Dmitry

On Fri, 24 Oct 2008 19:17:56 +0000, ddumont wrote:

That sounds alot more complex than in UCM. It seems it would be hard for
developers to just keep their work based off stable builds without
having to sift through all the incoming changes that happen during a
stabilization...

How so? They can just always accept from Stable Integration, then they
will always have the stable builds.

Perhaps I'm not yet familiar enough with the Jazz workspace...

I see a pending changes view and it contains everything delivered to the
stream i'm working on.

You can change which stream you're working with by changing the flow
target.

- Dmitry

That sounds alot more complex than in UCM.
It seems it would be hard for developers to just keep their work based off stable builds without having to sift through all the incoming changes that happen during a stabilization...


Unless I'm misunderstanding....

Is such a process even necessary in jazz?
I've started looking at the process definitions where you can assign special permissions for certain phases of a process...

Do most projects just have a free-for-all development phase followed by a single-submitter stabilization phase?

Perhaps I'm not yet familiar enough with the Jazz workspace...

I see a pending changes view and it contains everything delivered to the stream i'm working on.

ddumont wrote:

Currently we are using clearcase for our source management.

We have a child stream off of integ for stabilization, with everyone
deliverying changes to integ.

Every now and then we strike a baseline in the integ and rebase the
stabiliation(stab) stream to that unrecommended baseline, build test
and try to stabilize this build.

When satisfied we strike another baseline, deliver the baseline to
integ, and recommend that baseline.

this way developers are basing their changes off of "sanctioned"
builds instead of whatever happens to be in integ.

The problem with that approach is that developers are delivering their
changes into an integration stream that contains activities (a.k.a.
change sets) that are not visible in their own development stream.
There is no easy way for them to test their own changes against those
unrecommended changes before delivering.

By not allowing developers to integrate their changes before delivering,
you are essentially guaranteeing that the integration stream will be
broken from time to time. Since integration can't happen at delivery
time, it needs to happen in the separate stabilization stream.

Is there any analogy to this cycle in jazz?

Rather than trying to recreate this in Jazz, I suggest working on
eliminating the need for the stabilization stream. Insist that
developers never break the integration stream, that their changes are
fully integrated before delivering.

One tool that Jazz provides that really, really helps with this is
personal builds. Personal builds allow developers to run an official
build using the contents of their own repository workspace rather than
the contents of the integration stream. If a developer has accepted all
incoming changes into his workspace and run a successful personal build,
then he can be quite confident that delivering all of his outgoing
changes will not break the integration stream.

The approach David describes is preferable when it is feasible, but a
stabilization stream might be necessary when it takes many hours to run
the build that verifies the stability of the configuration. In this
case, by the time a developer has run his private stabilization build,
some other developer has already delivered their changes to the
integration stream, invalidating the private stabilization build.

In general, Jazz SCM is designed to be flexible enough to support
whatever change flow you want happen to want.

Note, though, that some change flow patterns have better GUI support
than others. For example, in the stabilization stream scenario, the
Jazz SCM GUI does not yet allow you to declare that a particular flow
target is "incoming only" or "outgoing only". So in the stabilization
stream case (where you accept from the stabilization stream but deliver
to the integration stream), you either have to keep switching your
current flow target (in the default "single target" mode of the GUI), or
you have to be careful to only do delivers and accepts from the right
streams (in the optional "multiple target" mode of the GUI). A workitem
was posted a while ago to add support for declaration of incoming-only
and outgoing-only flow targets.

Cheers,
Geoff

David Olsen wrote:

ddumont wrote:
Currently we are using clearcase for our source management.

We have a child stream off of integ for stabilization, with everyone
deliverying changes to integ.

Every now and then we strike a baseline in the integ and rebase the
stabiliation(stab) stream to that unrecommended baseline, build test
and try to stabilize this build.

When satisfied we strike another baseline, deliver the baseline to
integ, and recommend that baseline.

this way developers are basing their changes off of "sanctioned"
builds instead of whatever happens to be in integ.

The problem with that approach is that developers are delivering their
changes into an integration stream that contains activities (a.k.a.
change sets) that are not visible in their own development stream. There
is no easy way for them to test their own changes against those
unrecommended changes before delivering.

By not allowing developers to integrate their changes before delivering,
you are essentially guaranteeing that the integration stream will be
broken from time to time. Since integration can't happen at delivery
time, it needs to happen in the separate stabilization stream.

Is there any analogy to this cycle in jazz?

Rather than trying to recreate this in Jazz, I suggest working on
eliminating the need for the stabilization stream. Insist that
developers never break the integration stream, that their changes are
fully integrated before delivering.

One tool that Jazz provides that really, really helps with this is
personal builds. Personal builds allow developers to run an official
build using the contents of their own repository workspace rather than
the contents of the integration stream. If a developer has accepted all
incoming changes into his workspace and run a successful personal build,
then he can be quite confident that delivering all of his outgoing
changes will not break the integration stream.

In our case we can't do it the preferred way.

Our source is javascript, and our build will tell us nothing about how the product actually works, we have to pass it through a smoke bvt to catch the common stuff. missing semi-colons... etc..