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.
Note
You access dashboards through your team project portal. You can access the Build dashboard only if that portal has been enabled and is provisioned to use Microsoft Office SharePoint Server 2007. For more information, see Dashboards (Agile) or Access a Team Project Portal and Process Guidance.
In this topic
|
You can use this dashboard to answer the following questions:
|
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.
Note
Code coverage and churn charts, reports and , do not appear when the data warehouse for the team project is not available.
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. |
||
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. |
||
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 |
||
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. |
||
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. |
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 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 Using 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 Using Test Settings for Automated Tests.
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 Basic Build Definition and Run and Monitor 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: