It's all about the answers!

Ask a question

Is it possible to create a repository workspace only with completed stories and the associated change set?

Kim Tittemann Burggraaf (1624) | asked Aug 09 '13, 7:06 a.m.
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?

Kim Tittemann Burggraaf

Tim Mok commented 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 commented Aug 09 '13, 9:06 a.m. | edited 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.

Accepted answer

permanent link
Tim Mok (6.6k38) | answered Aug 09 '13, 9:26 a.m.
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.
Kim Tittemann Burggraaf selected this answer as the correct answer

Kim Tittemann Burggraaf commented Aug 09 '13, 9:54 a.m.

Thanks Tim, is it possible to do the cherry pick on workitem level or do we have to do this on change set levelĀ 

Tim Mok commented Aug 09 '13, 9:57 a.m.

You can switch your Pending Changes view to show outgoing work items. This will group your change sets by your tasks.

Kim Tittemann Burggraaf commented Aug 09 '13, 10:03 a.m.

Great - many thanks

Kim Tittemann Burggraaf

One other answer

permanent link
Geoffrey Clemm (30.1k33035) | answered Aug 09 '13, 10:28 a.m.
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.

Kim Tittemann Burggraaf commented Aug 09 '13, 11:26 a.m.

Thanks Geoffrey, we normally have multiple developers on each story (=many tasks, =many components) so it could get a little bit complicated I guess - that's life.

Kim Tittemann Burggraaf

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.