Is it possible to create a repository workspace only with completed stories and the associated change set?
We sometime need to deliver the code before all stories are completed. The non-completed stories and the associated change set must be "removed" before we release the code, and the non-completed story will just be moved to the next release of the code.
I'm not sure I'm right but if it is possible to create a repository workspace from a previous baseline and then just accept completed stories (and associated change sets), then I think it probably will work. But it MUST be workitem-driven (="story-driven") - that's the way we communicate with product owner.
Case example:
Before starting we have a baseline (my-start-baseline).
We have one epic (my-first-epic) with two stories (my-first-story) and (my-second-story). Both stories have tasks with associated change sets. All tasks (=workitems) that has been completed has been delivered to the stream. But it is only all tasks in (my-first-story) that has been delivered. (my-first-story) are completed but some tasks to (my-second-story) is still in-process, andwe must deliver next release now. We have to exclude (my-second-story).
How do we create a repository workspace only with completed stories (my-first-story) and the associated change?
Regards
Kim Tittemann Burggraaf
I'm not sure I'm right but if it is possible to create a repository workspace from a previous baseline and then just accept completed stories (and associated change sets), then I think it probably will work. But it MUST be workitem-driven (="story-driven") - that's the way we communicate with product owner.
Case example:
Before starting we have a baseline (my-start-baseline).
We have one epic (my-first-epic) with two stories (my-first-story) and (my-second-story). Both stories have tasks with associated change sets. All tasks (=workitems) that has been completed has been delivered to the stream. But it is only all tasks in (my-first-story) that has been delivered. (my-first-story) are completed but some tasks to (my-second-story) is still in-process, andwe must deliver next release now. We have to exclude (my-second-story).
How do we create a repository workspace only with completed stories (my-first-story) and the associated change?
Regards
Kim Tittemann Burggraaf
Accepted answer
What you're describing sounds something like trunk based development. Your team is committing everything to the stream as it is done. When you want to make a release, you cherry pick your changes (i.e. you want story 1 but not story 2 in the release). In trunk based development, you create a branch (i.e. you create a new stream) where you will merge in the cherry picks. Typically, a release engineer will perform this task and is responsible for merging in the changes.
My recommendation is to create a second stream that will represent the release. It will begin at the starting baseline. With your repository workspace, accept all the changes from the main stream. Then switch flow targets to your release stream. Pending Changes can switch views to show outgoing changes grouped by work items. You'll see your change sets grouped by your tasks and you can deliver the ones from story 1.
There might be some change sets that can't be delivered due to the delivery creating a gap. This is due to the nature of RTC's design as a change set based source control. Some of your cherry picked changes may build on top of changes from story 2. You'll have to merge these manually by creating patches from the cherry picked changes. Until the upcoming gaps support is completed, there is no easier way to merge in your cherry picks.
My recommendation is to create a second stream that will represent the release. It will begin at the starting baseline. With your repository workspace, accept all the changes from the main stream. Then switch flow targets to your release stream. Pending Changes can switch views to show outgoing changes grouped by work items. You'll see your change sets grouped by your tasks and you can deliver the ones from story 1.
There might be some change sets that can't be delivered due to the delivery creating a gap. This is due to the nature of RTC's design as a change set based source control. Some of your cherry picked changes may build on top of changes from story 2. You'll have to merge these manually by creating patches from the cherry picked changes. Until the upcoming gaps support is completed, there is no easier way to merge in your cherry picks.
One other answer
I agree with Tim that you should have two streams ... called something like XXX-Integration and XXX-Release.
Any work item can be delivered to XXX-Integration, but only resolved work items can be delivered to XXX-Release (this can be enforced by RTC).
If you find that you are encountering a lot of "gaps", there is a (more complicated) process that avoids creating any gaps:
A developer can have two workspaces, a "development" workspace flowing with the XXX-Release stream and a "deliver" workspace flowing with the XXX-Integration stream. All development is done in the development workspace.
When the developer is ready to deliver intermediate work (before the work item is resolved), the developer would switch to their deliver workspace, accept all changes from their development workspace into their deliver workspace, perform any required merges, and deliver the result to the XXX-Integration stream. When a work item is resolved, the developer delivers the change sets for that work item from their development workspace to XXX-Release stream.
Any work item can be delivered to XXX-Integration, but only resolved work items can be delivered to XXX-Release (this can be enforced by RTC).
If you find that you are encountering a lot of "gaps", there is a (more complicated) process that avoids creating any gaps:
A developer can have two workspaces, a "development" workspace flowing with the XXX-Release stream and a "deliver" workspace flowing with the XXX-Integration stream. All development is done in the development workspace.
When the developer is ready to deliver intermediate work (before the work item is resolved), the developer would switch to their deliver workspace, accept all changes from their development workspace into their deliver workspace, perform any required merges, and deliver the result to the XXX-Integration stream. When a work item is resolved, the developer delivers the change sets for that work item from their development workspace to XXX-Release stream.
Comments
Tim Mok
JAZZ DEVELOPER Aug 09 '13, 7:31 a.m.Can you clarify that the part about only tasks in your first story have been delivered? Does that mean tasks for the second story were not delivered?
Kim Tittemann Burggraaf
Aug 09 '13, 9:08 a.m.Hi Tim
No, some tasks from (my-second-story) was also delivered (to stream) but not all tasks (workitems) - (my-second-story) not completed.