Adding Integration Fields in Work Item Types

You can customize types of work items to contain information that is generated by automated processes by adding fields that integrate with Team Foundation Build, Microsoft Test Manager, and Team Foundation version control. 

In this topic

• Fields that Integrate with Team Build

• Fields that Integrate with Visual Studio Test Tools

• Fields that Integrate with Team Foundation Source Control

Fields that Integrate with Team Foundation Build

Team Foundation Build is the automated build system of Team Foundation Server, and Team Foundation Build can generate work items when a build fails. It can also add build information to work items that were resolved in a particular build. For this to work, Team Foundation Build requires the following two fields be added to the work item type definition: Found In and Integration Build.

In the default process templates that Team Foundation Server provides, Found In and Integrated in Build fields appear in the type definitions of bugs. These fields associate bugs with the builds where they were found or fixed. You can use the following code example to add these fields to a work item type definition.

<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>
<FIELD name="Integration Build" refname="Microsoft.VSTS.Build.IntegrationBuild" type="String" reportable="dimension">
    <HELPTEXT>Product build number this bug was fixed in</HELPTEXT>
</FIELD>

If the Found In field is present in the work item type definition, and a build fails, Team Foundation Build creates a work item and sets the Found In field to the build number of the build that just failed. 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.

If the Integration Build field is present in the work item type definition, Team Foundation Build identifies work items that were resolved with each build and then updates those work items by setting the build number in which they were resolved 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.

For more information, see Build and Test Integration.

Fields that Integrate with Microsoft Test Manager

With Test Manager, you can automate the creation of a bug or other type of work item when a test fails. For more information, see Submitting Bugs.

If Test Manager has automatically created a work item in this way, it records information about the system and the steps to reproduce the bug in the System Info and Repro Steps fields.

You can add these fields to work item types that you create for tracking defects by using the following code example.

<FIELD name="System Info" refname="Microsoft.VSTS.TCM.SystemInfo" type="HTML" />
<FIELD name="Repro Steps" refname="Microsoft.VSTS.TCM.ReproSteps" type="HTML" />

For more information about additional fields used by Test Manager, see Build and Test Integration.

Fields that Integrate with Team Foundation Version Control

One of the features available in Team Foundation version control enables you to associate or resolve work items when you check in code. You may have worked on a particular work item when you make a 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, the source control system can transition the work item according to the set transition when it checks in the code.

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

Concepts

Determining Which Builds Have Bug Fixes, New Features, or Requirements

Other Resources

Determining Your Process and Tracking Customization Requirements

Change History