Managing Parallel Development Streams With Shared Codebases in Jazz SCM

We're in the situation where we have a common codebase (i.e. a shared set of Jazz components) which is being worked on by more than one development team, each of whom have different release dates. It is possible to set up Jazz to work for this situation, but it confused me at first. Here's how we managed it.



Create a "Next Release" Stream (for Integration and Releasing)
Firstly you need to create a "Next Release" Stream. No development happens on this stream, but it does contain all the components which all the other developments will be working on. It is purely for other streams to deliver into, and acceot changes from, and where releases are made. When a release is made, a new stream is created, named after the release, and any bug fixes made in that stream are flowed back into "Next Release".

Create the "Project Xxxxx" Streams as Required
For each development team (tasked with a certain package of work - called "Change Requests" in out project) create a new Stream containing the Components from the "Next Release" Stream as required. Name them after the Project and make the flow target the "Next Release" stream. Add build engines for each new Stream, each with their own workspace. We have two - one which compiles the code and runs just the unit tests and another which also deploys and runs the integration tests. The former is automatic on each check in. The other is scheduled to run at intervals.

Usage
Set up Jazz with seperate teams for each project. These in turn should have seperate dev lines and Iterations and Iteration Plans. Developers then create workspaces as required.

Development proceeds as normal, with developers delivering changes to their project's stream no a regular basis (twice a day is good) and accepting changes which are incoming. In addition, the team which is scheduled to release first periodically deliver their changes into the "Next Release" Stream (once a week? the volatility of the codebase and amount of shared components with other projects will dictate the frequency). The other teams then flow these changes into their workspaces, merging as required. They do not yet flow their changes into the "Next Release" Stream.

When the time comes, the release is made from the "Next Release" Stream. As mentioned before, a new Stream is created and populated with the new release's Components. Bugs subsequently found in this release are fixed in this Stream and flowed back into the "Next Release" Stream also.

What if Both Projects Release Simultaneously?
If both projects deliver simultaneously, then both teams should merge into the "Next Release" Stream as the periodic merge intervals, and accept the resulting changes which come from other projects. This should be done one project at a time to ensure that there is always a working set of functionality for the Next Release.