Introduction
A software build contains not only the developer’s code also includes a range of software artifacts. A DevOps artifact is a by-product produced during the software development process. It may consist of the project source code, dependencies, binaries or resources, and could be represented in different layout depending on the technology. Software artifacts are usually stored in a repository.
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.
Bundle Artifacts 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:
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.
The Artifact Process
Typically, a software development team will come up with a list of necessary artifacts for a piece of software before coding anything. These include things like risk assessments, source code, diagrams, and use cases. This is done during the research phase of the project.
Developing a piece of software without any of this is like building a house without blueprints. The process would be a huge mess, and crucial pieces would inevitably be left out. In this way, getting all your artifacts together is one of the most crucial parts of the software development life cycle.
Once all the initial artifacts are compiled, a development team can begin programming and building the actual program. Throughout this process, further artifacts might be developed. These can come up at any time and include everything from new sketches to use cases.
Some artifacts, like the end-user agreement, may need to be built after the software is complete for total accuracy. These may be added in before the program is compiled and sent out for consumption.
Why Are Artifacts Important?
Artifacts are important to hold onto throughout the development process of any piece of software, and even long after.
Without each and every artifact, it can make developing a piece of software much more difficult over time. This is especially true if development switches hands. When a new developer is put on a project, one of the first things they’ll want to do is go through the artifacts to get an idea of how the software works.
If an artifact is missing, that leaves a developer in the dark. This is why most artifacts are kept in a repository. This lets relevant developers access the artifacts at any time, all from one place.
What Is an Artifact Repository?
An artifact repository is a location for all of the necessary artifacts that might be used to develop a piece of software. It is often hosted on a local server or in the cloud for easy access by developers.
Using an artifact repository is absolutely necessary for all software development. It makes a complex task easier by giving developers all the resources they need in one place. It helps cut down on searching and gives developers the ability to move, add, and delete artifacts with ease.
There are three types of artifact repositories used in software development:
Remote Repository: A remote repository is hosted on a remote URL, sometimes by a third-party company. You cannot add new artifacts to a remote repository, but you can remove them.
Local Repository: A local repository is stored in-house, usually on a dedicated server.
Virtual: A combination of the two above. This repository is held under one URL, allowing access to local and remote artifact files. This lets you add and remove artifacts from each repository with ease.
What are Artifacts Management Tools?
Artifacts management tools, also known as artifact repositories, are used to store, organize and distribute artifacts (that is, binary files plus their metadata) in a single centralized location. This reduces the amount of time spent downloading dependencies from a public place. Artifact management tools also prevent inconsistencies by allowing development teams to find the right version of an artifact easily.
The main features that artifacts management tools must have are:
1. Versioning support: properly store metadata, such as when the artifact was built, what its version number is, etc.
2. Retention: allows you to set up criteria to retain important artifacts while automatically deleting irrelevant ones.
3. User permissions: with this feature, you can control who can publish and download artifacts.
4. Promotion: allows you to not only promote artifacts to specific channels, but also to move artifacts between them.
5. License filtering: due to licensing and legal issues surrounding third party artifacts, license filtering is necessary to restrict artifacts so that only approved artifacts can be deployed.
6. High availability: any downtime can significantly encumber development, so it’s important to have a redundant set of repository managers to maintain stability and performance.
Examples of artifact uses in software development
Artifacts can include the following:
Diagrams. These help developers map out the structure of the software.
Images. These design or reference images help develop the software.
Meeting notes. These are design choices and aspects written down as full or partial transcripts from meetings.
Software documentation. These documents describe the characteristics and attributes of the software.
Source code. This is the designed and fundamental system that enables code to work.
Prototypes. This fully functioning version of the software helps developers build a basic functioning version of their project.
Risk assessments. These include the potential risks and downfalls of a piece of software, which can help new developers determine potential risks and resolutions to issues at a glance.