RTC Project Areas - many versus few

I am looking at a large zOS shop that has Endevor with approximately 180 subsystems (applications). Looking at the possibility of migrating to RTC3.0 I am looking at a potentially large number of components and of course along with those the streams, dependency build definitions, promotions and package/deploys. Under the eclipse client there is no way that I have seen where you can filter your view so that you only see a subset of streams, builds, promotes etc. if all these artifacts are defined under one RTC project area when a user connects they have a LONG list of items to deal with. I know you can use the "Favorites" folder for some things but not the ones mentioned (correct me if I am wrong).

In the shop I may logically see an organizational grouping that would suggest creating a few RTC project areas but not a lot of them. So for manageability what are the pros/cons for creating a LOT of RTC project areas to the point I may have only a few components and component related artifacts in each rather than a few projects and MANY components and component artifacts?

Hi Donald,

my 2 cents.

Having few projects reduces the administrative overhead. If you can get along with a few projects go for few.

A real need for having multiple project areas starts with

* Requirements for restrictions on read access
* Completely different process definitions e.g. different work item types and workflows

The number of components on a stream should not be too big see http://jazz.net/library/article/205/ 180 are way below the threshold though.

Ralph

I am looking at a large zOS shop that has Endevor with approximately 180 subsystems (applications). Looking at the possibility of migrating to RTC3.0 I am looking at a potentially large number of components and of course along with those the streams, dependency build definitions, promotions and package/deploys. Under the eclipse client there is no way that I have seen where you can filter your view so that you only see a subset of streams, builds, promotes etc. if all these artifacts are defined under one RTC project area when a user connects they have a LONG list of items to deal with. I know you can use the "Favorites" folder for some things but not the ones mentioned (correct me if I am wrong).

In the shop I may logically see an organizational grouping that would suggest creating a few RTC project areas but not a lot of them. So for manageability what are the pros/cons for creating a LOT of RTC project areas to the point I may have only a few components and component related artifacts in each rather than a few projects and MANY components and component artifacts?

So how do you deal with connecting to a project and seeing 180 or so builds to select from or 180 or so promotes, streams etc. Is there anyway to filter the list under eclipse? I would be interested in hearing from someone who is actually dealing with an RTC project that has 100+ components.

Hi Donald,

my 2 cents.

Having few projects reduces the administrative overhead. If you can get along with a few projects go for few.

A real need for having multiple project areas starts with

* Requirements for restrictions on read access
* Completely different process definitions e.g. different work item types and workflows

The number of components on a stream should not be too big see http://jazz.net/library/article/205/ 180 are way below the threshold though.

Ralph

I am looking at a large zOS shop that has Endevor with approximately 180 subsystems (applications). Looking at the possibility of migrating to RTC3.0 I am looking at a potentially large number of components and of course along with those the streams, dependency build definitions, promotions and package/deploys. Under the eclipse client there is no way that I have seen where you can filter your view so that you only see a subset of streams, builds, promotes etc. if all these artifacts are defined under one RTC project area when a user connects they have a LONG list of items to deal with. I know you can use the "Favorites" folder for some things but not the ones mentioned (correct me if I am wrong).

In the shop I may logically see an organizational grouping that would suggest creating a few RTC project areas but not a lot of them. So for manageability what are the pros/cons for creating a LOT of RTC project areas to the point I may have only a few components and component related artifacts in each rather than a few projects and MANY components and component artifacts?

Hi,

A person can filter by team areas, teams he is member of etc.
All artifacts e.g. build definitions will be filtered.

So, instead of creating 180 project areas you would create some and
create teams within.

I have seen a project dealing with 100+ components. They did not have
so many builds however. You could also divide and conquer on streams.
Also you could organize things in folders within the components.

Just some options.

Ralph

dpoulinwrote:
So how do you deal with connecting to a project and seeing 180 or so
builds to select from or 180 or so promotes, streams etc. Is there
anyway to filter the list under eclipse? I would be interested in
hearing from someone who is actually dealing with an RTC project that
has 100+ components.

rschoonwrote:
Hi Donald,

my 2 cents.

Having few projects reduces the administrative overhead. If you can
get along with a few projects go for few.

A real need for having multiple project areas starts with

* Requirements for restrictions on read access
* Completely different process definitions e.g. different work item
types and workflows

The number of components on a stream should not be too big see
http://jazz.net/library/article/205/ 180 are way below the
threshold though.

Ralph

dpoulinwrote:
I am looking at a large zOS shop that has Endevor with approximately
180 subsystems (applications). Looking at the possibility of
migrating to RTC3.0 I am looking at a potentially large number of
components and of course along with those the streams, dependency
build definitions, promotions and package/deploys. Under the eclipse
client there is no way that I have seen where you can filter your
view so that you only see a subset of streams, builds, promotes etc.
if all these artifacts are defined under one RTC project area when a
user connects they have a LONG list of items to deal with. I know you
can use the "Favorites" folder for some things but not the
ones mentioned (correct me if I am wrong).

In the shop I may logically see an organizational grouping that
would suggest creating a few RTC project areas but not a lot of them.
So for manageability what are the pros/cons for creating a LOT of RTC
project areas to the point I may have only a few components and
component related artifacts in each rather than a few projects and
MANY components and component
artifacts?

I agree with Ralph's comments, and in particular, that you should use
multiple team areas whenever possible to partition the streams, instead
of multiple project areas.

WRT number of components, would all 100+ components be included in a
single development workspace? I personally prefer to have more like
30-40 components in a development workspace, rather than 100+, so I
don't have to do so much scrolling in the pending changes view. Note
that I don't mind having a larger number of components in a stream, as
long as I only need 30-40 for my workspace.

Cheers,
Geoff

On 12/16/2010 10:53 AM, rschoon wrote:

Hi,

A person can filter by team areas, teams he is member of etc.
All artifacts e.g. build definitions will be filtered.

So, instead of creating 180 project areas you would create some and
create teams within.

I have seen a project dealing with 100+ components. They did not have
so many builds however. You could also divide and conquer on streams.
Also you could organize things in folders within the components.

Just some options.

Ralph

dpoulinwrote:
So how do you deal with connecting to a project and seeing 180 or so
builds to select from or 180 or so promotes, streams etc. Is there
anyway to filter the list under eclipse? I would be interested in
hearing from someone who is actually dealing with an RTC project that
has 100+ components.

rschoonwrote:
Hi Donald,

my 2 cents.

Having few projects reduces the administrative overhead. If you can
get along with a few projects go for few.

A real need for having multiple project areas starts with

* Requirements for restrictions on read access
* Completely different process definitions e.g. different work item
types and workflows

The number of components on a stream should not be too big see
http://jazz.net/library/article/205/ 180 are way below the
threshold though.

Ralph

dpoulinwrote:
I am looking at a large zOS shop that has Endevor with approximately
180 subsystems (applications). Looking at the possibility of
migrating to RTC3.0 I am looking at a potentially large number of
components and of course along with those the streams, dependency
build definitions, promotions and package/deploys. Under the eclipse
client there is no way that I have seen where you can filter your
view so that you only see a subset of streams, builds, promotes etc.
if all these artifacts are defined under one RTC project area when a
user connects they have a LONG list of items to deal with. I know you
can use the "Favorites" folder for some things but not the
ones mentioned (correct me if I am wrong).

In the shop I may logically see an organizational grouping that
would suggest creating a few RTC project areas but not a lot of them.
So for manageability what are the pros/cons for creating a LOT of RTC
project areas to the point I may have only a few components and
component related artifacts in each rather than a few projects and
MANY components and component
artifacts?

I have prototyped a project with multiple streams, components and
builds and was able to organize them in team areas (development vs
test). The problem is that the team area DOES NOT include links to
enterprise extensions folders so I am not able to include "team
level" promotions, package or deploys. The zOS shops that build
at development and then promote to test and then promote to QA and
then deploy - all based on dependency builds where promotion is by
component will have to deal with a long list of promotion definitions
instead of just the ones connected to their team. Any thoughts?

gmclemmwrote:
I agree with Ralph's comments, and in particular, that you should use

multiple team areas whenever possible to partition the streams,
instead
of multiple project areas.

WRT number of components, would all 100+ components be included in a

single development workspace? I personally prefer to have more like

30-40 components in a development workspace, rather than 100+, so I

don't have to do so much scrolling in the pending changes view.
Note
that I don't mind having a larger number of components in a stream,
as
long as I only need 30-40 for my workspace.

Cheers,
Geoff

On 12/16/2010 10:53 AM, rschoon wrote:
Hi,

A person can filter by team areas, teams he is member of etc.
All artifacts e.g. build definitions will be filtered.

So, instead of creating 180 project areas you would create some and
create teams within.

I have seen a project dealing with 100+ components. They did not
have
so many builds however. You could also divide and conquer on
streams.
Also you could organize things in folders within the components.

Just some options.

Ralph

dpoulinwrote:
So how do you deal with connecting to a project and seeing 180 or
so
builds to select from or 180 or so promotes, streams etc. Is there
anyway to filter the list under eclipse? I would be interested in
hearing from someone who is actually dealing with an RTC project
that
has 100+ components.

rschoonwrote:
Hi Donald,

my 2 cents.

Having few projects reduces the administrative overhead. If you can
get along with a few projects go for few.

A real need for having multiple project areas starts with

* Requirements for restrictions on read access
* Completely different process definitions e.g. different work item
types and workflows

The number of components on a stream should not be too big see
http://jazz.net/library/article/205/ 180 are way below the
threshold though.

Ralph

dpoulinwrote:
I am looking at a large zOS shop that has Endevor with
approximately
180 subsystems (applications). Looking at the possibility of
migrating to RTC3.0 I am looking at a potentially large number of
components and of course along with those the streams, dependency
build definitions, promotions and package/deploys. Under the
eclipse
client there is no way that I have seen where you can filter your
view so that you only see a subset of streams, builds, promotes
etc.
if all these artifacts are defined under one RTC project area when
a
user connects they have a LONG list of items to deal with. I know
you
can use the "Favorites" folder for some things but not
the
ones mentioned (correct me if I am wrong).

In the shop I may logically see an organizational grouping that
would suggest creating a few RTC project areas but not a lot of
them.
So for manageability what are the pros/cons for creating a LOT of
RTC
project areas to the point I may have only a few components and
component related artifacts in each rather than a few projects and
MANY components and component
artifacts?