Analyzing Build Details and Build Coverage Using the Build Perspective
By using the Build perspective, you can view just the measures, dimensions, and attributes in the SQL Server Analysis Services cube for Visual Studio Team Foundation Server that pertain to the build process. For example, you can use these measures to determine how many builds are failing and how much of the code changed within a build.
The Build perspective is based on the relational tables that enable reporting on builds as either a property of the build, code coverage, or a changeset in version control. For more information, see Build Details Tables, Build Project Tables, Build Coverage Tables, and Build Changeset Tables.
.png "Build Measure Group") |
By using the Build perspective, you can create reports that answer the following questions: Status reports:
Trend reports:
.gif "Note") Note
If your data warehouse for Visual Studio Application Lifecycle Management (ALM) is using SQL Server Enterprise Edition, the list of cubes will include Team System and a set of perspectives. The perspectives provide a focused view of the data so that you do not have to scroll through all of the dimensions and measure groups that are defined for the whole Team System cube.
|
In this topic
Example: Build Status Report
Build Measures
Dimensions and Attributes in the Build Perspective that Support Filtering and Categorization
Required Activities to Manage Builds and Tests
Example: Build Status Report
By using PivotChart reports in Excel, you can display the build status over time, similar to the data in the following illustration.
.png "Build Status report")
The process templates for Microsoft Solutions Framework (MSF) v5.0 include the Build Status report in Excel. For more information, see Build Status Excel Report.
Back to top
Pivot Field Selection and Filters
.png "Pivot Fields for Build Summary Status report")
You can create the summary report for build status by performing the following steps:
In Excel, connect to the Analysis Services cube for Team Foundation Server, and insert a PivotChart report.
For more information, see Create a Report in Microsoft Excel for Visual Studio ALM.
Right-click the chart, click Change Chart Type, click Area, and then click Stacked Column.
For each report filter, right-click each of the following fields, specify the hierarchies, weeks, or other elements of interest, and then drag the field to the Report Filter area.
Team Project Hierarchy from the Team Project dimension
Year Week Date from the Date dimension
Build Definition Name from the Build dimension
In the Date dimension, expand More fields, and drag the Date, Week, or Month fields to the Axis Fields (Categories) area to specify how granular a report you want to generate.
Drag the Build Details Count field from the Build Details measure group to the Values area.
Drag the Build Status Name field from the Build Status dimension to the Legend Fields (Series) area.
(Optional) Filter the Build Status Name field to display only those builds that Failed, Partially Succeeded, or Succeeded.
Back to top
Build Measures
The following table describes the measures that are associated with builds. The Build Coverage measure group requires that the test team instrument tests to gather code coverage data. For more information, see Required Activities for Managing Builds and Tests later in this topic. For an example of a report that uses several of these measures, see Build Quality Indicators Report.
Measure Group |
Measure |
Description |
|---|---|---|
Build Details |
Build Details Count |
Number of times that a specific build has been run. |
Build Duration |
Number of minutes that the build took to finish. |
|
Build Changeset |
Build Changeset Count |
Number of changesets in the selected set of builds. |
Build Coverage |
Blocks Covered |
Number of blocks that the selected build covers. If multiple test runs are performed against a build, the build coverage reflects the combined coverage of the runs. However, the runs may cover blocks that overlap. |
Blocks Not Covered |
Number of blocks that the selected build does not cover. If multiple test runs are performed against a build, the build coverage reflects the combined coverage of the runs. However, the runs may cover blocks that overlap. |
|
Build Coverage |
Number of builds that are associated with code coverage statistics. |
|
Lines Covered |
Number of lines that the selected build covers. If multiple test runs are performed against a build, the build coverage reflects the combined coverage of the runs. However, the runs may cover lines that overlap. |
|
Lines Not Covered |
Number of lines that the selected build does not cover. If multiple test runs are performed against a build, the build coverage reflects the combined coverage of the runs. However, the runs might cover lines that overlap. |
|
Lines Partially Covered |
Number of lines that the selected build partially covers. If multiple test runs are performed against a build, the build coverage reflects the combined coverage of the runs. However, the runs might cover lines that overlap. |
|
Build Project |
Build Project Count |
Number of .csproj files, .vbproj files, and other project files in the selected set of builds. |
Compile Errors |
Number of compile errors that occurred for the selected builds. |
|
Compile Warnings |
Number of compile warnings that occurred for the selected builds. |
|
Static Analysis Errors |
Number of static analysis errors that occurred for the selected builds. |
|
Static Analysis Warnings |
Number of static analysis warnings that occurred for the selected builds. |
Back to top
Dimensions and Attributes in the Build Perspective that Support Filtering and Categorization
You can use the attributes in the following table to aggregate a measure, filter a report, or specify a report axis. These attributes supplement the Team Project and Date shared dimensions that Working with Shared Dimensions describes.
Note
To use the Assembly, Build Flavor, or Build Platform dimension attributes, the test team must publish the test results to the data store for Team Foundation Server. For more information, see Required Activities for Managing Builds and Tests later in this topic.
Dimension |
Attribute |
Description |
|---|---|---|
Assembly |
Assembly |
(Published test results only) The name of the code of the application that is tested as part of the build. For more information, see Use Your Build System to Work with Tests. |
Build |
Build Definition Name |
Name that is assigned to the build definition for which a build was executed. |
Build ID |
The number that is assigned to the build. Each time that a particular build definition is run, the Build ID is incremented by 1. |
|
Build Name |
The name or expression that uniquely identifies a build. For more information, see Work with Build Numbers. |
|
Build Start Time |
The date and time when the build started. |
|
Build Type |
The reason why the build was run. Build types are associated with the trigger that was defined for the build. Team Foundation Server supports the following types of builds: manual, continuous (triggered by every check-in), rolling (accumulate check-ins until the previous build finishes), gated check-in, and scheduled. For more information, see Specify Build Triggers and Reasons. |
|
Drop Location |
The Uniform Resource Locator (URL) for the completed build. A URL specifies the protocol with which web browsers will to locate Internet resources. Each URL includes the name of the server on which the details of the build resides. You can also include the path to a resource. |
|
Build Flavor |
Build Flavor |
(Published test results only) A name that designates the category of builds that was assigned to a set of completed builds that were published as part of a test run. For example, a build flavor can designate a beta release or final release. For more information, see Command-Line Options for Publishing Test Results. |
Build Platform |
Build Platform |
The name of the platform for which an end-to-end (not desktop) build was made (for example, x86 or Any CPU). For an example of a report that uses this attribute, see Build Summary Report. For more information, see Define a Build Using the Default Template. |
Build Quality |
Build Quality |
The quality of the build. For example, you can rate a completed build's quality as Ready for Deployment, Rejected, or Under Investigation. For more information, see Add or Remove Build Quality Values. |
Build Status |
Build Status Name |
The current state of the build. Valid values are Failed, Partially Succeeded, Stopped, Succeeded, and Unknown. For more information, see Use Build Explorer to View and Manage Queued, Ongoing, and Completed Builds. |
Build Source Project File |
File Hierarchy |
The full network path of the source file. |
File Extension |
The extension of the name of the source file. |
|
Version Control Changeset |
Changeset ID |
The number that is assigned to the changeset. |
Checked In By |
The user name of the team member who checked in the changeset. |
|
Description |
The check-in comment that is associated with the changeset. |
|
Policy Override Comment |
The comment that is provided when a policy is overridden. If a policy was not overridden with a changeset, the field is null. |
Back to top
Required Activities to Manage Builds and Tests
To create build reports that contain useful data, team members must perform the following activities to manage builds and tests:
Configure a build system. To use Team Foundation Build, the team must set up a build system.
For more information, see Configure Your Build System.
Create build definitions. The team must create at least one build definition. The team can create several definitions, each of which can be run to produce code for a different platform or a different configuration.
For more information, see Create a Basic Build Definition.
(Recommended) Run builds regularly. The team can automatically run builds at intervals that they specify or after every check-in. By using the schedule trigger, the team can automatically run builds at the same time or times on the same day or days that they specify.
For more information, see Specify Build Triggers and Reasons and Run and Monitor Builds.
(Optional) Rate completed builds. To populate the Build Quality dimension with useful information, a team member must manually rate a build by using Build Explorer.
For more information, see Rate the Quality of a Completed Build.
(Optional) Define tests to run automatically as part of the build. As part of the build definition, the team can define automated tests to run as part of the build and analyze the impact of code changes on tests.
For more information, see Define a Build Using the Default Template.
(Optional) Configure tests to gather code coverage data. For code coverage data to appear in the report, team members must instrument tests to gather that data.
Important
To collect data about code coverage, the team must install Visual Studio Premium or Visual Studio Ultimate on the build agent machine. For more information, see Create and Work with Build Agents.
For more information, see How to: Configure Code Coverage Using Test Settings for Automated Tests and How to: Gather Code-Coverage Data with Generic Tests.
Publish tests. As the team tests builds, it must publish the results of those tests to the data store for Team Foundation Server.
For more information, see Team Foundation Build Activities and Command-Line Options for Publishing Test Results.
Back to top
See Also
Concepts
Perspectives and Measure Groups Provided in the Analysis Services Cube for Team System
Other Resources
Use Your Build System to Work with Tests
Change History
Date |
History |
Reason |
|---|---|---|
|
July 2011 |
Rewritten for clarity and completeness. |
Information enhancement. |