Planning a Jazz SCM setup
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
Geoffrey Clemm (30.1k●3●30●35)
| 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, |
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 |
> 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 |
Geoffrey Clemm (30.1k●3●30●35)
| 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, Geoffrey Clemm wrote: It sounds like a reasonable set-up, except for the rule: |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.