It's all about the answers!

Ask a question

Planning a Jazz SCM setup


Soren Peen (61) | asked Dec 07 '09, 8:50 a.m.
Hi,

We are currently in the process of planning a move of versioning system from CVS to the jazz SCM system. Since we are already using Team Concert and the SCRUM development process, we would like to take advantage of the work item/change set integration while retiring our aging CVS server.

Having read the JUnit examples we have come up with a proposed setup and I am now writing this post, because I would appreciate some input on this setup from others, who may have some experience with running a development environment in team concert. Hopefully this will set off a constructive discussion which may also help others in similar situations.

To get right to it, our setup is as follows:
- One product consisting of several components, but everything is always released together.
- Two development teams working independently mostly in separate components, but changes in common components do happen. The teams do not necessarily release their work at the same time.

In the interest of keeping everything as simple as possible, the initial plan for a setup in team concert is as follows:

The product is imported into jazz SCM as a single component.
Four streams are created in total:
- Two development streams, one for each of the development teams allowing them to work in isolation.
- One integration stream.
- One release stream.

The process will then dictate that each development team works in their own stream and deploys all changes to the integration stream at least once a week. Each development team does not accept the changes of the other team from the integration stream, except in cases where changes in common components has created conflicts. This should allow each team to work in isolation while allowing conflicts to be caught early and the resolved fixes being deployed to both teams. The release stream is there to allow a team to deploy their changes where the testers can work on getting a release ready without being bothered by the continuing changes in the development stream.

This description is a simplified view of the situation so as not to get bogged down discussing details. What I'd really like to hear is if anyone has experience with a similar setup of components and streams and how it worked out?

Best regards
Soren

4 answers



permanent link
Geoffrey Clemm (30.0k23035) | answered Dec 07 '09, 9:38 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
It sounds like a reasonable set-up, except for the rule:

"Each development team does not accept the changes of the other team
from the integration stream, except in cases where changes in common
components has created conflicts."

This can significantly increase the number of conflicts (because one
team is not working with the latest version of a file), as well as hide
inter-file conflicts until testing takes place on the integration stream
(always better to catch the conflicts in development if possible).

So I'd suggest changing that to be "Each development team accepts a
checkpoint from the integration stream when there is a clean (green)
build of that checkpoint."

Cheers,
Geoff

peen wrote:
Hi,

We are currently in the process of planning a move of versioning
system from CVS to the jazz SCM system. Since we are already using
Team Concert and the SCRUM development process, we would like to take
advantage of the work item/change set integration while retiring our
aging CVS server.

Having read the JUnit examples we have come up with a proposed setup
and I am now writing this post, because I would appreciate some input
on this setup from others, who may have some experience with running a
development environment in team concert. Hopefully this will set off a
constructive discussion which may also help others in similar
situations.

To get right to it, our setup is as follows:
- One product consisting of several components, but everything is
always released together.
- Two development teams working independently mostly in separate
components, but changes in common components do happen. The teams do
not necessarily release their work at the same time.

In the interest of keeping everything as simple as possible, the
initial plan for a setup in team concert is as follows:

The product is imported into jazz SCM as a single component.
Four streams are created in total:
- Two development streams, one for each of the development teams
allowing them to work in isolation.
- One integration stream.
- One release stream.

The process will then dictate that each development team works in
their own stream and deploys all changes to the integration stream at
least once a week. Each development team does not accept the changes
of the other team from the integration stream, except in cases where
changes in common components has created conflicts. This should allow
each team to work in isolation while allowing conflicts to be caught
early and the resolved fixes being deployed to both teams. The
release stream is there to allow a team to deploy their changes where
the testers can work on getting a release ready without being bothered
by the continuing changes in the development stream.

This description is a simplified view of the situation so as not to
get bogged down discussing details. What I'd really like to hear is
if anyone has experience with a similar setup of components and
streams and how it worked out?

Best regards
Soren

permanent link
Soren Peen (61) | answered Dec 07 '09, 10:51 a.m.
Hi Geoff,

Thanks for your input! I can definitely see your point. I am however concerned that if both teams accept changes from each other, it will mean that when one of the teams are ready for a release, they will be deploying a workspace that also contains changes from the other team, which may not be complete.
Is there any mechanisms to manage/avoid that situation, which I have missed?

The reasoning behind the proposed setup of only accepting changes borne of conflicts was that changes in common components between teams can be considered fairly rare and the continuous integration should discover them rapidly.

Regards
Soren

permanent link
Jean-Michel Lemieux (2.5k11) | answered Dec 07 '09, 10:51 p.m.
JAZZ DEVELOPER
> The product is imported into jazz SCM as a single component.

You are probably going to have trouble having code split between teams but all withing the same component. It's doable, but harder to enforce your process that some changes are accepted, but not all of them.

When there is a level of distinction between the teams and their pace, having the component separation makes it a lot more fluid to control what gets accepted and what doesn't, at a higher granularity.

We've set this up multiple times, and everything in your description is reasonable, but it would be simpler with two components, one for each team that needs isolation. Teams deliver baselines of their components to the integration stream when they think it's stable.

We catch integration problems by running a build that takes the latest from both streams and compiles, and tests it. Or you can let the teams decide on when to integration.

Cheers,
Jean-Michel

permanent link
Geoffrey Clemm (30.0k23035) | answered Dec 07 '09, 11:23 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
By a "clean build", I meant not just a compile, but a build that
successfully ran all of the automated tests. That would catch
incomplete/incorrect changes. But I agree that if the teams are not
releasing on the same schedule, that when one team is stabilizing for a
release, that team would stop accepting changes from the integration
stream until their release. Note that in this case, they wouldn't
accept changes from the integration stream, even if there are conflicts.

Cheers,
Geoff

peen wrote:
Hi Geoff,

Thanks for your input! I can definitely see your point. I am however
concerned that if both teams accept changes from each other, it will
mean that when one of the teams are ready for a release, they will be
deploying a workspace that also contains changes from the other team,
which may not be complete.
Is there any mechanisms to manage/avoid that situation, which I have
missed?

The reasoning behind the proposed setup of only accepting changes
borne of conflicts was that changes in common components between
teams can be considered fairly rare and the continuous integration
should discover them rapidly.

Regards
Soren


Geoffrey Clemm wrote:
It sounds like a reasonable set-up, except for the rule:

"Each development team does not accept the changes of the other team
from the integration stream, except in cases where changes in common
components has created conflicts."

This can significantly increase the number of conflicts (because one
team is not working with the latest version of a file), as well as
hide inter-file conflicts until testing takes place on the
integration stream (always better to catch the conflicts in
development if possible).

So I'd suggest changing that to be "Each development team accepts a
checkpoint from the integration stream when there is a clean (green)
build of that checkpoint."

Your answer


Register or to post your answer.