Build Status Excel Report
TFS 2017 | TFS 2015 | TFS 2013
The Build Status report helps the team track the progress of their builds by showing the number of builds that failed or succeeded for the most recent four weeks.
This report is only applicable for XAML builds, which are deprecated for TFS 2018 and later versions. If your build process isn't based on XAML builds, this report and the TFS Warehouse for builds won't yield any meaningful data.
For information about how to access this report, see Excel reports.
You can view the Build Status report from the Quality dashboard. You can access this dashboard only if your team project portal has been enabled and is provisioned to use Microsoft Office SharePoint Server 2007. For more information, see Configure or redirect process guidance.
To view the report, 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 or customize the report, you must be a member of the TfsWarehouseDataReaders security role in SQL Server Analysis Services. You must also 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 Team System]/azure/devops/report/admin/grant-permissions-to-reports.md).
Data in the report
The team can review the Build Status report to help determine the trend of build health over time and whether any builds need attention today. As the following illustration shows, the report provides a stacked column of the number of builds that were run with an outcome of failed, passed, or unknown during the most recent two weeks.
The chart is based on a PivotTable from data that is stored in the Analysis Services database.
Required activities for tracking build status
For the Build Status report 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 Build and Release agents.
Create build pipelines. You can create several build pipelines and then run each of them to produce code for a different platform. Also, you can run each build pipeline for a different configuration.
For more information, see Get started with CI/CD.
Run builds regularly. You can run builds at set intervals or after every check-in. You can create regular builds when you use the schedule trigger.
For more information, see Build triggers.
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]/azure/devops/report/sql-reports/build-summary-report.md).
Interpret the report
You can use the Builds Status report to gain insight into the following questions:
- How is my team's build health changing over time?
- Do any builds need attention today?
Customize the report
You can customize the Builds Status report by opening it in Office Excel and changing the filter options or a column field list for the PivotTable report. You can modify the report to support other views, as the following table describes.
|Build results for an iteration||Change the filter for WorkItem.Iteration (default=All)|
|Build results for a product area||Change the filter for WorkItem.Area (default=All)|
|Build results for the most recent six, eight, or more weeks||In the Columns PivotTable Field List, replace @@Last 4 weeks@@ with a different Set|