Basic usage of RTC Jazz SCM is easy enough but there’s what about more advanced usage? Using streams to isolate development from integration? Cross-project component reuse? Parallel branched development? This is the guide for that stuff.
Feel free to contact me with questions or just use the comments section below – I can also offer RTC Masterclasses covering this stuff and more.
This blog is in three parts:
- Development, Integration and Release Streams
- Streams for parallel branched development
- Streams for component reuse
Part 1 also covers the introduction and overall conclusions
Change set based SCM systems like git and RTC do away with the need for a lot of branching. You don’t need to branch to get developer isolation, to gather file changes together to understand them as an atomic set of changes related to a bit of work or to manage concurrent development of the same files on a small scale. You get all of that for free by using change sets. Developers are always in their own private personal branch separated from the rest of the team but unified by a common stream or repository. However sometimes it’s still appropriate to branch, this blog covers some of the situations when it’s appropriate and how to do it effectively in RTC Jazz SCM.
When to branch?
Change sets provide for developer isolation and can even be shared amongst part of the team without delivering but that’s quite awkward especially when a number of developers might be working together on a change and don’t want (yet) to commit it to the rest of the team. In this case using another branch of the code to isolate the sub-team makes sense.
Another example is for parallel development of a new major version of a product while also developing and releasing updates to a historical release of a product.
In this example imagine that we’ve shipped v1 of a product. We then move onto a new lifecycle developing v2 of the the product. During that dev time critical defects are discovered in v1, they need fixing but the code in v2 has moved on too far to do the fix there. This is another case for the need for branching.
Branching in RTC SCM is achieved using streams. The main development stream continues the creation of v2 but we can make a new stream for v1 maintenance which is based on the v1 release snapshot and will ultimately release v1.1 of the product. Defect fixes in the v1 maintenance stream may or may not need to be merged into the v2 stream depending on how divergent the code is.
The practical bit
Creating a historic stream is easy enough, you create a new stream and instead of creating new components to go in it you select the “Add…” button and add the v1.0 general release snapshot. This new stream could easily have associated integration and release streams if appropriate but the focus of this blog is more about passing changes between v1 and v2 parallel development.
RTC Historical Stream
There are four ways to manage flowing changes from maintenance work in the historical stream to main development work:
- Don’t – just rewrite any changes that are necessary in both streams. Generally a bad idea, but if v2 and v1 are extremely divergent it might be quicker to re-develop something than merge in a change.
- Baseline components in the maintenance stream and replace the v2 dev stream versions with those baselines. This is the easiest option but presupposes that there are no changes in the v1 stream which is extremely unlikely in real life.
- An “Integrator” can create a workspace in between the two streams and manage changes between them.
- Non-conflicting changes can be simply transferred between the streams directly
I would generally recommend option 4, falling back to option 3 where necessary in the case of conflicts.
To directly transfer changes between streams consider the following situation where I have a workspace on both the v2 dev stream and the v1 maintenance stream. I probably can’t load both simultaneously due to code overlaps but that’s not necessary to do this kind of thing. There’s nothing special about this setup other than I’ve added the v2 development stream as a flow target from the v1 maintenance stream.
As well as the pending changes views I’ve got on my two workspaces I can also create a pending changes view between the streams (as of RTC 3.0.1). To do this simply right click on the maintenance stream in the Team Artifacts view and select Show -> Pending Changes
The pending changes view now has 3 root entries:
- v2 dev local -> v2 dev stream
- v1 maintenance -> v1 maintenance stream
- v1 maintenance stream -> v2 development stream
Initially this is going to show a fair few incoming changes from the v2 dev stream to the v1 maintenance stream, however we don’t necessarily want to accept in that direction. If I make a change in my maintenance workspace and deliver it with a comment such as “Fix critical bug 69″ then the Stream Pending changes view allows me to deliver this change from the maintenance stream to the dev stream
This works great for non-conflicting changes however if the changes do conflict then you’ll get an error saying as much and telling you to accept all first and so on. At this point I’d fall back to option 3 mentioned earlier “An Integrator can create a workspace in between the two streams and manage changes between them” do essentially do what the error message tells us:
- Create a workspace on the development stream (or reuse your existing one)
- Accept all incoming so you’ve got an up to date clean workspace
- Open the workspace properties and add the maintenance stream as a flow target, making sure you make it current.
- Accept the conflict from the maintenance stream to your local dev workspace
RTC Cross-stream conflict resolution
- Resolve the conflict in your local dev workspace
- Change the flow target of your workspace back to the development stream – you should now have two outgoing changes: the conflicting change from the maintenance stream and your merges that fix the conflict
- Deliver the change and merge to the development stream
RTC Deliver Merges
Doing this sort of thing without support isn’t easy so call on your software development mentors for help. Don’t be afraid to cross the streams! If you want some expert SCM support, backup or help in your organisation get in touch.
See Part 1 for Development, Integration and Release Streams
See Part 3 for Component reuse