It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,877
×1,221
×23

question asked: Jan 23 '17, 3:16 a.m.
question was seen: 3,994 times
last updated: Jan 24 '17, 3:33 a.m.

Related questions

Advice on best way to use RTC streams

0
Steven Cocks (11●1●1) | asked Jan 23 '17, 3:16 a.m.

Hi

I am in the process of taking over the SCM role for a large enterprise team of 150+ developers spread across multiple scrum teams using a mixture of technologies including Teradata, Oracle, PowerCenter, Aptitude, and scripts

The current setup of RTC has two streams for each scrum team, one for development and one for test. We have a monthly release cycle so each month a release candidate is created and all scrum team test streams are merged one at a time into the release candidate stream.

This release candidate stream then flows into a system integration test stream and a business acceptance stream before finally flowing into the production stream. 1 week is spent in system integration and 1 week in business acceptance

Speaking to the teams and management i have so far identified a number of problems

1. Merging the code into the release candidate takes days as each stream has to rebase from the release candidate before merging and this is done sequentially.
2. We have issues with teams not merging correctly and we overriding each other (particualry the ETL tools which are XML based)
3. Errors found in release candidate are fixed using the development streams and re-delivered. This sometimes brings in code that wasn't targetted for this release as the teams have already started to development functionality for future releases
4. Errors found in production are fixed using development streams. Same problem as above that sometimes they bring in code that is not part of the production fix

I have been reading as much material as i can find on RTC looking at best practises and trying to understand how RTC differs from other versioning systems i have used such as Git and Perforce.

There are plans to rampup the number of scrum teams but first we need to address a number of issues within the current process and i am looking for advice on how best to approach this

Kind Regards
Steve

One answer

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Ralph Schoon (63.5k●3●36●46) | answered Jan 24 '17, 2:57 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
  1. I don't understand the rebase. Usually, if you work with streams, you want to continuously accept, merge, deliver to and from the stream. This keeps the merging effort manageable and the overhead small. You accumulate data and use snapshots/baselines to mark a release candidate. Even if you had a new repository workspace on some baseline that is earlier than the current stream, you should be able to accept the incoming change sets including the merges. You would not have to merge again, as the merge is available as a change set.    

  2. This is not a tool problem. This is a people problem. Maybe there is a lack of training? You can find the users that overwrite by looking into the component history. Tell people what they do wrong or require approval for delivery.

  3. Fix errors on the release candidate. Create a repository workspace/stream from the snapshot for the release candidate. fix issues and accept the fixes back into the development stream later. In addition require approvals for the permission to deliver to the stream.

  4. Like 3.

    also a nice approach: Green Stream https://jazz.net/library/article/649
Comments
Steven Cocks commented Jan 24 '17, 3:17 a.m.

Thanks Ralph

1) I believe you are saying instead of doing the merge of the release candidate to the team stream and then bringing the merged code into the release candidate they should merge directly into the release candidate and resolve code conflicts there, Correct? Also they should do the merge as soon as they are "done" and not wait until the end of the sprint so that the effort to do the merges remains manageable

2) We will be conducting a retrospective around the latest release which had merge issues and will provide training and feedback if required

3) and 4) Agreed. I suspected this was the way it should be done

What do you think about having all these environment streams?

They have streams for the development teams that get merged to a team test stream for deployment into a dedicated test system. Then they have similiar environment streams for both System Integration (SIT) and Business Acceptance Test (BAT) environments once the release candidate has been fully merged.

Shouldn't we get rid of these environment streams and instead deploy test systems from snapshots?

Ralph Schoon commented Jan 24 '17, 3:33 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
  1. Yes. Please note, if your scrum teams heavily overlap in components and get huge merge work in components where multiple teams change, you should consider your architecture and componentization. To reduce heavy merge impact in shared components consider more frequent integration.

    Please read https://jazz.net/library/article/649 and the linked articles
    Stream strategies with Rational Team Concert 3.0 , Multi Stream Development , Getting Started with Setting up Jazz Builds

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.