Mike MacDonagh's Blog

Somewhere in the overlap between software development, process improvement and psychology

Advanced RTC SCM Streaming – Part 3 Component reuse

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? Integration Streams aligned to Definitions of Done? This is the guide for that stuff.

This blog is in three parts:

  1. Development, Integration and Release Streams
  2. Streams for parallel branched development
  3. Streams for component reuse

Part 1 also covers the introduction and overall conclusions

Working with components across multiple RTC projects can present a bit of a challenge. It’s simple enough to create a stream with any baseline of any component in your repository but dealing with changes to those common components is not simple or obvious, especially if you need different visibility controls and access rights for different teams on different components.

Consider the following situation where Team A has a development stream developing some components which depend on Common X while at the same time Team B are in the same position.

General best advice

I generally recommend that the best thing to do here is to put Common X in a binary repository and use a dependency management solution like Maven or Ivy to pull the required version from the repository during build. Doing this you still have the problem of Team A knowing when there’s a new version of Common X and how they can raise defects/changes on it but it’s a good start.

Other options?

Sometimes that’s not possible or not what you want. Sometimes you’ve got a component team working on Common X and you want frequent changes being pushed from the Common X team to Team A and Team B.

One solution to this problem in RTC SCM is to use streams to isolate Team A, Team B and Team Common X while communicating changes.

The following options look at having the Common X component owned by a Team Common project which has both a development and release stream. The common component can then be developed with periodic releases via a release stream. For more details on this kind of separation see Part 1 Development, Integration and Release streams.

Workspace sharing

Developers in Team A and Team B can then load a workspace on the Team Common Release stream providing access to the released version of the component. The advantage of this approach is that Team A and Team B developers can see when a new stable version of the common component is released. The disadvantage is that the dependency between the components is resolved in the local workspace, which is fragile as it’s not a team level dependency but an individual dependency, it’s also difficult to mirror on the build servers.

Component baseline replacement

A better option is to have Team A and Team B include a specific baseline of CommonX in their definition. There is still a problem of Team A and B being notified of new releases though. once they know about a new version they can replace the Common X in their development streams with the new baseline from the Common Release Stream.

Flowing from Common stream to a team stream (not multiple streams)

Using a technique similar to that in Part 2 regarding parallel development you can flow the common component directly between streams (perhaps using flow scope to limit to just one component) to automatically notify a team of changes to the common component and manage the inclusion or not at a team level. The problem with this is that a stream can only have one active flow target so the Common Release stream can only actively deliver it’s changes to one of the teams at a time 😦

RTC limited cross stream delivery flow diagram

Although it’s possible to deliver, change the flow target and deliver repeatedly this could be laborious if there’s more than two dependant teams. Also this option requires the common stream to flow to each dependant team, maintaining that could be annoying.

Shared Integration

If you’re not sharing via a binary repository as described at the top then this is my recommended option.

Multiple team SCM integration

Since streams can only flow to one current target at time the above model is quite limited. The logical alternative is to build a hierarchy of development streams so that integration across  Team A, Team B and Team Common is shared in an integration stream. To do this, set up each development stream (Team A, Team B and Team Common) so flow to the same integration stream. Integrators (perhaps a representative from each team) can then merge changes as necessary in the Shared Integration stream. Any (hopefully minimal) changes made in the Shared Integration can then be flowed back to the respective development streams.

Note this model can of course be built on top of the integration streams rather than the development streams, although then an integrator has to manage two levels of flow so I’ve based this example on development streams for simplicity.

The downside to this plan is of course that it only applies to situations where strictly hierarchical development and integration (or groups of hierarchies) make sense. Also if your development streams are flowing to the Shared integration stream they can’t easily flow to their own integration and release streams without someone changing the flow targets.

If you’re not careful this model will cause components to propagate between all of the involved streams. Although that will make sense of CommonX to propagate to Team A and Team B streams you probably don’t want the Team A and B components in each others streams and the Team Common Development stream. To get around this issue you can scope the flow targets of each stream as follows:

Team Common Development Stream: Only flow CommonX (prevent other incoming components from Shared Integration)

Team B Development Stream: Only flow CommonX and it’s own components (Sneeze and Whisper) to prevent Team A components from coming in.

Team A Development Stream:  Only flow CommonX and it’s own components (Blah and Chortle) to prevent Team B components from coming in.

Changes from each stream will then need promoting if necessary to the Shared Integration stream. So a change made in my local workspace against Common X will need delivering the the Team Common Development Stream. From there the change must be delivered from the Team Common Development Stream to the Shared Integration Stream.

Once delivered into the Shared Integration Stream the change will show as an incoming change from the Shared Integration Stream into each of the Team A and Team B development streams.

Of course once these changes are accepted the changes will then show as incoming changes to Team A and Team B developers as normal changes from their stream to their workspaces.

If you’re looking to do large scale component sharing in RTC scm then odds are you’ll need to use a combination of these techniques across your development organisation. 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 2 for parallel branched development


4 responses to “Advanced RTC SCM Streaming – Part 3 Component reuse

  1. Pingback: Advanced RTC SCM Streaming – Part 2 Parallel branched development « The Mac Daddy

  2. Pingback: Advanced RTC SCM Streaming – Part 1 Development, Integration and Release Streams « The Mac Daddy

  3. Frank March 13, 2012 at 10:17 pm

    There are three things I don’t understand why this is not supported in RTC.
    1. Multiple deliver targets. This would allow Common X to be delivered (pushed) to Team A and Team B.
    2. Baseline promotion levels. This would allow Team A and Team B to subscribe to a promotion level of Common X, thus automatically using the baseline when it reaches the promotion level.
    2. Accept changes from a different stream than the deliver target. This would allow changes to be passed through a rigorous quality assurance process after delivery, before being offered for acceptance to other team members.

    • mikemacd March 13, 2012 at 10:31 pm

      Hi Frank, fair points. I don’t work for IBM so I can’t really comment, but you can raise a change request on them at jazz.net.

      I’d really like to see multiple deliver targets and update subscriptions (1 and 2), it would make complex system of systems integration a whole lot easier.

      As for 3, you can accept changes from a different stream into a workspace, you just change your workspace flow target to accept the change, then reset it to deliver the change back to the “original stream”. However you can only do this between different versions/branches of the same component in different streams. I covered that technique in Part 2 of this guide, in “The practical bit”, co-incidentally it’s option 3 there too!

      I suppose I should have put that in this part too in case people only read one of the parts, but I wrote all this as a bit of stream of conciousness so it all flowed as one story to me when I wrote it.

      Thanks for commenting 🙂

What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: