Lately, we have been doing a lot of changes to our internal processes... something we noticed lately is that it would be useful to track the build-breakages seperately from bugs. While they are bugs, they tend to require different attention that "regular" bugs (priority-wise, and sometimes even staff-wise).
Ultimately, we decided to treat a build failure as a different work item type so that it doesn't clutter the bug reporting and management that we do on a day-to-day basis. As such, the simpliest way to do this was to clone the 'bug' work item type to make a 'build failure' Work Item Type.
1. Export the Bug WorkItem Type
2. Rename the XML File exported to BuildFailure.xml
3. Modify the BuildFailure.xml to have a new Name/Description
<WORKITEMTYPE name="Build Failure"> <DESCRIPTION>Describes a failure that occurs during the Build and Build Verification Processes.</DESCRIPTION>
4. Import the new Work Item Type
5. Update your build process template, locate this snippet of code (in my template it was at about line 250)
<mtbwa:InvokeForReason DisplayName="Create Work Item for non-Shelveset Builds" Reason="Manual, IndividualCI, BatchedCI, Schedule, ScheduleForced, UserCreated"> <mtbwa:OpenWorkItem AssignedTo="[BuildDetail.RequestedFor]" Comment="["This work item was created by TFS Build on a build failure."]" CustomFields="[New Dictionary(Of String, String) From { {"System.Reason", "Build Failure"}, {"Microsoft.VSTS.TCM.ReproSteps", "Start the build using TFS Build"}, {"Priority", "1"}, {"Severity", "1 - Critical"} }]" DisplayName="Create Work Item" Title="[String.Format("Build Failure in Build: {0}", BuildDetail.BuildNumber)]" Type="["Bug"]" /> </mtbwa:InvokeForReason>
Change the work item type to be 'Build Falure', or whatever name you specified in Step 3 above.
6. Update the Categories to indicate that Build Failure is a type of Category.
witadmin exportcategories /collection:%Collection% /p:%Project% /f:"C:\categories.xml"
- Modify the resulting categories.xml file as follows:
<CATEGORY name="Bug Category" refname="Microsoft.BugCategory"> <DEFAULTWORKITEMTYPE name="Bug" /> <WORKITEMTYPE name="Build Failure" /> </CATEGORY>
- Import the update category list
witadmin importcategories /collection:%Collection% /p:%Project% /f:"C:\categories.xml"
I generally place some of the more common commands in a batch file, then have another that sets up the target. In this case, the target-setting batch file would have contents like this:
Set Collection=http://TFSServer:8080/tfs/MyProjectCollection
Set Project=MyProject
You can create a query that returns work items by category, for example after you have performed the above steps, a query that would return all of the Build Failures and bugs would look like this:
After we started using this for a while, we decided to change the Assigned To field so that it could contain the value of Not Assigned. We also changed the Transition to the Resolved state to set the Assigned to to Not Assigned; the default behavior was to set it to the creator, but this would set it to the TFS Build Service Account, and that user is not part of the 'assignable' users. We'll probably come back and revist this at a later time...
Subscribe