Guidance regarding Artifact traceability between CI & CD Jenkins using DORA

Using Jenkins
1

Folks,
We are calculating DORA mostly with Jenkins as CI & CD. What is the best way to get traceability of an Artifact (deployed in Prod through CD pipeline) to the artifact created first using CI pipeline, in this case as an enterprise we are using multiple disjointed Jenkins instances (CI & CD jenkins are separate and they do not talk to each other).
Looking for general solution however in this case we have Jenkins (for CI & CD), Github and Artifactory (Jfrog Artifactory).
Appreciate your guidance. Thank you

3

To help with artifact traceability across separate Jenkins CI and CD environments, you might consider using a unique, immutable identifier that can follow the artifact from build to deployment. Here’s a general approach that could work well with tools like Jenkins, GitHub, and JFrog Artifactory:

1. Consider Embedding Metadata at Build Time (CI Jenkins)

During the CI process, it might be helpful to include some metadata directly in the artifact. Things like:

  • The Git commit SHA
  • The CI build number
  • A build timestamp

This metadata can be stored in various ways. Maybe in a build-info.json file bundled with the artifact, inside a manifest, or even as custom properties if you’re using Artifactory.

2. Publishing the Artifact to Artifactory

Once the artifact is built, you’d typically upload it to Artifactory. At this stage, it’s possible to attach the metadata as custom properties (e.g., gitCommit, ciBuildNumber) using either the Jenkins Artifactory plugin or Artifactory’s REST API.

3. Referencing the Artifact in the CD Pipeline (CD Jenkins)

In the CD pipeline, the artifact can be fetched from Artifactory using its coordinates (like group, name, and version). It might be a good idea to also retrieve and log the associated metadata—either directly from the artifact or from the properties stored in Artifactory. This can make it easier to audit or trace the deployment later on.

4. Enabling Traceability

With this setup, you’d have a few ways to trace an artifact:

  • Query Artifactory to check which Git commit or CI build produced a given artifact.
  • Cross-reference the Git SHA in GitHub to find code reviews or changes.
  • Look up the CI build number in Jenkins to find logs or test results.
  • Use that same metadata in the CD pipeline to help link deployments back to the originating CI build.

Example (Just to Illustrate)

Let’s say CI Jenkins builds my-app-1.2.3.jar from commit abc123 and sets these properties in Artifactory:

  • gitCommit=abc123
  • ciBuildNumber=CI-42

Then, CD Jenkins pulls that artifact and logs something like:

“Deployed artifact built from commit abc123 (CI build CI-42)”

Some Practices That Might Help

  • Try to ensure that artifact versions are immutable, so no one accidentally overwrites them.
  • Automating the capture and transfer of metadata can reduce manual effort and errors.
  • Artifactory’s plugins or API can really simplify setting or querying properties.
  • For teams working with multiple environments, a central dashboard or metadata store could be a nice way to visualize and report on artifact provenance.

This kind of setup could still work even if your CI and CD Jenkins instances are completely separate, since Artifactory can serve as the shared point of truth.

4

Thank you @poddingue. This is helpful, one problem we have since the process should be least invasive (these are external customer’s Jenkins so no direct code changes are allowed, but we can use a plugin or change configuration from our side), we cannot write code/groovy scripts on their Jenkins. Are you familiar with any plugin which does the job being external. Thank you