RLM: Complete Walk Through

RLM: Complete Walk Through

Products
JFrog_Distribution
Content Type
User_Guide
AuthorFullName__c
Joshua Han
articleNumber
000006635
FirstPublishedDate
2025-09-21T09:06:13Z
lastModifiedDate
2025-09-21
VersionNumber
1
Key Benefits of Release Lifecycle Management 

A structured Release Lifecycle Management (RLM) process offers significant benefits:
  • immutable and auditable releases ensuring the tested software is what's released with a tamper-proof audit trail;
  • enhanced governance and control through environment definitions and Xray policies enforcing quality and security; 
  • improved security by integrating Xray for vulnerability scanning and using signed keys; 
  • and streamlined, automated workflows reducing errors and improving efficiency. 
This enables reliable and secure distribution of verified Release Bundles to any destination, including air-gapped environments, ensuring a secure software supply chain.

Phase 1: Administrative Setup


An administrator performs this initial setup, which is fundamental to the entire RLM workflow. If these are already configured, you can disregard these steps.


1. Create a Project (Recommended)
Projects are essential for organizing and isolating your resources. Creating a dedicated project for a software application or team provides better control over repositories, builds, and permissions, enhancing security and manageability.

In the Administration module, create a new project. When you create repositories and other resources, you can then associate them with this project.
2. Define Environments
Environments are the distinct stages of your software development lifecycle (SDLC). While default environments like DEV and PROD (Production) are provided, you can customize these to perfectly match your organization's workflow (e.g., QA, UAT, Performance Testing).

To create and configure custom environments, follow the instructions described in Manage Custom Environments. If the repository is part of a project, the project admin will need to assign the environment to one or more roles.

3. Create and Assign Repositories
You need repositories to store your artifacts, builds, or contents of Release Bundles. Each repository must be assigned to an environment to enforce the lifecycle. For example, a libs-dev-local repository would be where developers upload their initial builds, and it would be assigned to the DEV environment.

Create the required repositories for your build process. In each repository's settings, assign it to the appropriate environment. If using projects, create repositories under the project.

Phase 2: The Release Bundle Lifecycle - Create, Scan, and Promote


This is the core, iterative cycle of your release process.


1. Create a Build or Upload Artifacts
The source of any release is the set of artifacts produced by your build process. Using a CI/CD tool (like Jenkins or GitHub Actions) to integrate with Artifactory is the recommended way to publish your builds and their associated metadata (build info).

Configure your CI/CD pipeline to publish build info to your Artifactory project. Alternatively, you can manually upload artifacts to a repository in the initial (e.g., DEV) environment.
2. Create Signing Keys for Release Bundles (Optional) 
Each Release Bundle is signed to ensure its integrity. It is a security best practice to use a unique signing key for each project and, ideally, for each environment promotion.

Under the Administration > Security > Keys Management module, create and manage the signing keys that will be used for signing Release Bundles.
3. Create a Release Bundle
It is a signed, immutable collection of your software components that will be promoted across environments. You can create a bundle from various sources to fit your specific needs.

Via UI, REST API, or JFrog CLI:
  • Source Type - Builds: The most common method. Create a bundle directly from the build information published by your CI/CD tool.
  • Source Type - Release Bundles: Combine several existing Release Bundles into a new, larger one.
Via REST API or JFrog CLI:
  • Source Type - AQL (Artifactory Query Language): Dynamically create a bundle by querying for specific artifacts.
  • Source Type - Artifacts/Packages: Create a bundle by explicitly listing the artifacts or packages to include.
For more information, visit Create Release Bundles.

Example Project

For a quick demonstration, you can create a Release Bundle from artifacts that have already been uploaded to a repository. 

To do this, use the Create Release Bundle REST API with `Source Type – Artifacts`

Below is a cURL example executed from the command line, showing how to assign all artifacts from the `demo-maven-dev` and `demo-generic-dev` repositories to a bundle:
curl --request POST \
  --url 'https://<JFrog_Platform_Base_URL>/lifecycle/api/v2/release_bundle?project=<NAME_OF_YOUR_PROJECT>&async=false' \
  --header 'Content-Type: application/json' \
  --header 'X-JFrog-Signing-Key-Name: <NAME_OF_YOUR_KEY>' \
  --data '{
    "release_bundle_name": "<NAME_OF_YOUR_BUNDLE>",
    "release_bundle_version": "<YOUR_VERSION>",
    "sources": [
        {
            "skip_docker_manifest_resolution": false,
            "source_type": "aql",
            "aql": "items.find({\"$and\" : [{\"repo\": {\"$match\": \"demo-*-dev\"}}, {\"name\": {\"$match\": \"*\"}}]})"
        }
    ]
}'

4. Create webhooks for Release Bundle creation and promotion events (Optional)
Administrators can create webhooks that are triggered by Release Bundle v2 creation events. When a webhook is triggered, it sends relevant information about the event to a web location that is listening for that specific event notification. 

Webhooks enables you to integrate Release Bundle v2 creation with third-party applications that are also essential to your release lifecycle process.

Configure webhooks to dispatch alerts to external platforms like Slack.
5. Scan Release Bundles with Xray (Optional) 
Requires a Pro X or above subscription.
Prior to promotion, scan the Release Bundle for a security and license compliance assessment.
  1. To enable Xray scanning of a newly created Release Bundle, index and scan the bundle's contents. The scan results will then be linked to that specific bundle version.
  2. Examination and assessment of scanned results are necessary. Remediation may be required, or the identified items may not necessitate immediate action until the subsequent stage.
For more information, consult the Scan Release Bundles with Xray documentation.

6. Promote Release Bundles to the Next Environment
Promotion is the formal act of advancing a Release Bundle from one environment to the next (e.g., from DEV to STG) after it has met all the quality and security gates of the current environment.

Once a bundle is verified (e.g., passed integration tests, resolved issues identified by Xray scans), promote it. This action is recorded as signed evidence.
7. Repeat for Each Environment
The process of scanning and promoting is repeated as the Release Bundle moves through the lifecycle (e.g., from STG to PROD).

8. Monitor Release Bundle
The release lifecycle and Release bundle promotions can be monitored using third party applications by using the Release Bundle Webhooks (see above) and Release Lifecycle Management Metrics (Open Metrics).

Tip

The JFrog CLI includes commands to facilitate the Release Lifecycle Management process. For more information, see CLI for JFrog Release Lifecycle Management.



Phase 3: Enhanced Governance and Compliance

This phase focuses on leveraging advanced features for tighter control and a more complete audit trail.

Evidence Tracking 
Requires a Pro X or above subscription.

Every promotion and scan result is automatically captured as signed evidence, providing an unbreakable audit trail.

How to View:
  • Select a Release Bundle v2 from the dashboard and view the evidence graph, which provides a graphical depiction of the evidence files associated with the Release Bundle and the builds and packages it contains.
    For more information, see View the Release Bundle Evidence Graph.
    You can view a list of evidence-related events associated with a Release Bundle v2 version (such as promotion to an environment) in the version timeline

External Evidence

Requires an Enterprise+ subscription.

Enrich the built-in evidence with your own data. This can include links to external systems, test results, or manual approval records.

For more information, refer to the Attach External Evidence

Verify Release Bundle

Independently verify that a Release Bundle manifest and its artifacts have not been tampered with in transit to their current location (e.g., a deployment server).

For more information: refer to the Verify Release Bundles

Xray Policies for Promotion Control 

Requires a Pro X or above subscription.

This is a powerful feature for "shifting left." Create policies in Xray to automatically block the promotion of Release Bundles if they violate your security or license criteria (e.g., contain critical vulnerabilities).

In Xray, create Security Policies then attach the policies to Watches.
Xray Policies for Distribution Control 
Requires an Enterprise+ subscription.
Apply the same policy enforcement to the final distribution step, creating a last line of defense before release.

Create Xray policies that are specifically checked when a Release Bundle is being distributed.

Phase 4: Secure Distribution

The final step is to deliver your fully vetted release to its target.

Distribute Release Bundles v2 

Requires an Enterprise+ subscription.

Distribution is the process of transferring a Release Bundle from your central Artifactory platform to remote locations, such as JFrog Distribution Edges or other Artifactory instances. This is a secure and efficient way to deliver software, even to air-gapped environments.

After a Release Bundle has been promoted to the final environment (e.g., PROD), use the distribution functionality to deliver it.
For more information, refer to the Distribute Release Bundles and Distribute Release Bundles (Air-Gaped)