Jazz SCM: Big amount of streams, components and teams
Hi,
We are evaluating (again) the possibility of deploy Jazz SCM as corporate SCM solution.
Due to our development/corporate structure we have serious doubts about how to map Jazz SCM concepts.
At this moment we have 40 software responsibility "areas" . Each one has 3 different areas of development and each development area has his development team or teams.
So, 40 x 3 = 120 development areas and 30 teams (one team is related to more than one development area). Each development area contains or will contain about 100 development components.
Write access to SCM repository must be granted to each team only over his development area.
This situation, due to how Jazz SCM security works (I could be wrong), leads to an structure like that:
30 teams each one proprietary of some streams (120 streams in total) each stream containing 100 components.
This numbers are going to grow in the future. It's possible that we reach 200 responsibility areas:
200 x 3 = 600 streams and, maybe, 50 teams.
And my question is: This volume of teams/streams/component could be a problem in terms of performance?
Any recommendations or good practices?
Thanks in advance
Andres
We are evaluating (again) the possibility of deploy Jazz SCM as corporate SCM solution.
Due to our development/corporate structure we have serious doubts about how to map Jazz SCM concepts.
At this moment we have 40 software responsibility "areas" . Each one has 3 different areas of development and each development area has his development team or teams.
So, 40 x 3 = 120 development areas and 30 teams (one team is related to more than one development area). Each development area contains or will contain about 100 development components.
Write access to SCM repository must be granted to each team only over his development area.
This situation, due to how Jazz SCM security works (I could be wrong), leads to an structure like that:
30 teams each one proprietary of some streams (120 streams in total) each stream containing 100 components.
This numbers are going to grow in the future. It's possible that we reach 200 responsibility areas:
Any recommendations or good practices?
Thanks in advance
Andres
2 answers
600 streams (if distributed into several project areas) should be
manageable.
But note that a "responsibility area" might not imply the creation of a
separate stream. It might just be a different team area. You create
new streams when you want to isolate the changes made by one team from
the changes made by another team.
And I assume that many of the teams will share components used by other
teams?
Cheers,
Geoff
On 2/9/2011 5:53 AM, jaguerrero wrote:
manageable.
But note that a "responsibility area" might not imply the creation of a
separate stream. It might just be a different team area. You create
new streams when you want to isolate the changes made by one team from
the changes made by another team.
And I assume that many of the teams will share components used by other
teams?
Cheers,
Geoff
On 2/9/2011 5:53 AM, jaguerrero wrote:
Hi,
We are evaluating (again) the possibility of deploy Jazz SCM as
corporate SCM solution.
Due to our development/corporate structure we have serious doubts
about how to map Jazz SCM concepts.
At this moment we have 40 software responsibility "areas" .
Each one has 3 different areas of development and each development
area has his development team or teams.
So, 40 x 3 = 120 development areas and 30 teams (one team is related
to more than one development area). Each development area contains or
will contain about 100 development components.
Write access to SCM repository must be granted to each team only over
his development area.
This situation, due to how Jazz SCM security works (I could be wrong),
leads to an structure like that:
30 teams each one proprietary of some streams (120 streams in total)
each stream containing 100 components.
This numbers are going to grow in the future. It's possible that we
reach 200 responsibility areas:
200 x 3 = 600 streams and, maybe, 50
teams.
And my question is: This volume of teams/streams/component could be a
problem in terms of performance?
Any recommendations or good practices?
Thanks in advance
Andres