Monitoring and Analyzing Builds

Build information is provided in Visual Studio through the Team Build Browser. This browser window provides a list of completed or in-flight builds, and it functions as the principal mechanism for viewing build progress or completed summary reports.

Introducing the Team Build Browser

The Team Build Browser, shown in Figure 23.14, provides a snapshot of any build by indicating whether it succeeded, failed, or is in progress; the name of the build; the quality of the build; and the date it was completed.

Figure 23.14. The Team Build Browser.

Tip

If you or other members of the project team want to be notified when a build has been completed, you can use the Team Foundation Server project alerts feature. TFS defines two build-related events that you can subscribe to: Build Completed and Build Quality Changed.

The browser enables you to access the report for a specific build and set the build's quality state.

Setting a Build's Quality State

Team Foundation Build comes with a stock set of quality states that the QA group can select from when indicating the quality of a given build:

• Initial Test Passed

• Lab Test Passed

• Ready for Deployment

• Ready for Initial Test

• Rejected

• Released

• UAT Passed

• Under Investigation

• Unexamined

As part of the build process, the QA group would visit the Team Build Browser and change a build's quality state to indicate to the rest of the team what their tests have found. You can do this quite easily by clicking in the column and selecting one of the states, as shown in Figure 23.15.

Figure 23.15. Setting the build quality state.

In addition to the stock quality states, you can also add your own. Just select the Edit option in the Build Quality drop-down. Using the Edit Build Quality dialog box (see Figure 23.16), you can add new states or remove one of the existing ones.

Figure 23.16. Adding a new build quality state.

The Build Report

To view reports for both in-progress and completed builds, you double-click the build within the Team Build Browser.

Each report is hosted within a document window opened in Visual Studio and has the following sections:

• Summary Summarizes the details of the build and includes data points such as the build name, the person who requested the build, the machine that executed the build, the current quality state of the build, and a link to the build log.

• Build steps Contains a list (which is dynamic if the build is in progress) that provides date and time stamp information for each stage of the build.

• Result details Contains errors and warnings generated by the build, the results of any tests run with the build, and the code coverage results.

• Associated changesets Contains a hyperlinked list of any changesets that were a part of the build.

• Associated work items Provides a hyperlinked list of any work items that were associated with the build.

Figure 23.17 shows a build report open in Visual Studio.

Figure 23.17. A build report.

Work items once again provide a correlation mechanism for associating builds and other team project artifacts. For example, consider the following chain of information:

1.	A developer fixes a bug and checks in its changes to the source control system.
2.	The bug work item with the changeset is created from the check-in.
3.	Because the changeset is associated with the work item, and builds work against changesets within the source repository, you can now easily tell which bugs have been fixed in what build.