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:
- Development, Integration and Release Streams
- Streams for parallel branched development
- 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.
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.
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.
If you’re not sharing via a binary repository as described at the top then this is my recommended option.
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