Share via


Build Summary Report

The Build Summary lists builds and provides information about test results, test coverage, code churn, and quality notes for each build.

For information about how to access, refresh, or manage reports, see Reports (Agile).

Note

This report requires that the team project collection that contains your team project was provisioned with SQL Server Reporting Services. This report is not available if Report Reports does not appear when you open Team Explorer and expand your team project node. 

In this topic

  • Data in the Report

  • Setting the Duration of the Iteration

  • Interpreting the Report

  • Filtering the Report

You can use this report to answer the following questions:

  • What is the status of all builds over time?

  • Which builds succeeded?

  • Which builds have a significant number of changes to the code?

  • How much of the code was executed by the tests?

  • Which builds are ready to install?

Required Permissions

To view the report, you must be assigned or belong to a group that has been assigned the Browser role in Reporting Services. For more information, see Add Users to Team Projects or Managing Permissions.

Data in the Report

The data that appears in the Build Summary report is derived from the data warehouse. The report presents a visual display of the percentage of tests that are passing, code that is being tested, and changes in code across several builds.

You can review the results for both manual and automatic builds, in addition to the most recent builds and continuous or frequent builds. The report lists the most recent builds first and contains build results that were captured during the specified time interval for all builds that were run, subject to the filters that you specified for the report.

At a glance, you can determine the success or failure of several build definitions for the time period under review, as the following illustration shows.

Example Build Summary report

The following table describes the information that appears for each quality indicator:

Quality indicator

Description

Build Progress

Specifies the status of the build. A build can be in one of the following states:

  • Failed. The build failed to compile or tests failed to pass.

  • Partially Succeeded. Only some portions of the build successfully compiled.

  • Stopped. The build was manually stopped.

  • Succeeded. The build successfully compiled, and tests ran.

Build Quality

Specifies a manually assigned assessment of the quality of the build. You can add or remove the build qualities that are defined for your team project. For more information, see Add or Remove Build Quality Values.

The column is empty if the build quality has not been rated.

% Tests Passed

Displays a horizontal stacked bar chart that lists the percentage of tests that passed superimposed on a green bar. The remaining bar segment is red, which indicates the percentage of tests that failed. The total length of the chart always equals the width of the column.

% Code Coverage

Displays a horizontal stacked bar chart that lists the percentage of code that was covered superimposed on a green bar. The remaining bar segment is light blue, which indicates the percentage of code that was not tested in the build. The total length of the chart always equals the width of the column.

% Code Churn (lines)

Displays a horizontal bar chart that lists the percentage of code churn superimposed on a gray bar. The code churn is calculated by determining the number of lines of code that the team has added, deleted, or modified divided by the total number of lines in the build. The bar length is proportionate to the percentage figure, scaled across the report so that the maximum amount of code churn across all builds equals the width of the column.

You can filter the Build Summary report in the following ways:

  • Change the start and end dates for the report.

  • Filter the build definitions by specifying the platforms, configurations, build definitions, build qualities, or build progress to include in the report.

For more information, see Filtering the Report later in this topic.

Required Build Management Activities

For the Build Summary report to be useful, team members must perform the following activities to manage builds:

Setting the Duration of the Iteration

To understand the progress that the team is making in your current iteration, you must set the start and end dates for the report to match those of your current iteration cycle.

To change the duration of the iteration

  1. Next to Iteration Start (Date) or Iteration End (Date), click the calendar icon, and then click a date.

  2. Click View Report.

Interpreting the Report

You can review the Build Summary report to answer questions about the most recent builds. It contains more information than the Build Success Over Time report.

Questions That the Report Answers

You can use this report to find answers to these questions:

  • What is the status of all builds over time?

  • Which builds succeeded?

  • Which builds have a significant number of changes to the code?

  • Which builds are ready to install?

  • How much of the code did the tests execute?

The Build Summary report does not indicate the causes of problems, but it points to where you can look to determine the root cause of problems. This report also does not indicate the size or significance of build problems.

Healthy Version of Report

A healthy Build Summary report show the following indicators:

  • Most builds are passing.

  • Most tests are passing.

  • Code coverage is high.

  • Code churn shows few spikes.

Unhealthy Version of Report

An unhealthy version of the Build Summary report will show one or more of the following indicators. You may want to investigate according to the following guidance:

  • Many builds are failing. Investigate reasons why builds are failing.

  • Many tests are failing. Investigate and fix tests that are failing to pass.

  • Code coverage is mostly blue. You might want to write more automatic tests.

  • Code churn shows spikes. You might want to verify that unusual peaks are accounted for.

Filtering the Report

You can filter the Build Summary report in the following ways:

  • Change the start and end dates for the report.

  • Filter the set of builds that are represented in the report by specifying the platform, configuration, build definition, build quality, and build progress to include in the report.

    Note

    You can configure build definitions to run no tests, some tests, or all tests. The report will vary greatly based on the configuration of the build definitions.

The following illustration shows the available filters:

Filters for Build Summary report

You must apply the filters in the sequence that the following procedure specifies. The options that are available with some filters depend on the filters that you previously set.

To filter the builds that appear in the report

  1. In the Platform list, select the check box of each platform to include.

  2. In the Configuration list, select the check box of each configuration to include.

  3. In the Build Definition list, select the check box of each build definition to include.

  4. In the Build Quality list, select the check box of each build quality to include.

  5. In the Progress list, select the check box of each build progress to include.

  6. Click View Report.

See Also

Concepts

Build Quality Indicators Report

Build Success Over Time Report

Stories Progress Report (Agile)

Other Resources

View Build Results

Reports (Agile)