DTP enables you to compare changes in the codebase as it evolves. If your organization builds software continuously, then using builds for comparison provides insight that wouldn't be possible using a traditional date-based approach to comparing data. The Build Administration page provides visibility into build activity and information stored in DTP. In this section:
Click on the Build Administration - Statistics widget to open the build administration page.
If you know the filter ID, you can manually enter the report URL:
http://<host>:<port>/grs/dtp/reports/builds?filterId=<id>
You can add a descriptive tag to a build, making it easier to identify from the build administration page. Tags added this way will appear below the build ID on the build administration page as well as in the build audit report. To add a descriptive tag, click the pencil icon next to the build ID and enter the desired descriptive text in the dialog that appears. Descriptions cannot exceed 128 characters.
You can lock a build to prevent DTP from accepting new reports tagged with the same build ID. Locked builds commonly mark the end of a development phase. You can archive a build to save the XML report files associated with a build ID, including the test and coverage details. DTP only keeps test and coverage details for the last two builds by default, but you may want to archive all data associated with a specific build so that existing test and coverage details are not deleted.
A build must be archived in order to download the XML, HTML, or PDF version of the report. See Build Audit Report for additional information. |
<DTP_DATA_DIR>/data/_DEFAULT_/dc/baselined/{build primary id}/{run id}
directory, where {build primary id}
is the ID (primary key) of the build in the database and {run id}
is the ID (primary key) of the run in the database. If the data associated with some runs becomes unreliable, you can search for builds associated with the compromised runs and use the REST API to delete the data from the database. For example, if the source control system goes offline, then authorship, branch information, and other data may lose integrity and have a negative impact on the effectiveness of reporting mechanisms in DTP. If the system under test (SUT) experiences a critical failure, the test results associated with runs that were executed during the failure may represent "noise" and not actual regressions.
Data removed from the database is at the build level, so all data associated with the build will be deleted--even if the removal occurs across different runs. By default, Parasoft code analysis and test execution tools generate unique builds daily, so deleting data associated with a build will likely result in deleting all data for that day.
Click on a build in the Build Administration page to open the Compliance Report for that ID. The Compliance Report shows all artifacts associated with a baselined build, such as environment attributes, test configuration used, and test results, so that you can understand how well the build is tested. See Build Audit Report for details.