Try JFrog
Guides
Contact SupportTry JFrog
  1. AppTrust
  2. AppTrust Ecosystem
  3. AppTrust Jira Integration

Development Promotion Process

The process of promoting application versions when using the Jira integration with JFrog AppTrust

When you use the Jira integration with JFrog AppTrust, promoting an application version (for example, to DEV, or any stage you defined in the setup) does more than move artifacts between repositories. AppTrust automatically collects Jira ticket information linked to the work in that release and attaches it as evidence on the application version. That evidence gives you an auditable record of items shipped with each promotion without manually copying ticket details into AppTrust.

The process spans your usual delivery tools: GitHub builds and publishes packages to JFrog Artifactory, AppTrust governs application versions and promotions, and Jira supplies context that AppTrust turns into evidence.

The promotion process, described in detail below, takes place in two phases:

  • First Application Version: For the first application version in a line of releases, AppTrust captures the original Jira ticket.
  • Subsequent Application Versions: On later versions, AppTrust captures only what changed since the previous version.

You can run most steps from your CI/CD pipeline (create versions, promote, release) or from the AppTrust UI. Evidence creation occurs automatically when you promote to any stage you defined in the setup.

Prerequisites

  • The Jira integration is configured and connected to your Jira instance.
  • Your CI/CD pipeline publishes packages to Artifactory and attaches SLSA provenance to builds (GitHub Actions or equivalent).
  • The GitHub–JFrog integration is set up so AppTrust can read commit messages referenced in provenance.
  • The lifecycle stages, such as DEV, QA, and PROD, are configured for the application (or at the global level).
  • Commit messages in the repositories that build your packages include Jira issue keys in a recognizable form (for example, PROJ-1234).

What you will see in AppTrust

As you move through the process, check these places in the AppTrust UI:

  • Lifecycle (Stages Board) — Shows which stage each application version is in (for example, DEV or PROD).
  • Version Timeline — Records version creation, promotions, and evidence events in chronological order.
  • Evidence — Lists Jira evidence attached to the version after promotion to DEV. Open an evidence item to review the tickets AppTrust collected.

First Application Version

The first iteration establishes your application in AppTrust and delivers the first release (for example, version 1.0.0) from build through DEV to PROD. Jira evidence for this version includes only the commit that was given in the attached SLSA provenance. The following steps occur in the first iteration.

1. Build and Publish Packages

In GitHub, you build your product (or your connected source control) and publish the resulting packages to Artifactory. Your pipeline should produce versioned artifacts ready for AppTrust to bind to an application version.

2. Attach Supply-Chain Attestation

During the build, SLSA provenance is generated and attached to the build output. AppTrust uses this provenance later to discover which commits—and therefore which Jira tickets—belong to the release. Ensure provenance is available for the packages you include in the application version.

3. Register the Application

If you already have an application defined, skip to Step 4.
If not, you create an application in AppTrust (using the UI, the REST API, or the CLI). This is a one-time step per product which defines the governance boundary for all versions of that software.

4. Create the First Application Version

In AppTrust, you create an application version (for example, 1.0.0) and bind it to the packages from Artifactory that represent this release candidate. The version starts in the Unassigned area of the lifecycle until you promote it.
For details, see Create an Application Version.

5. Promote to DEV

You promote the application version to the DEV stage. AppTrust runs policy checks for that stage, moves artifacts as configured, and updates the version’s position on the lifecycle board.
Promotion to DEV is the trigger for Jira evidence on the first iteration.

6. Review Jira Evidence (Automatic)

After promotion to DEV succeeds, AppTrust creates Jira evidence for the version. You do not start this step manually; it runs as part of the promotion flow.
AppTrust does the following:

  1. Reads the packages on the application version and their SLSA provenance from the platform data layer.
  2. Resolves commit messages for commits referenced in provenance, using the GitHub–JFrog integration.
  3. Extracts Jira issue keys from those commit messages (for example, PROJ-1234).
  4. Fetches ticket details from Jira (such as status, assignee, summary, and approval-related fields).
  5. Attaches an evidence record to the application version with the collected ticket data.

When processing finishes, open the version’s Version Timeline or Evidence view in AppTrust to confirm the new evidence item and review the linked tickets.

7. Release to PROD

When DEV and all the subsequent stages in the lifecycle are complete, you promote the same application finally to PROD. AppTrust treats this as the completion of the first release cycle for that version (for example, 1.0.0 is live in PROD).
Evidence from Step 6 remains on the version and continues to support audit and traceability for that release.

Subsequent Application Versions

Each new release (for example, 1.0.1 and higher) repeats a shorter path. You do not recreate the application. AppTrust still creates Jira evidence when you promote to DEV, but on later versions it records only incremental changes, for example, tickets tied to commits that were not part of the previous application version.

1. Build and Publish Updated Packages

In GitHub, you implement new work, run a new build, and upload updated packages to Artifactory with SLSA provenance, same as in the first iteration.

2. Create a New Application Version

In AppTrust, you create a new application version with a higher version identifier (for example, 1.0.1) and bind it to the new packages. The previous version (for example, 1.0.0) remains in AppTrust for history and comparison.

3. Promote the New Version to DEV

You promote the new version to DEV. This triggers incremental Jira evidence for the version.

4. Review Incremental Jira Evidence (Automatic)

AppTrust runs the same overall evidence workflow as on the first iteration, with one important difference. It compares the new version only to old versions which are currently in PROD (during the promotion) and processes only new commits from provenance, not the entire commit history again.

Earlier evidence on prior versions is unchanged. Each version accumulates its own evidence trail, focused on what that release introduced.

5. Release to PROD

You promote the new version to PROD when it is approved for release, same as in the first iteration.

Tips for Reliable Jira Evidence

  • Reference Jira in commits: Use consistent issue keys in commit messages so AppTrust can extract them (for example, PROJ-1234: Fix login timeout).
  • Keep provenance intact: Do not strip SLSA metadata from builds you bind to application versions.
  • Use sequential versions: Incremental evidence depends on AppTrust identifying the previous application version; use clear version numbering (for example, 1.0.0, 1.0.1).
  • Check the timeline after DEV promotion: If evidence is missing or incomplete, open the version timeline for errors and confirm integration connectivity before promoting to PROD.

Related Topics