Starting with version 1.11, DevOps change acceleration for releases lets
you view all commits and work items in the change request for the DevOps release
when approving, rather than having commits spread across multiple task executions.
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:
- Category DevOps
- Commits and Work Items related lists
Artifact setup
- (Optional) Create an artifact tool
record in DevOps.
Note: An artifact tool is not necessary unless a webhook or
user-created integration subflow configuration is required to look up artifact
versions.
- Register artifacts in the CI pipeline.
- 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.
Artifact package creation
Configure artifact
package creation in a scripted pipeline or freestyle job using the
DevOps API
/package/registration endpoint.
Note: Package name must be
specified.
Note: When an artifact version is not 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, once 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 and Nexus,
for example.
Note: An artifact tool is not 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.
