Streams/team areas - help setting up correctly

Create a stream for each distinct "configuration" that needs to be
shared/used by more than one team member.

So in the scenario described below, you'll want Build_1, Build_2, and
Build_3 streams.

Cheers,
Geoff


micjohnson997 wrote:

Hi all,

Just want to make sure I get this right the first time. Here's our
situation. We have several "teams" on a large project that
are responsible for developing "components." We'll call
these Team CA, Team CB, and Team CC (CA
== "component A", etc.) We work on multiple versions of
each of these concurrently, where there are several common
integration points (call them Build 1, Build 2,
etc.

So I am thinking that to set this up correctly, I need to create a
"Team Area" for each team. Good so far.

Next come the streams. What's the best way to configure the streams
to support parallel-version development of multiple components? I
think from everything I have read that this is exactly what RTC/Jazz
handles excellently; I'd just like to see an example (or maybe even
just a published flow diagram?) that gives a good explanation of
what should flow where.

I apologize in advance if the request is muddled -- I am sure you Jazz
folks will come back to me with several questions so that you can
understand what I am trying to do :)

Thanks in advance,
Mike

Geoff,

Thanks! OK, next question then. Let's say we are developing all three builds in parallel. Any changes that occur in build 1 need to be "flowed" to build 2 and 3. Any changes that occur in build 2 need to be flowed to build 3. How would you set this up? Can you set up a stream so that it "flows" to more than one target? (IE, the build 1 stream flows to build 2 and 3?)

Thanks,
Mike

Also, while I was working with this, another thing occurred to me. I have the three teams (Team CA, Team CB, and Team CC). When I go to create the new "build 1" stream, RTC asks me for the Owner of the stream. It really isn't ANY of those teams, since build 1 includes ALL of the components (CA, CB, and CC). Am I missing some kind of top-level team or something? I created my three teams as top levels, so there's nothing else to pick besides those three...

Thanks,
Mike

Flows between streams only occurs via a workspace.
I posted details on how to do so in another thread today (let me know if
you missed that other post).

Cheers,
Geoff

micjohnson997 wrote:

Geoff,

Thanks! OK, next question then. Let's say we are developing all
three builds in parallel. Any changes that occur in build 1 need to
be "flowed" to build 2 and 3. Any changes that occur in
build 2 need to be flowed to build 3. How would you set this up?
Can you set up a stream so that it "flows" to more than one
target? (IE, the build 1 stream flows to build 2 and 3?)

Thanks,
Mike

The significance of the team area that owns the stream is that this
determines who can deliver to the stream. The default behavior for many
processes is that someone with a "contributor" role in a project is
allowed to deliver to a stream. So one thing you could do is to create
a "system" team area (possibly named after the system that comprises CA,
CB, and CC), and have the streams owned by that team area. Then make
all of members of Team CA, Team CB, and Team CC members of that system
team area.

Cheers,
Geoff

micjohnson997 wrote:

Also, while I was working with this, another thing occurred to me. I
have the three teams (Team CA, Team CB, and Team CC). When I go to
create the new "build 1" stream, RTC asks me for the Owner
of the stream. It really isn't ANY of those teams, since build 1
includes ALL of the components (CA, CB, and CC). Am I missing some
kind of top-level team or something? I created my three teams as top
levels, so there's nothing else to pick besides those three...

Thanks,
Mike

Geoff,

Thanks for the info! Now I wish that I could see a flow diagram for RTC. I think your case is probably similar to what I want to accomplish (although I am sure your streaming is more complicated). I did read that description of how to deliver between streams in the other thread, so now here is my next question. In the scenario I describe, there are 3 streams for each of 3 different "builds." I would normally want changesets from build 1 flowed into builds 2 and 3; and there MIGHT be a codefix in 2 or 3 that would need to be flowed to 1, although in most cases, changesets in 2 or 3 would NOT need to be flowed to 1. How do you guys handle this in your RTC development right now? IE, I know you have a 1.0.1 maintenance group, which must flow changes up to 2.0, but you normally don't want stuff from 2.0 flowing to 1.0.1 (although again there might be one or two that do need to be flowed because someone fixed an issue that also shows up in 1.0.1...) Do you just "reject" changesets from flowing back down to your 1.0.1 stream from 2.0? Or is there some way to set up the flowing to say that it's only one way, ie, "up" from 1.0.1 to 2.0?

Thanks,
Mike

I've submitted a workitem a while ago, asking for the ability to declare
the direction of flow. (Feel free to add your support to workitem 33114
:-). Until that enhancement is in place, you just need to be careful.
There is some support for this functionality via the ability to declare
that a particular stream is the "default" target. Anytime you deliver
to a non-default target, you get a warning. So in the example below, in
the workspace that merges changes from 1.0.1 to 2.0, you would declare
2.0 to be the default target. Then if you by mistake tried to deliver
to 1.0.1, it would give you the warning "delivering to non-default
stream" (and give you the option to cancel the request).

Cheers,
Geoff

micjohnson997 wrote:

Geoff,

Thanks for the info! Now I wish that I could see a flow diagram for
RTC. I think your case is probably similar to what I want to
accomplish (although I am sure your streaming is more complicated).
I did read that description of how to deliver between streams in the
other thread, so now here is my next question. In the scenario I
describe, there are 3 streams for each of 3 different
"builds." I would normally want changesets from build 1
flowed into builds 2 and 3; and there MIGHT be a codefix in 2 or 3
that would need to be flowed to 1, although in most cases, changesets
in 2 or 3 would NOT need to be flowed to 1. How do you guys handle
this in your RTC development right now? IE, I know you have a 1.0.1
maintenance group, which must flow changes up to 2.0, but you
normally don't want stuff from 2.0 flowing to 1.0.1 (although again
there might be one or two that do need to be flowed because someone
fixed an issue that also shows up in 1.0.1...) Do you just
"reject" changesets from flowing back down to your 1.0.1
stream from 2.0? Or is there some way to set up the flowing to say
that it's only one way, ie, "up" from 1.0.1 to 2.0?

Thanks,
Mike