It's all about the answers!

Ask a question

Streams strategy in RTC SCM

Muhammad Moid (141634) | asked Oct 29 '15, 3:14 a.m.
edited Oct 29 '15, 3:21 a.m.

Our company has acquired RTC 5.0.2 and we are now planning to implement RTC source control management with the Best Practices offered by RTC in our Software development Life cycle. e.g. How many streams we need to create, what should be the roles, flow b/w the phases of SDLC, release management etc.    
We have gone through multiple articles on but could not find the precise road map for our implementation. As it is our first implementation in RTC SCM we were desperately looking for any sample case study and we have come across of JKEBanking case study which seems pretty much similar to what we are looking for our complete SDLC but it is difficult for us to understand the working mechanism and sequence of flow b/w the streams.

Kindly help us to understand JKEBanking Flow diagram and strategize our first SCM project in RTC, because basically we cannot figure out how bug fixes and release versioning can be managed by following JKE Banking strategy.

Please note, currently we do not have any source control requirement or process.We just wanted to get started with it with the basics and afterwards when get use to RTC SCM we can modify our process as per our requirement.

You can find the image of JKEbanking flow diagram from the link below :

Muhammad Moid

3 answers

permanent link
Chris McGee (50511117) | answered Nov 03 '15, 4:19 p.m.
Without really understanding how your project works and its goals, I would say that your stream topology seems fine. I usually like to consider other aspects of RTC such as builds and work items when planning this structure.

In general, you probably want to have a stream in any instance where you have multiple developers or teams collaborating to produce some result. Usually the result is a build where the sanity of the code is verified through unit testing, compilation and the assembly of the product version.

In small projects you probably only need a single stream for the whole team and a single component (more on that later). Each developer has their own repository workspace for the stream, which they can load (ie. download) the files to their local hard disk to do their work. They can check-in their changes from their hard disk to the repository workspace and organize them into change sets. Checkin-in changes also backs them up on the server. When the changes are ready they can be delivered to the stream for everyone else and also for the next build. One really fun thing about RTC is that you can run "personal" builds with your repository workspace to check that you won't break the real builds when you deliver your change sets. Kind of like a test drive for your changes.

If your small project will be managing multiple releases at once then you will probably need extra streams to collect changes for each release. Also, you'll probably need extra builds to verify, compile and assemble those streams for the releases. New timelines will allow you to assign work items to different releases. Developers have a choice whether they will create extra repository workspaces to match the streams (releases) that they are working on. If there are large differences between them then they may need to create extras (and load/unload as necessary). Otherwise, if the differences are small (e.g. a maintenance release) then they may be able to switch between different streams as the "flow target" of their repository workspace.

For large projects with multiple teams, like in the JKE banking project, you'll notice that there is a hierarchy of streams. There is one for the entire project and individual ones for each team. This allows the team to work on a long running feature without affecting other teams until it is ready. Because the team has their own stream, they are able to have their own builds.

You'll also notice that the JKE banking project uses multiple components. Logically organizing the parts of the product into components allows you to create streams (and repository workspaces) that include some components, but not others. Sometimes it's not necessary for a particular team to have everything in their own repository workspaces, builds, and stream. They can exclude the components that are not needed.

So, how do changes flow from the team's stream to the central stream with all team's changes. Well, there are a few options. First, you can appoint one developer on the team (e.g. the "releng" person) whose job it is to check the team's builds and occasionally use their repository workspace to switch their flow target to the central stream and deliver all of the team's change sets there. Also, the team's builds can be configured to automatically flow changes to the central stream upon any successful build. You can imagine that getting other team's changes from the central stream to your team's stream has the same two options, which you get to choose.

I hope that this helps to explain the kinds of considerations that you can make when planning your SCM stream topology. For further reading there is a series of articles that attempts to show you how to use RTC starting from a small single-person project gradually into a larger project. The context is Mac application development using the command-line interface but the concepts should be the same regardless of the type of product that you are developing.

I hope that this helps,

permanent link
Ralph Schoon (63.3k33646) | answered Oct 29 '15, 3:33 a.m.
That project is a sample that is supposed to give you enough to play with some data. That sample is not a production environment that has bug fix streams or streams for multiple releases.

We have a library with articles for various things. Try
to see all articles around SCM. There are several interesting ones.

Also see for a general introduction on all the concepts.

You can introduce new streams for new versions as well as for bug fixes. This is, at least from my perspective, very similar to what you would do with "Branches" in other tools. You use repository workspaces to flow changes between different streams. 

Muhammad Moid commented Oct 29 '15, 10:45 a.m.
Thank you for sharing the articles. It was really very helpful to improve my  RTC SCM concepts.
Taking your new versions and big fixes streams suggestion as a starting point, I have created a streams strategy diagram for the implementation in our organization. I would appreciate if you could review it and let me know if there are any issues or changes required in the flow.
You can find my created diagram from the link below:

Muhammad Moid commented Oct 29 '15, 10:47 a.m.
Hi Ralph,

Thank you for sharing the articles. It was really very helpful to improve my RTC SCM concepts.

Taking your new versions and big fixes streams suggestion as a starting point, I have created a streams strategy diagram for the implementation in our organization. I would appreciate if you could review it and let me know if there are any issues or changes required in the flow.

You can download my created flow diagram from the link below:

permanent link
Muhammad Moid (141634) | answered Nov 04 '15, 8:24 a.m.
edited Nov 04 '15, 8:25 a.m.

Thank you Chris. 

You have given a very supportive answer and explained things very well in simple words. I am currently working on the same stream topology in a test environment. However, I was wondering few things in this topology.

1.   If you see my stream topology, there is a Bug Fix 1.0 stream which also flows target to Integration 2.0 stream and the reason for this flow target is to deliver the Release 1.0 fixes into Release 2.0. But by flowing target to integration 2.0, Bug Fix 1.0 would also receive the incoming changes from integration 2.0 and from this all the streams of Release 1.0 will get synced with Release 2.0 . Since I don’t want this to be happen in the topology, is there any way that I can ONLY DELIVER change sets to Integration 2.0 from Bug Fix 1.0 rather than ACCEPTING change sets from Integration 2.0 ?

2. Do you think there is a need of flow targets b/w integration to QA and QA to production streams in our topology? One of my colleague is suggesting me for these flow targets. A/c to him this would enable the person or team to flow the changes quickly when there are no conflicts (just need to load the streams in Pending Changes).

3.  In designed topology, production fixes will go directly from Dev Workspace to Maintenance stream.  Is It essential to pass the fixes via QA stream, If yes then I think there is no need of Maintenance stream in my topology.

4. I have build the small projects (which usually contains one component) easily using build engine and definition. For large projects (which can have many components), how are we going to build our application. Is there any specific step in Build definition to combine all the components and produce single build result?

5. As per my knowledge, the only way testing team will get releases are from their Build Feeds widget on dashboard OR is there any best practice in RTC for testing team to pick the releases for testing?

Ralph Schoon commented Nov 04 '15, 10:25 a.m.

With respect to BugFix and Next release. RTC 6.0.1 provides new capabilities to specify prohibited direction on flows.
With respect to bug fixes, if you have the change sets on work items, another way to bring them into the new release would be to load a repository workspace for that and then accept the changes sets from the work item. I think this will often also require active work to integrate these changes. You might even have conflicting changes.

Muhammad Moid commented Nov 05 '15, 1:16 a.m.

We are currently using RTC 5.0.2, this means to use this feature we have to upgrade RTC to 6.0.1. Great!

I would appreciate if you could give your valuable comments on Point 2 - 5 as well. 

Ralph Schoon commented Nov 05 '15, 8:57 a.m.

This is really something you should try out and take what works best for you. You can always change your strategy and adopt.

2. Either flow from integration to QA or use a post build deliver to deliver to the QA stream. Depends on how you want to work
3. If you don't want to do QA for fixes...........
4. The same as for small ones, you define the workspace to build and the stream and that sets up the components to build
5. You can also coordinate around a work item that tracks the builds to test.

Your answer

Register or to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.