what is recommended stream strategy for project in maintenance phase?
4 answers
Create a separate stream for each release.
Emergency fixes for a release would be delivered to the stream for that release.
All fixes for a release should be delivered to the next release.
Ideally, you would perform a fix in the earliest release that has that problem ... but if you discover that an earlier release requires the fix, you would need to "back-port" that fix to the earlier release.
Comments
Thanks!
Create a workspace that has both the first and second release as its flow targets. Have the second release be the default target. Periodically, accept changes from both flow targets into the workspace, perform any merges that are required, and then deliver the result to the second release.
Also, When I chave the flow target of RELEASEstream to be DEVstream, components of DEVstream come into RELEASEstream. No merge happens as the components get duplicated in RELEASE stream when I accept the incoming changes. Am I doing anything wrong?
Few Questions:
- When a component is added to a stream by accepting/delivering it to another stream, no merge is needed (merge is only required when two changes are being made in parallel to the same file). So that is working the way it should. Note: You are sharing the configuration of that component in the stream ... you are not making a "copy" of it.
- The targets in a stream/workspace determine what choices you are given when that stream/workspace is shown in the Pending changes view. So it is the flow targets of workspaceA that are the choices you are given for the "change flow target" operation on workspaceA.
- Some teams have a single development stream that is used for all releases, and then they branch of a "release maintenance stream" for each release. That works fine if you don't start working on the next release until you are done with the current release. But if you are working on multiple releases at the same time, you will need separate development streams for each release. The development stream of a release is often used as the maintenance stream for that release, after the release is delivered. The stream is then deleted only when you are no longer doing maintenance on that release (deleting a stream from the GUI will auto-create a snapshot, so you can always restore the release stream from the snapshot, if you want/need to).
- Changes can only flow from to one target (stream) at a time. To flow to multiple streams from one request, you would write a script.
- Currently, there is no way to declare which direction the changes can flow to a flow target. The enhancement request to allow this to be declared is: support directed flows throughout Jazz Source Control (160738) .
Comments
Thanks for this very useful details.
Regarding #1: If I have stream named "Release-1", with "Component-1", with "File-1" in it & is modified by User-1. And I have another stream named "Release-2" which is duplicate of Release-1 stream with "Component-1", with "File-1" in it & is modified by User-2.
Now when I change the flow target of Release-2 to be Release-1, will it give me conflict on File-1, when I accept the incoming changes from Release-1?
Basically, I want that changes from Release-2 should keep getting latest changes from Release-1 and on top of it Release-2 will have its own changes which should not flow to Release-1.
Please let me know.
To flow changes between streams where there are conflicts, you need to use a workspace. So you would have a workspace which flows with both Release-1 and Release-2. To flow changes from Release-1 to Release-2, you would first accept into the workspace all changes from Release-1, and then accept all changes from Release-2. If there are conflicts because the same file has been changed in parallel in each stream (such as File-1 in the preceding comment), then you will have to do a merge in your workspace, which will create a new change-set containing the merge. Then deliver everything in the workspace to Release-2 (which will include any merge change sets that you had to create to resolve merges).
Comments
Pravin Patil
Mar 09 '15, 1:05 a.m.Any answers, please?