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.

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 Access to the Databases of the Data Warehouse for Visual Studio ALM.

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. For more information, see Managing Permissions.

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. This dashboard displays the Web parts that the illustration shows and the table describes.

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 checkins before the build within the most recent four weeks.	Code Churn Excel Report (CMMI)
	List of recent builds and their build status. You can view more details by clicking a specific build. This list is derived from a Team Web Access Web part. Legend: : Build in Progress : Build Not Started : Build Succeeded : Build Failed : Build Stopped : Build Partially Succeeded	Managing and Reporting on 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 clicking each number. This list is derived from a Team Web Access Web part.	Work Items and Workflow (Agile)
	List of the most recent check-ins. You can view more details by clicking a specific checkin. 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 Configuring 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 Define a Build Process that is Based on the Default Template.

• 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 How to: Configure Code Coverage (Visual Studio 2010) Using Test Settings in Visual Studio.

• 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 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 Web site:

• 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

See Also

Concepts

Dashboards (Agile)

Artifacts (Agile)

Other Resources

Scrum Processes

Reports (Agile)