Making code promotion easier
Hey everybody.. Here we have started using RTC and so far it's working pretty good. Our previous source control tool was synergy, and one thing we're struggling is how to make code promotion from different releases easier.... Right now, we have different streams for each release (one for the production codebase and others for each parallell release we have). The problem is that we eventually need to promote fixes from release N to release N+1 and all subsequent ones. Synergy allowed non-conflicting changes to flow automatically, and for all conflicting ones we had a report and then developers could merge them and fix.
On RTC, the only way I have found to do something similar was to temporarily repoint the N+1 workspace flow to release N (so the pending changes will popup), accept them and merge. We also tried the post build deliver, but that was confusing since the developers started seeing thousand of incoming changes after a promotion build, since all change sets are re-delivered.
What I was trying to accomplish here was an automated view (like the one we have by comparing streams), so developers could simply run the report or open the view and see the pending promotion fixes, accept them and merge. We want to avoid the manual re-pointing since that could cause issues if one forgets to point to the right flow.
Is there any way we can do such thing?
On RTC, the only way I have found to do something similar was to temporarily repoint the N+1 workspace flow to release N (so the pending changes will popup), accept them and merge. We also tried the post build deliver, but that was confusing since the developers started seeing thousand of incoming changes after a promotion build, since all change sets are re-delivered.
What I was trying to accomplish here was an automated view (like the one we have by comparing streams), so developers could simply run the report or open the view and see the pending promotion fixes, accept them and merge. We want to avoid the manual re-pointing since that could cause issues if one forgets to point to the right flow.
Is there any way we can do such thing?
6 answers
You can show streams in Pending Changes and run delivers stream to stream for non-conflicting changes. It is a manual procedure but developers are allowed to have more than one workspace loaded/tracked in Pending Changes.
https://jazz.net/library/article/126#Streams_ShowPendingChanges
Why does a post-build deliver not work for you? The developers will see changes incoming if they do not have them in their workspaces. Whether the build delivered them or somebody else, those changes would still appear as incoming to developers that don't have the changes.
What do you mean by "re-delivered" change sets? You cannot re-deliver a change set that already exists in the stream.
https://jazz.net/library/article/126#Streams_ShowPendingChanges
Why does a post-build deliver not work for you? The developers will see changes incoming if they do not have them in their workspaces. Whether the build delivered them or somebody else, those changes would still appear as incoming to developers that don't have the changes.
What do you mean by "re-delivered" change sets? You cannot re-deliver a change set that already exists in the stream.
> Is there any way we can do such thing?
A build workspace can accept automatically from multiple targets in different components, but not from multiple targets for a given component. You can open an enhancement request with your scenario against Source Control to discuss this further.
https://jazz.net/library/article/649 and https://jazz.net/library/article/649#Example_showPendingChanges will give you ideas on how you can setup your builds to make sure you only promote changes verified by a build (post build deliver to a target stream), and track multiple streams in pending changes view to detect when new changes are ready to be delivered to the streams higher. But you're right, use "change flow target" on a repo workspace to accept and merge the changes to the various streams involved.
HTH,
Christophe Cornu
A build workspace can accept automatically from multiple targets in different components, but not from multiple targets for a given component. You can open an enhancement request with your scenario against Source Control to discuss this further.
https://jazz.net/library/article/649 and https://jazz.net/library/article/649#Example_showPendingChanges will give you ideas on how you can setup your builds to make sure you only promote changes verified by a build (post build deliver to a target stream), and track multiple streams in pending changes view to detect when new changes are ready to be delivered to the streams higher. But you're right, use "change flow target" on a repo workspace to accept and merge the changes to the various streams involved.
HTH,
Christophe Cornu
If you are promoting all changes from Release N to Release N+1, then
that would be reasonably simple to script using the RTC scm command line
tool (use "scm deliver" to deliver the changes from the Release N stream
to the Release N+1 stream). If there is a conflict, the script will
throw an error with an appropriate error message, and you can have the
script send email (or submit a work item) so that a human can go in and
do the merge.
Or does someone see a problem with this scripting approach?
Cheers,
Geoff
On 9/21/2011 1:53 PM, pr3st00 wrote:
that would be reasonably simple to script using the RTC scm command line
tool (use "scm deliver" to deliver the changes from the Release N stream
to the Release N+1 stream). If there is a conflict, the script will
throw an error with an appropriate error message, and you can have the
script send email (or submit a work item) so that a human can go in and
do the merge.
Or does someone see a problem with this scripting approach?
Cheers,
Geoff
On 9/21/2011 1:53 PM, pr3st00 wrote:
Hey everybody.. Here we have started using RTC and so far it's working
pretty good. Our previous source control tool was synergy, and one
thing we're struggling is how to make code promotion from different
releases easier.... Right now, we have different streams for each
release (one for the production codebase and others for each
parallell release we have). The problem is that we eventually need to
promote fixes from release N to release N+1 and all subsequent ones.
Synergy allowed non-conflicting changes to flow automatically, and
for all conflicting ones we had a report and then developers could
merge them and fix.
On RTC, the only way I have found to do something similar was to
temporarily repoint the N+1 workspace flow to release N (so the
pending changes will popup), accept them and merge. We also tried the
post build deliver, but that was confusing since the developers
started seeing thousand of incoming changes after a promotion build,
since all change sets are re-delivered.
What I was trying to accomplish here was an automated view (like the
one we have by comparing streams), so developers could simply run the
report or open the view and see the pending promotion fixes, accept
them and merge. We want to avoid the manual re-pointing since that
could cause issues if one forgets to point to the right flow.
Is there any way we can do such thing?
You can show streams in Pending Changes and run delivers stream to stream for non-conflicting changes. It is a manual procedure but developers are allowed to have more than one workspace loaded/tracked in Pending Changes.
https://jazz.net/library/article/126#Streams_ShowPendingChanges
Why does a post-build deliver not work for you? The developers will see changes incoming if they do not have them in their workspaces. Whether the build delivered them or somebody else, those changes would still appear as incoming to developers that don't have the changes.
What do you mean by "re-delivered" change sets? You cannot re-deliver a change set that already exists in the stream.
Currently, we have the promotion build definition with the post-build deliver targeting the N+1 development stream (where all developers deliver the changes to).
After the build is ran, the N+1 development stream is replaced with the snapshot from the N release, and developers start to see all their N+1 changes as pending for delivering. After some time, this means thousands of outgoing change sets. Even worse, if they're not up-to-date with N+1 changes and the promotion build is performed, they cannot merge the changes because they need to catch-up with release N, which would again require the some flow re-pointing.
Sorry, I used the word re-delivered in a confusing context.
Actually, this would be very similar to the scenario we had before using Synergy SCM. Basically, synergy automatically pushes non-conflicting changes and we had a weekly script generating a report of conflicting changes so someone could take care of them.
This is one script I have found by researching the subject.
http://www.befreeman.com/2011/05/automated-merges-with-rational-team.html
Maybe that would be a good start point..
Thanks,
This is one script I have found by researching the subject.
http://www.befreeman.com/2011/05/automated-merges-with-rational-team.html
Maybe that would be a good start point..
Thanks,
If you are promoting all changes from Release N to Release N+1, then
that would be reasonably simple to script using the RTC scm command line
tool (use "scm deliver" to deliver the changes from the Release N stream
to the Release N+1 stream). If there is a conflict, the script will
throw an error with an appropriate error message, and you can have the
script send email (or submit a work item) so that a human can go in and
do the merge.
Or does someone see a problem with this scripting approach?
Cheers,
Geoff
On 9/21/2011 1:53 PM, pr3st00 wrote:
Hey everybody.. Here we have started using RTC and so far it's working
pretty good. Our previous source control tool was synergy, and one
thing we're struggling is how to make code promotion from different
releases easier.... Right now, we have different streams for each
release (one for the production codebase and others for each
parallell release we have). The problem is that we eventually need to
promote fixes from release N to release N+1 and all subsequent ones.
Synergy allowed non-conflicting changes to flow automatically, and
for all conflicting ones we had a report and then developers could
merge them and fix.
On RTC, the only way I have found to do something similar was to
temporarily repoint the N+1 workspace flow to release N (so the
pending changes will popup), accept them and merge. We also tried the
post build deliver, but that was confusing since the developers
started seeing thousand of incoming changes after a promotion build,
since all change sets are re-delivered.
What I was trying to accomplish here was an automated view (like the
one we have by comparing streams), so developers could simply run the
report or open the view and see the pending promotion fixes, accept
them and merge. We want to avoid the manual re-pointing since that
could cause issues if one forgets to point to the right flow.
Is there any way we can do such thing?
Thanks,
I'm trying a hibrid approach here, where we have an intermediary stream where post-build deliveries the code to and developers can check the pending changes for code promotions. This is good because we don't need to keep repointing our workspaces flows and still merge the changes. If no conflicts are there, they can simply deliver from promotion stream to DEV stream.. if conflicts are there, they can right click and accept changes locally, merge and deliver.
Let's see how it goes...
Fernando
I'm trying a hibrid approach here, where we have an intermediary stream where post-build deliveries the code to and developers can check the pending changes for code promotions. This is good because we don't need to keep repointing our workspaces flows and still merge the changes. If no conflicts are there, they can simply deliver from promotion stream to DEV stream.. if conflicts are there, they can right click and accept changes locally, merge and deliver.
Let's see how it goes...
Fernando
You can show streams in Pending Changes and run delivers stream to stream for non-conflicting changes. It is a manual procedure but developers are allowed to have more than one workspace loaded/tracked in Pending Changes.
https://jazz.net/library/article/126#Streams_ShowPendingChanges
Why does a post-build deliver not work for you? The developers will see changes incoming if they do not have them in their workspaces. Whether the build delivered them or somebody else, those changes would still appear as incoming to developers that don't have the changes.
What do you mean by "re-delivered" change sets? You cannot re-deliver a change set that already exists in the stream.