It's all about the answers!

Ask a question

Best way for the parallel development with Rational Team Concert


Leandro Leal (14614245) | asked Dec 04 '14, 3:56 p.m.

We are implementing our company the parallel development with Rational Team Concert, suppose there are two development teams working on 2 different requirements (Feature 1 and Feature 2) but for the same application, also suppose we have two streams: Development and Integration , developers start developing and delivering change sets associated with Feature 1 and Feature 2 in the Development stream, after we have 30 change sets mixed of both requirements on the development stream and then we take the changes sets associated with each requirement to create a base line on the integration stream, we have the following questions:

-        - How do you identify what changes the leader be accept or discard to create the base line on integration stream for Feature 1 and Feature 2?

-         - At what point should merge Feature 1 and Feature 2 and how (a technical response)?

-          - baselines can be merged?

We consulted the source: http://www.ibm.com/developerworks/rational/library/parallel-development-rational-team-concert/

Accepted answer


permanent link
Ralph Schoon (63.1k33646) | answered Dec 05 '14, 6:35 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
edited Dec 05 '14, 6:37 a.m.
If you want to separate integration for Feature 1 and Feature 2 you would not use a common development stream. You would likely rather use separate development streams for each feature, develop them until they are ready and then integrate on a stream.

From my perspective it makes no sense to develop them on one stream, where you will potentially get changes for different features entangled and thus dependent upon each other and then try to unravel the mess afterwards.

Once you have the features stable and a baseline for it, you could create an integration stream for one of the baselines (final feature stream configuration) and a repository workspace from that configuration. Then you  can point the repo workspace to the other feature stream and start accepting the incoming changes, merging them in.

This approach will push merges and integration to the end which is not ideal, but if you want to separate the features later anyway, better do it in the beginning than in the end.

You can compare based on baselines and also merge them using multiple streams and a repository workspace.


Leandro Leal selected this answer as the correct answer

One other answer



permanent link
Leandro Leal (14614245) | answered Dec 05 '14, 7:54 a.m.
edited Dec 05 '14, 7:54 a.m.
Very Thanks! Ralph the answer was very useful.

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.