It's all about the answers!

Ask a question

Any sample to maintain two development streams in project?


jon chen (4611715) | asked Sep 11 '08, 5:36 a.m.
In our project, we are using only one development stream. Everyone delivers their workspaces to this stream. It may cause some problems by delivering error code into it.

So, can we create another stream for this project in RTC? The previous stream will be development stream, and the new stream will be the integration stream. People develiver their code to the development stream first. If they verify the code in development stream is fine for the final build. They will deliver their code to the integration stream.

Is this scenario possible? Or, do we have another way?

3 answers



permanent link
Dmitry Karasik (1.8k11) | answered Sep 11 '08, 5:36 a.m.
JAZZ DEVELOPER
So, can we create another stream for this project in RTC? The previous
stream will be development stream, and the new stream will be the
integration stream. People develiver their code to the development
stream first. If they verify the code in development stream is fine for
the final build. They will deliver their code to the integration stream.

Is this scenario possible? Or, do we have another way?

Yes, this is roughly how the jazz team itself works.

- Dmitry

permanent link
David Olsen (5237) | answered Sep 15 '08, 7:28 p.m.
JAZZ DEVELOPER
czhuang wrote:
In our project, we are using only one development stream. Everyone
delivers their workspaces to this stream. It may cause some problems
by delivering error code into it.

So, can we create another stream for this project in RTC? The previous
stream will be development stream, and the new stream will be the
integration stream. People develiver their code to the development
stream first. If they verify the code in development stream is fine
for the final build. They will deliver their code to the integration
stream.

Is this scenario possible? Or, do we have another way?

Another possible way to limit the frequency of the integration breaking
is to have developers run a build which uses their own repository
workspace as the source. Developers would be expected to run such a
build before delivering to the integration stream if there is any chance
that their change could break the integration stream. This has
essentially the same effect as a development stream (not in all cases,
but in most), and it saves the hassle of transferring changes from the
development stream to the integration stream.

permanent link
James D'Anjou (2011511) | answered Sep 15 '08, 9:02 p.m.
I recommend examining the Team Convert User workshop which illustrates
practices like this and many more.

In the workshop database used on Jazz.net/Learn you have the opportunity
to see coordination between three streams, the user interface team
stream, the core library team stream, and the integration stream.

I recommend examining the slides and exercises for lesson
110-...-Project growth and multi-stream development.

It illustrates best practices in this area.

Here the workshop link.
https://jazz.net/learn/LearnItem.jsp?href=content/docs/workshop/index.html

Jim D'Anjou
Jazz/RTC Jumpstart Team

David Olsen wrote:
czhuang wrote:
In our project, we are using only one development stream. Everyone
delivers their workspaces to this stream. It may cause some problems
by delivering error code into it.

So, can we create another stream for this project in RTC? The previous
stream will be development stream, and the new stream will be the
integration stream. People develiver their code to the development
stream first. If they verify the code in development stream is fine
for the final build. They will deliver their code to the integration
stream.

Is this scenario possible? Or, do we have another way?

Another possible way to limit the frequency of the integration breaking
is to have developers run a build which uses their own repository
workspace as the source. Developers would be expected to run such a
build before delivering to the integration stream if there is any chance
that their change could break the integration stream. This has
essentially the same effect as a development stream (not in all cases,
but in most), and it saves the hassle of transferring changes from the
development stream to the integration stream.

Your answer


Register or to post 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.