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.

Read More

Tips for Setting up a New Project in IBM's Jazz Team Server

I've just set up my first few projects on IBM's Jazz platform.  It's dead simple, but there are a few things I've learned which are worth knowing.  I've listed them so others can benefit from my experiences.  

NOTE: this is all done with the Web UI.  Once you've completed these steps, its best to move to the Eclipse-based client for the rest of your configuration as the errors are less cryptic / actually exist.

1. Think about what you need before you do anything.  You need to know what you will name your project (we named ours after the client), which process you will use (we are going for Scrum), what your development lines are (we have the default mainline and also an existing release (we have inherited a codebase) and what teams ("Team Areas") you will need (we have one for our client who will access the web UI as well as multiple for ourselves).  There are other descicions to make, but these are the ones you will need at the beginning.
2. Create an admin user for your project area.  Give them JazzAdmin priviledges and also (temporarily) a Developer licence.
3. Logged in as your project admin user deploy the bundled process configurations
4. Still logged in as your project admin user, create the users you need, allocating them licences as appropriate.  As well as the "real" users, you will likely need a Build user.
5. Before you create your Project area, deploy the bundled process configurations
6. Create your project, making sure you select the process you want to use.  Add the users you have created as applicable.  Allocate the users to process roles (i.e. Team Member, ScrumMaster etc.)
7. Create any additional Development Lines.  We kept the default "Main Development Line" but also added a "Support Development Line"
8. Create team areas as required.  We had several - one for the client, one for our onsite support, another for the existing app maintenance, and a fourth for new development.  Team Members can belong to more than one team so don't worry about allocation when designing this layout.  Make sure when you create a Team Area that you select the required Development Line
9. Allocate team members to the team areas as appropriate.  I choose to send the invite emails as this makes getting new members onboard easier
10. Remove the default admin user (archive the account)
    
11. Set up backups 

Additional Notes:

• I've tried this on Jazz 1.0 and 1.0.1
• It might seem as if you can't rename or archive some things after you've created them if you're using the Web UI.  Swap to the Eclipse client and you will probably be in luck.
• I've not covered adding additional "Setup Work Items" which are automatically generated for each user upon creation.  This should be done before team members are added.  I'll cover this in a later blog post

Read More