Release Audit Report

This topic covers the audit report in Digital.ai Release, which provides full traceability and auditability for auditors. You can generate an audit report for releases that are in progress, completed, or archived.

For more information about how to generate the audit report, see Generate the audit report.

Requirements

Running multiple audit reports at the same time can increase memory usage. For example, complex releases can take up to 2 GB of memory.

tip

If you notice a drop in performance on your Release instance, try to increase the Java heap memory.

• SonarQube
• Fortify on Demand
• Black Duck
• ServiceNow
• Deploy
• Jira
• Jenkins
• Checkmarx
• Ansible

note

By default, Jira and Jenkins are bundled with the installation package, and only need to be upgraded if the user installed them separately. If you use any other custom or community plugins, these should also be updated to take advantage of the release audit report.

Audit Report Permissions

The global Auditor permission is required to generate and download the release audit reports.

For more information about permissions and how to add them, see Global permissions.

Store Reports

The generated audit reports are stored as temporary files on a shared file system. These reports are available for a default period of 10 days after they are generated. You cannot delete the reports manually from Release.

Set Retention Period

To configure the retention period for the generated reports in Release:

1. Go to Settings > General.
2. Under Release audit reports, in the Delete release audit report older than field, specify the maximum number of days the reports can be stored before automatically deleting them.

Types of Reports

• Single release - show all the information that happened in a release and additional data from tool integrations.
• Multiple releases - a .zip package containing a master report and one audit report for each of your filtered releases. The master report is an Excel file indexing all of the single-release report files in a .zip package.

Format

For a single release, you can export an Excel file containing information about the release.

For multiple releases, you can download a .zip package containing multiple Excel files with report information.

The report header shows the timezone used for the dates and times in the report. Audit reports use the Release server timezone, not your personal display timezone, so that timestamps are consistent for all auditors.

Contents

The contents of the report are displayed in separate sheets in the .xls file based on the type of data gathered from Release and the existing integrations.

Information Gathered from Release

• Release overview tab - Details about the release, including phases and tasks.

• Task details tab - Input and output information from the tasks in the release.

• Activity details tab - The activity log from Release.

Integrations Data

Plugin tasks provide additional information to help you understand what happened while the task was running and why it failed or passed. You can see data for any of these five categories as a separate sheet in your report:

• Plan tab - Shows the details for Jira tasks from Release including the Jira ticket number.

• Build tab - Shows the details for Jenkins tasks from Release and accessible build URLs from Jenkins.

• Security and Compliance tab - Shows the details for the SonarQube, SonarCloud, Fortify on Demand, and BlackDuck tasks including links to the corresponding projects.

• ITSM tab - Shows the details for ServiceNow tasks from Release and an accessible link to the project in ServiceNow.

• Deployments tab - Shows the details for Deploy tasks from Release and an accessible link to the deployment in Deploy.

Each sheet contains a set of columns that can be grouped into three lists.

1. Shared with other types of task-related sheets:
   • Phase
   • Task
   • Type
   • Status
   • Start date
   • End date
   • Duration
   • Assigned user
   • Assigned team
   • Completed by
2. Task specific:
   • Server url: Server base URL used to fetch data, not an object URL
   • Server user: Username used to authenticate to the server when fetching data
3. Unique to each type of task

Each type of task contains fields as follows:

1. Build (example: Jenkins)
   • Project: The name of the project
   • Build ID: The ID of the build
   • Build result: Result of the build
   • Build start: Start date of the build
   • Build end: End date of the build
   • Build duration: Duration of the build
2. ITSM (example: ServiceNow)
   • Record number: Unique identifier in ITSM
   • Record title: Title of the record in ITSM
   • Status: Status of the record
   • Priority: Priority of the record
   • Record created by: Record created by
3. Plan (example: Jira)
   • Ticket id: Ticket ID
   • Title: Issue title
   • Ticket type: Ticket type
   • Status: Status of the ticket
   • Updated on: Date and time of last update
   • Updated by: Person who performed the last update
4. Security and Compliance (example: SonarQube, SonarCloud, BlackDuck, Fortify, and Fortify on Demand)
   • Project: The project name
   • Analysis date: Date of the analysis
   • Compliance check: Result of the analysis
   • Compliance data: The compliance data
5. Deployment (example: Deploy)
   • Deployment task: The deployment task
   • Application: The application name
   • Environment: The environment name
   • Application version: The version of the application
   • Deployment status: The status of the deployment

Important: Only releases executed after 9.0.x will contain the audit report data.

User Permissions Data

The "Permissions" sheet of the report contains permissions relevant to the release (folder- or release-specific) that each user had between release start and end. For example, if the release started on a Monday and ended on a Wednesday, and on Tuesday user A was granted "edit task" permission for only 5 minutes before it was revoked, the report will still list that permission. The report does not specify the duration for which a user had a permission, only the fact that the user had the permission for some (or all) of the time while the release was in progress.

The Permissions report can reveal the source of a user's permission: for example, whether the user is a member of a folder team, or the user is a principal of a role and that role is a member of a team.

important

Only Release version 10.0.x is capable of keeping historical permission data. Release starts storing historical permission data only when you upgrade to 10.0.x for the first time. As a result, you can get valid data in your reports only for releases that happened after the date you upgraded to 10.0.x.

Example

If your release contains tasks producing this type of data, you will see a separate sheet in your release audit report named after the category that contains all tasks of that type in the release. Here is an example of a Security and Compliance sheet:

Phase	Task	Type	Status	Start date	End date	Duration	Assigned user	Assigned team	Completed by	Server url	Server user	Project	Analysis date	Compliance check	Compliance data
New Phase	blackduck	BlackDuck: Check Compliance	Failed	June 13, 2019 11:37 AM	June 13, 2019 12:00 PM	0d 0h 23m				https://blackduck.xebialabs.com	xebialabs	xebialabs_xl-deploy	June 12, 2019 06:03 PM	FAILED	License Risk: High: 18 Low: 0 Medium: 3 Operational Risk: High: 15 Low: 3 Medium: 17 Security Risk: High: 3 Low: 6 Medium: 3

note

The columns Server url and Project contain hyperlinks that point to the server and the project URL on that server, respectively.

The Project field which contains a hyperlink to the project is specific only for the Security and Compliance category. The same applies to Build ID in the Build category, Record number in ITSM, and Ticket id in the Plan category.