X

This site uses cookies and by using the site you are consenting to this. We utilize cookies to optimize our brand’s web presence and website experience. To learn more about cookies, click here to read our privacy statement.

Technology Leadership Forecast
5 Ways IT Leaders Set Themselves Apart in 2022.
SEE THE REPORT

Understand Your DevOps Artifacts to Build and Deploy Efficiently

Author: Zachary Loeber Posted In: Azure, Cloud, DevOps
May 202020
To move quickly in large development projects, developers know to use immutable artifacts so the build progresses exactly the same through testing, pre-production and production. An immutable package gives you the most confidence that the package that was tested is what will be deployed to production.
It is the job of the build pipeline to create these immutable artifacts, with multiple types of artifacts available depending on what purpose it serves. Let’s go over the types of artifacts found in various DevOps pipelines.

Types of artifacts

An artifact is really just the output of a build of some sort. Too bad not all artifacts can be treated the same or things would be much easier. There are several kinds of build artifacts, each requiring different code and pipeline techniques to produce and then use in your deployments. Here are a few:
  • 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.

A Pipeline Artifact is an ephemeral file, bundle, or any other build output that lives only on your pipeline. These are typically are used to bridge the gap between a CI and CD within the same pipeline and can be found in almost every DevOps platform as a way to make pipeline as code more coherent. A few examples of pipeline artifacts include:

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.

Pipeline artifacts can be a way to get a functional pipeline quickly and can be used solely for some types of pipelines. A typical example would be a Terraform pipeline. Terraform produces a plan file that can be used in a bundle along with the cached initialization files and any custom providers for a deployment. Here is an oversimplified example:

Pipeline Artifact Example

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:

  1. 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.)
  2. 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.

 

You're on a roll! Try these next:

No related posts.

CICDCloud developmentDevOpspipeline
Next Optimizing Project Management in the Wake of COVID-19 and Beyond