Add Fields to Support Integration with Test, Build, and Version Control

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. You can configure your build process by using Team Foundation Build, 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 that 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 for bugs. These fields associate bugs with the builds where they were found or fixed. You can use the following code snippet 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>

When the Found In field is present in the work item type definition, Team Foundation Build creates a work item when a build fails, 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.

When 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 to set 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 Field Reference.

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 in Microsoft Test Manager.

When a work item has been created in this manner, information about the system and the steps to reproduce the bug are captured in the System Info and Repro Steps fields.

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

<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 Field Reference.

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 Automate Field Assignments Based on State, Transition, or Reason.

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

Determine Your Process and Tracking Customization Requirements