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 (56●1●10●10)
| asked Nov 20 '13, 10:12 a.m.
retagged Dec 16 '13, 12:49 p.m. by David Lafreniere (4.8k●7)
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. |
One answer
Geoffrey Clemm (30.1k●3●30●35)
| 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 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?let me see if I can reflect that back properly.
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
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.
Comments
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.