Artifacts and packages enable DevOps Change Velocity to track development and testing activities across a wide range of deployment and release models. This feature ensures that pipeline activity stored in the DevOps data model can be retrieved and applied when artifacts are created and released at different times or in different pipelines.

Artifacts

When an artifact version is registered, related activities like commits, tests, and code scans are tracked so that regardless of when the artifact version is deployed, those details can be retrieved. It can be in the current pipeline execution, a later execution of the same pipeline, a pipeline that is triggered by the current one, or a separate pipeline that is triggered independently.

When you associate commits with an artifact version (CI pipeline), and define an artifact package (CD pipeline), all artifact versions generated since the last time the app was deployed to production are included in the list of commits for the change. Consolidation of these items is helpful, especially when there are multiple CI builds before the deployment.

DevOps change request attributes:

Packages

A package tracks when one or more artifact versions are being used in a deployment pipeline. This provides two important benefits:
  1. Retrieval of activities for all artifact versions declared in the package. For example, for use in an automated change approval policy.
  2. Recording when a specified artifact version was successfully released, ensuring that information tied to them is no longer considered. For example, for later change requests.

Artifact setup

  1. Create an artifact tool record in DevOps.
    Note: An artifact tool isn’t necessary unless a webhook or user-created integration subflow configuration is required to look up artifact versions.
  2. Register artifacts in the CI pipeline.
  3. Create a package in the CD pipeline.
    Note: The package creation step must be before the Prod Deploy step.

Artifact registration

Configure artifact registration in a scripted pipeline or freestyle job using the DevOps API /artifact/registration endpoint. Multiple artifact versions are supported.

For Jenkins pipeline:
  • Scripted and declarative pipeline (snDevOpsArtifact Jenkinsfile command)

    For example:
    snDevOpsArtifact(artifactsPayload: """{"artifacts": [{"name": "sa-web.jar", "version": "1.9","semanticVersion": "1.9.0","repositoryName": "services-1031"}], "branchName": "master"}""")
  • Freestyle job (Register Artifact build step)

    For example:
    {"artifacts":[{"name":"sentiment-analysis-web2","version":"1.9","semanticVersion":"1.9.0","repositoryName":"maven-releases"}]}

Artifact package creation

Important: You must add the package creation step before the change step in your pipeline, and package creation must be added in a stage which is previous to the change step, so that packages are linked to the pipeline execution for a change request.
Configure artifact package creation in a scripted pipeline or freestyle job using the DevOps API /package/registration endpoint.
Note: Package name must be specified.
For Jenkins pipeline:
  • Freestyle job (Create Package build step)

    For example:

    {"artifacts":[{"name":"sentiment-analysis-web2","version":"1.9","repositoryName":"maven-releases"}]}
  • Declarative and scripted pipeline (snDevOpsPackage Jenkinsfile command)

    Package with more than one artifact (from different repos) in the payload, for example:
    snDevOpsPackage(name: "sentimentpackage", artifactsPayload: """{"artifacts":[{"name": "sa-web.jar", "version": "1.9", "repositoryName": "services-1031"}, "{"name": "sa-db.jar", "version": "1.3.2", "repositoryName": "services-1032"}], "branchName": "master"}""")

    DevOps change acceleration for releases package

Note: When an artifact version isn’t available during the build, build details (pipelineName or projectName, taskExecutionNumber, stageName, branchName) are used to look up the artifact version in the task execution.

Jenkins plugin step includeBuildInfo can be used to include build details in the API call.

Artifact workflow and objects

The orchestration tool job publishes the new artifact (consisting of versions) to the artifact repository. Each artifact version is associated with a task execution (consisting of the related code commits). A package is created for the release (consisting of specific artifact versions flagged for deployment) and, after the deployment stage completes, the package is marked as deployed to production.

These objects are part of the artifact structure.

  • Artifact tool

    Used to support artifact repository managers such as JFrog Artifactory.

    Note: An artifact tool isn’t necessary unless a webhook or user-created integration subflow configuration is required to look up artifact versions.
  • Artifact repository

    Target for artifacts generated in a build, and also a source of artifacts required by a build. Can be created manually, or through the RegisterArtifact API as new artifacts are published under new repositories in a tool.

  • Artifact

    Artifact name for which different builds (artifact versions) are generated. Can be created manually, or through the RegisterArtifact API. Artifacts (versions) are associated with a task execution and published to an artifact repository.

  • Artifact version

    Specific version of the artifact. Deployable component of an application generated by a CI build. When provided, semantic version is used.

    Can be created through discovery, or through the RegisterArtifact API. Artifacts (versions) are associated with a task execution and published to a tracked artifact repository.

  • Semantic version

    Optional attribute of an artifact version that, when provided, is used to determine commits for a change. Semantic version format is (MAJOR.MINOR.PATCH).

  • Package

    Collection of artifact versions used as input to a CD pipeline, or for associating test results.

    Package creation is triggered by the CreatePackage API call from the orchestration tool and contains the name, version, and repository name of all the artifact versions included in the package. A check box indicates whether the package has been deployed to production.

Example

DevOps change acceleration for releases:
Figure 1. DevOps change request – category DevOps
DevOps change request.
Figure 2. DevOps change request – commits and work items
DevOps change request commits.
Figure 3. DevOps artifact version list
DevOps artifact version list.
Figure 4. DevOps artifact version – commits
DevOps artifact commits.
Figure 5. DevOps artifact version – packages
DevOps artifact packages.
Figure 6. DevOps package
DevOps package.

You can also see all existing pipeline change requests directly from the Changes module in the application navigator.

Figure 7. Changes module

You can see all existing change control and pipeline change requests directly using the Changes module in the application navigator.

Navigate to DevOps Change Workspace > Changes > Pipeline change requests > All for all change-related information.

Pipeline change requests

Pipeline change requests.
Figure 8. List module

You can see all the existing artifacts and packages directly using the List module in the application navigator.

Navigate to DevOps Change Workspace > Lists > Artifact for all artifact-related information.

List of artifacts and packages.

Artifacts and packages monitoring

When artifacts and packages are registered from a source tool into ServiceNow, they are often staged in the sn_devops_artifact_staging table, while the remaining necessary data for creation and linkage of these objects is either received from inbound events, or fetched by DevOps flows.

Most of the times, these staging records are processed within a few seconds. But there may be cases where the necessary data is never received, so these records may be left idle. The Description field on the table below contains a summary of the details missing in such cases to help in easier monitoring.

Note: It is recommended to have unique artifact names for release builds, that is, different artifact names for builds running on different branch builds.