Is it possible to have the list of all work items containing change sets delivered on a specific stream (from a start to an end date)?
We have multiple source code streams (dev and maintenance streams) and we would like to use the same work item (defect or task) to deliver related code changes to different streams (defining a different change set for each stream where the change has to be delivered on). It happens, for example that a defect found developing the new feature is a base defect and so the changes have to be delivered also into maintenance streams.
In this context, is there any way to get the list of the work items that contains change set delivered into a specific stream? We found that it is possible to get the list of wi which contain a change set, but we don't found a way to filter change sets on the stream which they have been delivered on.
The only way we found for getting the list of work items with change set on a specific stream is to duplicate the work items for delivering changes into different streams, planning them for different iteration (depending on the related stream) and then filtering the work items using the planned for attribute.
Is there a different way to get this kind of wi list?
Is there any best practices for getting this information.
Thank you very much.
Best regards,
Tullio
In this context, is there any way to get the list of the work items that contains change set delivered into a specific stream? We found that it is possible to get the list of wi which contain a change set, but we don't found a way to filter change sets on the stream which they have been delivered on.
The only way we found for getting the list of work items with change set on a specific stream is to duplicate the work items for delivering changes into different streams, planning them for different iteration (depending on the related stream) and then filtering the work items using the planned for attribute.
Is there a different way to get this kind of wi list?
Is there any best practices for getting this information.
Thank you very much.
Best regards,
Tullio
2 answers
Searching for work items planned for the iteration that you want won't guarantee that the associated change sets have been delivered for that iteration. It's possible to have a work item with change sets that never get delivered to any stream or even to the wrong stream. The work item only shows intent on where the work will be delivered.
You can search for change sets using the Locate Change Sets editor. If you right-click on a change set, you can check if it exists in a stream. If you are on a version before 4.0, the locate change sets option is still there but isn't as fully featured compared to 4.0.
Based on what you want to do, it might be better to have a related task to the defect for delivering to the maintenance stream, or dev stream if you prefer. This would track the task of delivering the change set and any other work if the change set doesn't apply cleanly to the other stream.
You can search for change sets using the Locate Change Sets editor. If you right-click on a change set, you can check if it exists in a stream. If you are on a version before 4.0, the locate change sets option is still there but isn't as fully featured compared to 4.0.
Based on what you want to do, it might be better to have a related task to the defect for delivering to the maintenance stream, or dev stream if you prefer. This would track the task of delivering the change set and any other work if the change set doesn't apply cleanly to the other stream.
Comments
Thank you Tim for your quick replay.
The problem using the Locate Change Sets editor is that we need to check each change set. What we are searching for is something that could help us in getting (with a single operation) the list of all change set delivered to a specific stream.
Sorry what do you mean with "The work item only shows intent on where the work will be delivered."
I was thinking about the possibility to add a "stream" attribute in the change set object that could be used as a filter into the query work item editor. Do you know if there is some way to do this?
Thank you very much.
Ciao,
Tullio
Work items doesn't depend on source control so they don't provide any attributes to query at the level you want. Change sets also don't have any way for you to add an attribute to it.
Sorry what do you mean with "The work item only shows intent on where the work will be delivered."This means a change set associated with a work item isn't guaranteed to have been delivered to the stream the work item is planned for. Once you have the work items, you'll still have to do the check on the change sets to see if they were delivered.
If you are using RTC pre-4.0, you will be limited to searching one change set for one stream at a time. The only way you can search multiple change sets in multiple streams is in 4.0 where the locate change sets editor was enhanced with better search capability.
FYI, when responding to an answer, you can add a comment to it instead of starting a new answer. This helps other users differentiate answers vs. comments.
It sounds like your primary use case is selecting which work items from one stream should be applied to another stream.
The simplest approach is to make the initial change to a stream that "flows into" the other stream. For example, commonly, all the changes from a maintenance stream will flow into the current development stream. So if you have a change that needs to be made to both maintenance and development, perform the change in the maintenance stream, and then that change will automatically flow into the development stream. So in particular, review where a change should go *before* you start making the change in the development stream
But suppose that you are concerned that people are not being careful about making changes in the right stream first, and changes that should have been made initially in the maintenance stream are mistakenly being initially made in the development stream. The approach I usually use for this case is to create a "review-for-backporting" stream, where the stream containing changes to be reviewed (such as the development stream in the above example) is marked as flowing into this review stream. Then I periodically, use the pending changes view to determine whether there are any new changes in the development stream. If Ifind a change that needs to be backported, I add an Approval to the appropriate work item, indicating it needs to be backported. If during the backport operation I discover I need to actually create a patch or do some merging, I'll create a backport work item, to hold that work.
The simplest approach is to make the initial change to a stream that "flows into" the other stream. For example, commonly, all the changes from a maintenance stream will flow into the current development stream. So if you have a change that needs to be made to both maintenance and development, perform the change in the maintenance stream, and then that change will automatically flow into the development stream. So in particular, review where a change should go *before* you start making the change in the development stream
But suppose that you are concerned that people are not being careful about making changes in the right stream first, and changes that should have been made initially in the maintenance stream are mistakenly being initially made in the development stream. The approach I usually use for this case is to create a "review-for-backporting" stream, where the stream containing changes to be reviewed (such as the development stream in the above example) is marked as flowing into this review stream. Then I periodically, use the pending changes view to determine whether there are any new changes in the development stream. If Ifind a change that needs to be backported, I add an Approval to the appropriate work item, indicating it needs to be backported. If during the backport operation I discover I need to actually create a patch or do some merging, I'll create a backport work item, to hold that work.
