Advice on best way to use RTC streams
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
- 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.
- 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.
- 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.
- Like 3.
also a nice approach: Green Stream https://jazz.net/library/article/649
Comments
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?
- 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