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.
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
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.
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.
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.
Comments
sam detweiler
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.