Jose Armesto

Software Engineer

Having a good versioning strategy for our applications is key.
Specially in Jenkins X, which follows the GitOps flow to deploy our applications, specifying which version of our application will be used on each environment.

But having to manually create tags or releases for our applications can be a tedious task. Jenkins X automatically takes care of versioning for us.
It uses a tool called jx-release-version to figure out which is the next version to be released.
In order to do that it checks what’s the current released version in the repository looking at the released Git tags. It can also read this version from your pom.xml file, or your Makefile.

If we use semver semantics, and versions are written in the format major.minor.patch, jx-release-version will tell you which is the next patch version.

This year Jenkins X has been announced. If you haven’t heard, Jenkins X is a tool that lets you automate the whole delivery process of your software to a Kubernetes cluster.
One key aspect of Jenkins X is that the deployment of applications is implemented following the GitOps flow.
In this approach every environment is represented by a Git repository. In this post we’ll see how Jenkins X environments work.

If you’ve been developing applications for some time, you’ve probably developed some kind of HTTP application.
This is the most solved problem there is in our industry, with lots of frameworks and tools that help you solve this problem easily.
Also, there are some patterns and practices that we apply when solving this, that come from years of experience learning the pain points while developing these applications.
I’m talking about things like not coupling your business rules to your framework, or using layers to separate things like data access objects from your domain model.

However, sometimes we forget that we can apply these patterns to almost any kind of software project.
Lately I’ve been involved in projects that contain some Kubernetes Operators and the code in there could benefit a lot from the patterns that we already apply to our typical HTTP applications.

Docker released the multi-stage builds feature in the version 17.05. This allowed developers to build smaller Docker images by using a final stage containing the minimum required for the application to work. Even though this is being used more and more over time, there are still multi-stage patterns that are not that widely used.

Today I want to share with you the project I’ve been working on for the last year in my free time. For me, the project has already been a success: it’s a pet project that has allowed me to learn a lot about Amazon Web Services, Docker and Ansible. But letting that aside, I believe is a useful project that can help you deploy your software better!