Adding Integration Fields in Work Item Types
The Team Foundation work item tracking system integrates with other components of Team Foundation Server and Visual Studio Team System. To obtain maximum benefit out of the integration among components, you use certain fields and actions in work item types. This topic describes how you use those required fields and actions in the following sections:
Integration with Team Build
Integration with Visual Studio Test Tools
Integration with Team Foundation Source Control
Integration with Team Foundation Build
Team Foundation Build is the automated build system of Team Foundation Server. You can configure your build process using Team Foundation Build. Team Foundation Build can generate work items when a build fails, and it can also add build information to work items that were resolved in a particular build. For this to work, Team Foundation Build requires following two fields: Found In and Integration Build.
Adding the Found in Field
Team Foundation Build creates a new work item when a build fails, and sets the Found In field to the build number of the build that just failed. The Found In field must be present in the work item type that you want Team Foundation Build to create when a build fails. If the Found In field is missing, Team Foundation Build does not create a work item for the failed build, and everything else works as expected.
The following table summarizes the names and values of Found In field attributes.
Attribute Name |
Attribute Value |
RefName |
Microsoft.VSTS.Build.FoundIn |
Name |
Can be set to anything because integrations work based on field reference names, not field names. |
Type |
String |
Example of the Found In Field
<FIELD name="Found In" refname="Microsoft.VSTS.Build.FoundIn" type="String" reportable="dimension">
<HELPTEXT>Product build number (revision) in which this item was found</HELPTEXT>
</FIELD>
Adding the Integration Build Field
Team Foundation Build identifies work items that were resolved with each build and then updates those work items to set the build number in which they were resolved. It set the build number in the Integration Build field. If the Integration Build field is missing, Team Foundation Build does not store the build number in the work items, and everything else works as expected.
The following table summarizes the names and values of Integration Build field attributes.
Attribute Name |
Attribute Value |
RefName |
Microsoft.VSTS.Build.IntegrationBuild |
Name |
Can be set to anything because integrations work based on field reference names, not field names. |
Type |
String |
Example of the Integration Build Field
<FIELD name="Integration Build" refname="Microsoft.VSTS.Build.IntegrationBuild" type="String" reportable="dimension">
<HELPTEXT>Product build number this bug was fixed in</HELPTEXT>
</FIELD>
Integration with Visual Studio Test Tools
Some editions of Visual Studio include testing tools that are integrated into the development environment. One feature available in the testing tools is the ability to create new work items when a test fails. To do this, in the Test Results window, right-click the test result for which you want to create a bug, point to Create Work Item, and then click the type of work item you want to create, such as Bug. For more information, see How to: Create a Work Item from a Test Result.
When a work item has been created in this manner, three fields can be populated automatically to provide information about the test failure. The three fields are TestName, TestId, and TestPath. The Test Edition set these three fields with specific information about the test that failed. If the TestName, TestId, and TestPath fields are missing from the work item, the fields are not set, and everything else works as expected.
The following table summarizes the names and values of the attributes of these three fields.
Attribute Name |
Attribute Value |
RefName |
Microsoft.VSTS.Test.TestName, Microsoft.VSTS.Test.TestId, Microsoft.VSTS.Test.TestPath |
Name |
Can be set to anything because integrations work based on field reference names, not field names. |
Type |
String |
Example of the TestName, TestId, and TestPath fields
<FIELD name="Test Name" refname="Microsoft.VSTS.Test.TestName" type="String" reportable="detail">
<HELPTEXT>The name of the test that found this bug</HELPTEXT>
</FIELD>
<FIELD name="Test Id" refname="Microsoft.VSTS.Test.TestId" type="String" reportable="detail">
<HELPTEXT>The Id of the test that found this bug</HELPTEXT>
</FIELD>
<FIELD name="Test Path" refname="Microsoft.VSTS.Test.TestPath" type="String" reportable="detail">
<HELPTEXT>The full pathname of the test that found this bug</HELPTEXT>
Integration with Team Foundation Source Control
One of the features of Team Foundation version control is that you can associate or resolve work items while you check in code. You might have worked on a particular work item when making a particular code change and you can set that association from within the source-control check-in window when you are finished working on the code.
The ability of Team Foundation version control to resolve a work item requires that work items contain a particular action. The source control system then queries work item tracking to determine whether the work item supports that action, and if it does support that action, it also queries for the source and destination states of the transition. If the action is found, then the source control system can transition the work item according to the set transition while it checks in the code.
Note
When you use the Checkin action, you must set appropriate ‘from’ and ‘to’ states to reflect the state transition that you want.
For more information about Actions, see Associating a State Transition with an Action and Transition Action Details.
Example of the Checkin Action
<TRANSITION from="Active" to="Resolved">
....
<ACTIONS>
<ACTION value="Microsoft.VSTS.Actions.Checkin"/>
</ACTIONS>
....
</TRANSITION>
See Also
Tasks
How to: Create a Work Item from a Test Result
Concepts
Associating a State Transition with an Action