Every existing SCM tool allows you to fix a bug in a previous release. But the reality is that most SCM tools focus primarily on allowing you to change the code whereas there is more to fixing a bug than simply making the code changes.

It turns out that even with simple projects there are several steps involved, first you have to find the code that you actually shipped, make the changes, test the changes, build and package the changes, and finally make them available. Just when you think your done, another critical customer bug shows up and you have to repeat the process again.

With many projects following the “release often” mantra of Agile development, making this fixing a bug scenario easy is critical so that teams can continuously release fixes to their customers. Needless to say, this is an important use-case that we’ve been trying to tool in Jazz. I have to admit that it’s far from being complete, but we have some coolness which I think shows that we are going in the right direction.

At a high level, the mechanisms that we’ve added to Jazz to help realize these use-cases in Rational Team Concert are as follows:

• Streams, Change-sets, and flows: The basic philosophy of Jazz SCM is that you don’t have to proactively plan development branches, split-streaming, or anything else for that matter. Your job is to make code changes and test them out. Once you have your changes in hand in one or more change-sets, then you can decide about where to flow the changes. In simple cases, you can simply suspend them and work on something else. Or you may want to create a new stream from your repository workspace to work with others on some feature or maintenance effort. The point is that we don’t differentiate between multi-stream development and just making changes so that you don’t have to learn a whole bunch of new concepts when you are working on the latest, collaborating on a small feature with a friend or fixing a bug in a previous release.
• Builds and snapshots: The first step in fixing a bug in a previous release is to find the code that was shipped. Since build results are modeled in Jazz, you can find the build result that was shipped to the customer then use the snapshot associated with the build to reproduce the exact code that was used for the build itself. So modeling both the code and the way the code is built provides a nice linkage between the build artifacts and the build source code. You don’t have to memorize a tag scheme or ask the releng person what version of the files were built, anyone can just look at the build result and navigate from there. It also means that it’s relatively easy to create a new build for the maintenance work as well, you can easily clone a build and have it build from a different stream.
• Development lines: For many larger scale projects, maintenance development is a big task that quite often has a different schedule, process, and contributors. Jazz development lines provide this separation between different efforts within the same project. Each project in the Jazz repository can have one or more development lines. The development line will then conceptually own the maintenance stream, the teams, and the process used for all maintenance work. So you could define more aggressive code review rules for deliveries to the maintenance stream than for the main development and give team members different roles for each. It’s quite possible that the team lead for the main development isn’t the same as the team lead for the maintenance. For small teams with the same team working on small maintenance releases, you can probably get away with simply having a separate stream and milestone in the current development line.

Here is a short six minute video that shows how to fix a bug in a previous release with Rational Team Concert (opens a new window). This video is not meant as a tutorial; it’s more of a very quick overview to give a flavor of what is possible with the client today.

—
Jean-Michel Lemieux
Jazz Source Control Team