Including merges and associated work items in a build
Start by following the getting started page
Now you can add in the custom activity. In the tabs at the bottom of the workflow designer, click on “Imports”. Then click the dropdown and add TfsBuildExtensions.Activities to import it into the workflow.
Click on Arguments and create a new Argument (direction: In, type: Boolean) called “IncludeMerges”. Set the default value to True. You can also specify the MetaData for this argument to expose it in the Build Definition wizard later.
Then click on Variables and add a variable called “associatedMergedChangesets” with Scope “Sequence” and type IList.
You’ll need to add the custom activity to the Toolbox. To do this, select a section in the toolbox, right click and select “Choose Items”. In the browse dialog, browse to TfsBuildExtensions.Activities and click OK. There are a bunch of activities available, but the only one you really need is “AssociateMergedChangesetsAndWorkItems”.
Now scroll down to the If called “If AssociateChangesetsAndWorkItems” (this is the default one in the workflow). Just below the “AssociateChangesetsAndWorkItems” activity, add an If (where condition is "IncludeMerges = True") and then drop an “AssociateMergedChangesetsAndWorkItems” into the "Then" side as follows:
Set the properties of the "AssociateMergedChangesetsAndWorkItems" activity as follows:
- AssociatedChangesets: set to associatedChangesets (this is the Result of the previous activity)
- AssociateMerges: set to IncludeMerges, the Argument you created earlier
- Result: set to associatedMergedChangesets, the Variable you created earlier
- UpdateWorkItems: set to True
Make sure the project builds, and check in.
You’re now ready to run the build. Either create a new build definition or simply change the template of an existing build from the Default template to your newly customized template. Then go check in, merge and build.
So for an example, I have User Story 43, which has a child Task 44. I work on the DEV branch and check in against Task 44 (changeset 97). I then make another DEV change, no work item (changeset 98). I then merge to MAIN (merging changes 97 and 98) in changeset 99. I then merge from MAIN to LIVE in changeset 100.
Now if you had this scenario and ran the “old” template, you’d get 1 associated changeset (100) and no associated work items. However, running your new flashy “merge-aware” template, you get 4 associated changesets and 2 associated work items (see the build output below).
This does mean that the work items may end up having been associated with 2 (or more) builds. Let’s say you have a DEV build (for CI). In the example above, Task 44 would have its “IntegratedIn” in set to the DEV build. Then you merge DEV to MAIN and MAIN to LIVE, and run the merge workflow on the LIVE branch. The workflow will update the “IntegratedIn” field of Task 44 to the LIVE build. You’ll still see both associations in the History, but the Task’s “IntegratedIn” field is now updated to the latest build (the LIVE build) – which may or may not be what you want. For me, it makes sense this way. Now the build report is a REAL change-log (not just a log of the merge changesets).
Unfortunately this activity won't work with the Default build template in TFS 2013 Preview. There may be a change that allows this to work in the RTM of TFS 2013.
Fortunately, there is a workaround. Simply copy your template (which includes the merge activity) from TFS 2012 to your 2013 Preview server, and create builds using this template. Of course if you upgraded from TFS 2012, you will have this template available immediately, so you won't have to copy it