As a fresher, it was new to understand the release system adopted by my team. My interest lay in getting familiar with this system of successfully building, testing and delivering a feature, and understanding the need for a versioning strategy.

In this blog, I’ll be briefing about the following things:

The scheme of semantic versioning.

The significance of a version number.

I will elaborate this with the help of an example branch and release strategy. It will cover the versioning strategy we follow from one environment to another and eventually releasing our code to the production.

Semantic Versioning

Before moving to the branch and release strategy let us talk about what Semantic Versioning is.

Fig 1. Semantic Versioning Format

Semantic Versioning is a 3-component number in the format of X.Y.Z, where: X stands for a major release, Y for minor and Z for a patch.

Major Release — Increment the first digit from left by 1 if the new feature breaks backward compatibility and we say that it is a major release.

Minor Release — Increment the middle digit by 1 if the new feature doesn’t break any existing features and is compatible with the application in its current state, calling it a minor release.

Patch Release — Increment the last digit by 1 if you’re publishing bug/patch fixes to your application. Patch release is frequent and is also given in case we face bugs at production.

Strategy we follow

Fig 2. Tags on each environment

^ Don’t get confused by the diagram. Continue reading to break this down a little more and understand each part of the flow chart.

We have a single git repository with three branches namely QA, UAT, and Master. Whenever a new feature is built, the developer decides if it is a minor or a major release depending upon its compatibility. If not, we take it as patch release by default. However, we have generated a Jenkins pipeline where we can change release type in case it turns out to be minor while creating tags.

We use microservice architecture so, whenever a new service is deployed its version will be 1.0.0-alpha-x and 1.0.0-beta-x on QA and UAT environment respectively taking it to the production as 1.0.0. Later in this blog, you will get to know more about tags, continue reading.

Let us consider we have an already existing service with a previous release version as 1.3.2 which is now built with some new feature that does not break backward compatibility and thus is a minor release.

Fig 3. The process followed for QA environment

1. In the first step, code for the new feature is added and built from the QA branch which is tagged as 1.4.0-alpha-4

where 1.4.0 is major.minor.patch version number — minor number is incremented by 1 as it is a minor release, alpha tells that the tag is formed from QA branch and 4 is build number which increases each time the service is built.

2. In the second step, we deploy this tag on the QA environment.

QA testing will be done to know whether the feature is working fine or not and only after successful sign-off we merge code in the UAT branch and proceed with the fourth step.

Fig 4. The process followed for UAT environment

4. In the fourth step, code is built from the UAT branch and tagged as 1.4.0-beta-6

where 1.4.0 is major.minor.patch version number, beta tells that the tag is formed from UAT branch and 6 is build number which increases with every time the service is build.

5. This tag is now deployed on the UAT environment.