Understand Your DevOps Artifacts to Build and Deploy Efficiently
Types of artifacts
- Deployment
- Library
- Bundle
- Pipeline
Deployment Artifacts typically take the form of a released executable for public consumption. This includes deb, rpm, exes, tar.gz (single binaries), msi, img, or any other form of release. Lately, a popular destination for such an artifact is Github Releases. Other package management apps like pip, npm, apt, chocolatey, or nix can also be a target for deployment artifacts.
Arguably, the most popular deployment artifact in the industry at the moment is the lowly container image.
Library Artifacts are very similar to deployment artifacts. They can even end up in some of the same artifact repositories. Library artifact destinations include; maven, npm, pip, or nuget. One key element that differentiates a library artifact from a deployment artifact is that a library’s purpose is for use in other development efforts.
If you are developing some application and a version of a library randomly starts acting differently there can be very real downstream issues. Because of this, of utmost importance is that the library artifact is immutable and permanently versioned. That is, we should not be able to overwrite a particular deployed version of the library once the library artifact has been published.
I struggled to put Bundle Artifacts in the list. This is because it really is not one artifact but a grouping of several together that comprise a particular deployment or need. Typically the destination for a bundle artifact is not a repository or artifactory but rather a drop zone such as cloud storage or a virtual machine (or cluster of virtual machines). The end result is the same though, a group of binaries and configuration are packed up for downstream deployment or usage.
It is worth noting that it is entirely possible to bundle up artifacts into container images that are then unbundled further down in a deployment operations. Most notably, the Immutable Configuration pattern for Kubernetes deployments would employ this technique.
- Azure DevOps Pipeline Artifacts
- Github Workflow Artifacts
- TektonCD Pipeline Task Input/Output Artifacts
- Jenkins Archive (workspace) Artifacts
Often, a DevOps pipeline will rely on Pipeline artifacts when getting started or when a centralized artifact repository simply is not available. This is is complicated by the fact that some platforms (most notably, Azure DevOps Classic Pipelines) have created whole ecosystems around treating them as first class citizens within the DevOps process.
You can see that the plan bundle can be pushed into a pipeline artifact as a holding area. This is where dedicated reviewers would approve/deny the deployment into an environment. A Terraform plan bundle is perfectly suitable for a pipeline artifact as it meets both criteria I personally use to justify pipeline artifact usage:
- Is the artifact part of a one-way or single use operation? (Yes. It is unlikely you would use a prior Terraform plan bundle to roll back operations.)
- Does the artifact only apply to a single target environment? (Yes. It can ONLY ever be used on a single target environment.)
Do yourself a favor, don’t design your pipelines around using pipeline artifacts as your sole artifact type. Relying heavily on such ephemeral artifacts can weaken your overall pipeline independence and reduce the pipeline code base re-usability. They also makes rolling back to older versions of a deployment difficult, especially if your executed pipeline history is only kept for a short period of time.
