What is artifactz.io and how it can help you in your day-to-day activities?

The original idea behind artifactz.io came when we were trying to manage bespoke dependencies of the Spring Boot application. We required to produce different variations of the resulting application using our own libraries at the different stage of their development. We have recorded versions of the libraries, which at the time were called artifacts, at those stages in the database and used simple API to retrieve them with the set of tools that was generating a build.gradle file in the pipeline.

Then we expanded its use to selecting the version of those dependencies when packaging resulting application as an RPM package. Next, we started using it for deploying those RPMs to various environments, and after switching to use of the Docker started using it to manage which Image tag to be deployed to a specific set of environments.

Let’s illustrate one of the potential use cases. Imagine that an organisation builds a software and distributes them in the form of the Docker Images. Then, those images are deployed to number of environments for the various testing purposes and eventually for production use.

In such organisation group of developers will write a code which then will be pushed to SCM repository. The push event triggers automated CI pipeline which produces a Docker Image which is pushed to a Container Registry.

So far it is all automated right after developers completed their work.

However, now I would like to deploy produced images to the various environments each serving its own unique purpose. How do we track which image should be deployed to each such environment?

One of the options which we observe quite frequently is to store deployment manifests, or properties in SCM repository as well. Hence, to deploy a new version to an environment, some file or files must be changed, committed and corresponding pipeline is triggered.

When software artifacts are produced relatively frequently, deploying version of the specific artifact to the multiple environments becomes a quite tedious and error-prone process. Same applies to the libraries, linking correct library to the final product is a manual task. When someone links multiple libraries developed by different teams into a final product, well, I do not envy that person.

This is where artifactz.io can help. In few words, it maintains a logical map of your environments and keeps the track of what artifact resides at each possible location on that map. As an additional bonus it can force you to follow a specific flow, i.e. that enforces the rule that a specific artifact version can only be assigned to the stages in the specific order.

As I described in introduction, each location at the map of the environment we refer to as “Stage”.

A specific section of the map of your environment where the artifact can reside is called a “Flow”. Flow is optional for an artifact, but could be useful as it enforces how an artifact can travel through the environments.

Each artifact is identified by its name. Each copy of artifact, produced from the unique combination of the source components is called a “Version”.

For example, in our organization there is Docker Image called “web-service” that our CI pipeline builds. The “web-service” label is the name of the artifact.

We have four environments in the organization: “Integration Test”, “UAT”, “BAT” and “Production”. Those are the Stages where our Docker Image can in theory be deployed.

Let’s imagine for the purpose of this example that “web-service” can only be deployed to “Integration Test”, “UAT” and “Production”.

Without artifactz.io the process will look like this. Once change is made and pushed the CI pipeline is executed and it produces a Docker Image which is pushed to the Docker Registry. The image associated with the code change will be assigned a tag, e.g. 2.1.4.132.

If I want to run an Integration Testing pipeline or just deploy the image to the Integration Testing environment, I must use the above tag or version when running it so correct version of the image is deployed. If deployment is a manual process in organization, I must update compose file, kubernetes manifest or Helm environment config file with correct tag and deploy it.

Same happens in UAT and Production environments.

With artifactz.io this tasks could be drastically simplified.

Let’s first define the Docker Image lifecycle.

When the Docker Image is built, it is ready to be deployed to the “Integration Test” environment. After integration testing is successfully concluded, the image can be promoted or pushed to the “UAT” environment. Again, once User Acceptance Testing is complete, the image in question can be promoted to “Production” environment. Logically, we do not want this image to be deployed to “Production” unless it passed through the UAT, i.e. we cannot promote or push it from “Integration Test” directly to “Production” environment.

The statement above defines the “Flow” for our “web-service”.

Once, the flow is defined we can configure the pipelines. As soon as artifact is built by the CI pipeline, a plugin places it into “Integration Test” stage.

“Integration Test” stage is an entry point to the “web-service” life cycle. Once the version of the image is at “Integration Test”, the integration testing pipeline can be started. The Integration Testing pipeline uses plugin to get the version of the Docker Image which is currently associated with the “Integration Test” and deploy it to the environment.

Once we are happy that application is ready to be tested by user the version of the artifact in “Integration Test” stage is pushed using plugin to the “UAT” stage.

The deployment pipeline is using a plugin again to read details of the Docker Image version from the “UAT” stage and uses it to build a deployment manifest from the template.

Similarly, once the acceptance tests are over, the version from “UAT” stage can be pushed to the “Production” stage, where deployment pipeline also builds manifest on fly and deploys it to the environment.

Now, it is all automated and user is only required to run a pipeline without modifying anything. The versions are tracked by the artifactz.io.

Similar approach can be used to define which versions of the various Java artifacts are used to build a Java project with gradle. If artifactz plugin is used, it will attempt to get the current version of any java dependency which do not have explicitly set version. We will discuss this approach in details in the separate article.

So, in essence, artifactz.io helps you to organize the software artifacts in various deployment environments.

You can try it yourself, by clicking this link. Registration process is simple and does not require payment details, billing address etc. Once registered, you are in the trial mode for a some time, during which you can decide if it is for you. And if it is, you can still continue using it under the free subscription plan, which also by the way does not require billing or payment details, but has limited allowance, or subscribe to one of the premium plans.