It's all about the answers!

Ask a question

We are new to RTC and we would like to know the best way to structure our RTC project(s) and how to work on multiple releases simultaneously for a code base.


Michael Whitner (561910) | asked Nov 20 '13, 10:12 a.m.
retagged Dec 16 '13, 12:49 p.m. by David Lafreniere (4.4k7)
Today we have an single code base in a CVS repository that contains multiple products.  We want to migrate this single code base into RTC but, we are unsure of the best approach for structuring one or more projects within RTC.

We would like to have distinct code bases but, each code base would have groups of developers working on different releases of the respective code base. These groups have different members, different goals, different delivery dates, but are working on the same respective code base.

We are new to RTC and we would like to know the best way to structure our RTC project(s) and how to work on multiple releases simultaneously for a code base.


Comments
sam detweiler commented Nov 20 '13, 10:28 a.m.

can u expand on this 'We would like to have distinct code bases but,' a little.

release is an arbitrary word, which can mean lots of things..  in RTC this generally means some deliverable external to the development team.

will the teams members overlap? this usually causes trouble and confusion cause RTC doesn't provide good ways of isolating time spent across multiple projects concurrently by the same people.

are you going to use the planning and workitem components of RTC as well as the source?  this is pretty normal.. People (teams) doing work (workitems) over time (iterations) = Plan.

One answer



permanent link
Geoffrey Clemm (29.5k23035) | answered Nov 22 '13, 12:10 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
For "distinct code bases", you probably should consider storing each code base in its own RTC component (assuming a "code base" maps naturally to a single file system tree).   Until you have a good reason to do otherwise, I would start with a single project area, and create a separate team area for each team.   Each team would have a stream (initially, just one stream per team... you can add more later if needed).  The code bases (components) being worked on by a given team would be added to that team's stream, giving each team its own configuration of that code base.

Comments
Michael Whitner commented Nov 22 '13, 8:14 a.m.

Thank you both for your responses!

I do have an additional question for clarification in my own mind. Speaking with the product owner it is my understanding that within a team they could be working on different releases at the same time in the same component. Would that imply multiple streams within that component?

I envision a “main" stream per component with the code imported from CVS as the baseline. Each release would create a “release” stream from the “main” stream that flows back into the “main” stream. Developers working on that particular “release” stream would create workspaces from the “release” stream that flow back into the release stream. When the “release” is compete and the product is delivered to the world, the changes on the “release” stream can then be accepted back to the “main” stream.

Is this the proper way to perform simultaneous release development within a component?


sam detweiler commented Nov 22 '13, 9:45 a.m.

let me see if I can reflect that back properly.

you have a master codebase.  you fork the master for a release (may be multiple forks, 1/release)..  at some point you attempt to merge the forked changes back into the base.

how do you support the releases? with changes to the forked code? for how long?
who does the release maintenance, same development team?
is the maint work combined with the new release development (dev r+2, maint r,r+1?)

we had one product that had 1 component, a master stream, and a stream per customer (much customization).  SOME of the changes at the customer level also affected the master stream, so we would have to push those changesets into multiple streams. (change flow target)
each new customer would branch from the master at that time.
the child streams lived on forever in parallel.


Geoffrey Clemm commented Nov 23 '13, 2:32 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

The only adjustment I'd make is to flow the changes from the release streams reasonably frequently to the main stream, and not wait until the release is complete.  In addition, rather than flowing all of the release streams to the main stream, I'd flow each of the release streams just to the next higher release stream, and then the highest release stream flows to the main stream.

Your answer


Register or to post your answer.