Build dashboard (Agile)

You can use the Build dashboard to obtain an overview of the development activities that are affecting the quality of the builds. Nightly builds are important to software development projects. When builds are not completing successfully or are not passing build verification tests (BVT), the team must fix the problem immediately.

You access dashboards through your team project portal. You can access the Build dashboard only if that portal has been enabled and is configured to use SharePoint Server Enterprise Edition. For more information, see Dashboards.

Required permissions

To view the dashboard, you must be assigned or belong to a group that has been assigned the Read permissions in SharePoint Products for the team project. To modify, copy, or customize a dashboard, you must be assigned or belong to a group that has been assigned the Members permissions in SharePoint Products for the team project. For more information, see Add users to team projects.

To modify an Excel report, you must be a member of the TfsWarehouseDataReaders security role in SQL Server Analysis Services, and you must be assigned or belong to a group that has been assigned the Members permissions in SharePoint Products for the team project. For more information, see Grant permissions to view or create reports in TFS.

To view a work item, you must be a member of the Readers group or your View work items in this node must be set to Allow. To create or modify a work item, you must be a member of the Contributors group or your Edit work items in this node permissions must be set to Allow.

Data displayed in the dashboard

The team can use the Build dashboard to monitor the quality of builds and determine whether a member of the team must take specific steps to correct build failures. To learn about the Web Parts that are displayed on the Build dashboard, refer to the illustration and the table that follow.

Web Part	Data displayed	Related topic
	Line chart that depicts the percentage of code that was tested by build verification tests (BVT) and other tests over the most recent four weeks.	Code Coverage Excel Report
	Stacked area chart that depicts how many lines of code the team added, removed, and changed in the check-ins before the build within the most recent four weeks.	Code Churn Excel Report
	List of recent builds and their build status. You can view more details by choosing a specific build. This list is derived from a Team Web Access Web Part. Legend: : Build Not Started : Build in Progress : Build Succeeded : Build Failed : Build Stopped : Build Partially Succeeded	Run, monitor, and manage builds
	List of upcoming events derived from a SharePoint Web Part.	Not applicable
	Count of active, resolved, and closed work items. You can open the list of work items by choosing each number. This list is derived from a Team Web Access Web Part.	Not applicable
	List of the most recent check-ins. You can view more details by choosing a specific check-in. This list is derived from a Team Web Access Web Part.	Develop code and manage pending changes

Required activities for tracking builds

For the reports shown in the Build dashboard to be useful and accurate, the team must perform the following activities:

• Configure a build system. To use Team Foundation Build, you must set up a build system.

  For more information, see Configure and manage your build system.

• Create build definitions. You can create several build definitions and then run each of them to produce code for a different platform. Also, you can run each build for a different configuration.

  For more information, see Define your build process.

• Define tests to run automatically as part of the build. As part of the build definition, you can define tests to run as part of the build or to fail if the tests fail.

  For more information, see Use the Default Template for your build process.

• 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.

  For more information, see Run tests in your build process.

• Run builds regularly. You can run builds at regular intervals or after every check-in. You can create regular builds when you use the schedule trigger.

  For more information, see Create or edit a build definition and Run, monitor, and manage builds.

  Note

  Although a team member can manually rate a build by using Build Explorer, this rating is not reflected in the Build Quality Indicators report. The build rating appears in the Build Summary report. For more information, see Rate the quality of a completed build and Build Summary Report.

Monitoring builds

The team can use the Build dashboard to monitor the quality of builds and the level of code coverage that they are testing. Ideally, code coverage is high, and code churn is low or falling. Depending on your team goals, code coverage should be 80% to 100%.

You can use the Code Coverage and Code Churn reports to answer the questions that are listed in the following table.

• Which builds succeeded?

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

• How often are builds succeeding?

• How volatile is the code base?

• How much of the code is the team testing?

• How high is the quality of the builds?

• Is the quality increasing, decreasing, or staying constant?

For more information, see Code Coverage Excel Report and Code Churn Excel Report.

Customizing the Build dashboard

You can customize the Build dashboard in the following ways:

• Change the filters of each report in Office Excel to focus on specific product areas or iterations.

• Add existing Excel reports such as Builds Status or Bug Progress to the dashboard.

For more information about how to work with and customize Excel reports, see the following pages on the Microsoft website:

• Ways to customize PivotTable reports

• Edit or remove a workbook from Excel Services

• Publish a workbook to Excel Services

• Save a file to a SharePoint library or another Web location