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 the memory usage. For example, complex releases can take up to 2Gb of memory.

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

Recommended: If you are upgrading from a previous version to 9.0 or higher, you should also upgrade the following plugins to use the release audit report:

• 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.

Contents

The contents of the report is 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 has happened while running the task and why the task failed or passed. You can see data for any of these five categories as a separated 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 de 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 of users 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 have got "edit task" permission for 5 minutes only, and then permission was revoked, the report will still list that permission. Report will not specify duration for which user had permission, only the fact that user had permission for some (or all) time while release was in progress.

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

Important: Only version 10.0.x is capable of keeping historical permission data. Note, that only when you upgrade to 10.0.x first time, Release will start storing historical permission data, and, as a result, you will only be able to get valid data in your reports 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 with the category which contains all the tasks of that type in that 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 for Build id in the Build category, Record number in ITSM, and Ticket id in the Plan category.