The idea to develop came as an attempt to resolve a similar issue in two use cases:

  • The existing CI/CD tools does not allow us to track the version of the software in the complex pipelines
  • A Java artifact, that is actively being developed, we want a stable version of it to be used in the resulting product

What we need is a way to persist the version of the artifact and link it with the state of the system where it is currently being used.

In theory, we could have this functionality as a plugin of the specific CI/CD Tool but instead we have built it as a separate SaaS offering so it supports a number of different tools.

Use Cases

Tighter control over the artifact version brings numerous benefits.

Here are just two simple use cases where can help you to be more efficient.

Docker Images

Let’s imagine the following scenario: code commit triggers a CI/CD pipeline. As part of the pipeline a Docker Image gets created with a specific tag. Next, you want to run integration tests scenarios which potentially include the other product images that are built in the same way.

The key question here is which image versions should the integration test stack use?

In theory, you can use the latest image tag, but this is not a very good practice: you’re always better off with the tagged images.

Moreover, CI pipeline is generally used with every commit just to confirm that the new commit did not introduce any issues to the existing code. But not every commit should end up in the Integration Test environment.

Same could apply to any other forms of testing such as UAT, Performance Testing, BAT and eventually to production deployment. And as the product gets closer to production, it gets released less and less frequently to the next testing stage.

How can introducing the to your SDLC help you with the above scenario?

You can associate a specific version of the Docker Image in question with each testing or production stage in With or without flow you get full control over what gets deployed by the testing pipeline.

Java Libraries

Let’s imagine another scenario. Your company builds a complex a Java product that has a number of dependencies. For example, the product uses a number of libraries that are also getting developed in parallel by the other teams.

How can you ensure that correct versions of these dependencies are used?

How can help you to get full control over dependency versions?

It is simple really, just declare a specific stage and associate the library version with the stage.

Then, use the gradle plugin to automatically resolve dependencies during build or assembly.


Artifact – the Docker Image or a Java Library which versions are getting tracked by the

Stage – the state of the system usually associated with the specific phase of its lifecycle, for example Development, User Acceptance Testing or Production.

Flow – the sequence of stages through which an artifact travels during its lifecycle. If Artifact is linked to the flow a new version can only be added to the first stage of the flow. After that the version can only be pushed through the flow.

This website uses cookies. By continuing to browse this site, you agree to this use.