Application versioning

So far, during every Jenkins build, we have created a new Docker image, pushed it into the Docker registry, and used the latest version throughout the process. However, such a solution has at least three disadvantages:

• If, during the Jenkins build, after the acceptance tests, someone pushes a new version of the image, then we can end up releasing the untested version
• We always push an image named in the same way; thus, so effectively, it is overwritten in the Docker registry
• It's very hard to manage images without versions just by their hashed-style IDs

What is the recommended way of managing Docker image versions together with the Continuous Delivery process? In this section, we get to see different versioning strategies and learn different ways of creating versions in the Jenkins pipeline.

Versioning strategies

There are different ways to version applications.

Let's discuss these most popular solutions, which can be applied together with the Continuous Delivery process...