Ensuring consistency of delivered change sets
Hi,
In my usage of RTC we often end up with multiple change sets spread across multiple components in a stream. Once or twice we have managed to deliver one changeset, and missed of delivering the other. This causes a break in our scheduled build.
This is the most frequent cause of broken builds (although it should be noted we have only had 3 broken builds in the last 3 months).
Is there any facility in RTC to ensure that these changesets are delivered as a unit?
Thanks
Alasdair
In my usage of RTC we often end up with multiple change sets spread across multiple components in a stream. Once or twice we have managed to deliver one changeset, and missed of delivering the other. This causes a break in our scheduled build.
This is the most frequent cause of broken builds (although it should be noted we have only had 3 broken builds in the last 3 months).
Is there any facility in RTC to ensure that these changesets are delivered as a unit?
Thanks
Alasdair
5 answers
Alasdair
Change sets that span components will always be independent, but you
could consider merging change sets in the same component. I use this
technique often when I have many change sets but would rather not
deliver 15+ change sets for a single work item. Not only are 15+ change
sets hard to manage, but it's harder for people to see what really changed.
Of course, merging change sets does not solve the problem of developers
forgetting about change sets, since if they forget to deliver them,
they'll likely forget to merge them. But merging might help reduce the
chance of error.
While merging change sets is not supported directly, you can achieve the
same result by creating a patch and creating a new change set based on
the patch:
1. In the Pending Changes view, select all the change sets you want to
"merge".
2. Choose "New > Patch..." from the context menu.
3. Create the patch; I typically just use the clipboard, although if you
feel it safer, just create a patch file.
4. Suspend the change sets you wish to "merge" by choosing "Suspend"
from the context menu.
5. In the pending changes view create a new change set by selecting the
component and choosing the "New > Change set" context menu. This change
set will now be the default and will have a blue arrow on it. Associate
it with the appropriate work items, if any.
6. From the workbench menu, choose "Project > Apply Patch..." and apply
the patch you created in step 3.
7. The changes described by the patch will go into the new change set
you created in step 6.
8. Test test test, and possibly run a build.
9. Once you're happy that your single change set is correct, remove your
suspended change sets from any work items they are associated with, and
then discard them by selecting them and choosing "Discard" from the
pending changes view's context menu.
10. Deliver your merged change set.
I hope this helps,
Simon
--
Simon Archer
Jazz Server Team
Change sets that span components will always be independent, but you
could consider merging change sets in the same component. I use this
technique often when I have many change sets but would rather not
deliver 15+ change sets for a single work item. Not only are 15+ change
sets hard to manage, but it's harder for people to see what really changed.
Of course, merging change sets does not solve the problem of developers
forgetting about change sets, since if they forget to deliver them,
they'll likely forget to merge them. But merging might help reduce the
chance of error.
While merging change sets is not supported directly, you can achieve the
same result by creating a patch and creating a new change set based on
the patch:
1. In the Pending Changes view, select all the change sets you want to
"merge".
2. Choose "New > Patch..." from the context menu.
3. Create the patch; I typically just use the clipboard, although if you
feel it safer, just create a patch file.
4. Suspend the change sets you wish to "merge" by choosing "Suspend"
from the context menu.
5. In the pending changes view create a new change set by selecting the
component and choosing the "New > Change set" context menu. This change
set will now be the default and will have a blue arrow on it. Associate
it with the appropriate work items, if any.
6. From the workbench menu, choose "Project > Apply Patch..." and apply
the patch you created in step 3.
7. The changes described by the patch will go into the new change set
you created in step 6.
8. Test test test, and possibly run a build.
9. Once you're happy that your single change set is correct, remove your
suspended change sets from any work items they are associated with, and
then discard them by selecting them and choosing "Discard" from the
pending changes view's context menu.
10. Deliver your merged change set.
I hope this helps,
Simon
--
Simon Archer
Jazz Server Team
Hi Alasdair,
I agree that this is desireable functionality. I've submitted it as
workitem 71191.
Cheers,
Geoff
alasdair wrote:
I agree that this is desireable functionality. I've submitted it as
workitem 71191.
Cheers,
Geoff
alasdair wrote:
Hi,
In my usage of RTC we often end up with multiple change sets spread
across multiple components in a stream. Once or twice we have managed
to deliver one changeset, and missed of delivering the other. This
causes a break in our scheduled build.
This is the most frequent cause of broken builds (although it should
be noted we have only had 3 broken builds in the last 3 months).
Is there any facility in RTC to ensure that these changesets are
delivered as a unit?
Thanks
Alasdair
There is also another trick, the pending changes view has a group by work item mode which basically collapses all the change sets by work item ignoring the component boundaries. This is useful for helping deliver all changes to multiple components at the same time.
To associate multiple change sets to the same work item, simply use the "Associate Work Item" action on the different change sets.
To associate multiple change sets to the same work item, simply use the "Associate Work Item" action on the different change sets.