The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms.
This definition was issued by Martin Fowler in its microservices dedicated article.
Microservices are designed to be developed with their own life cycle, and to be updated often, easily and quickly.
Automation tools and CICD approach make it simple to add features, fix issues and deliver new source code with no pain. It became so easy to deliver and deploy new release of microservice components that monitoring the version of these live components in your production environment is critical. So, the versioning of these components became critical too.
This article will present you the method we adopted to make it simple keeping a rigorous and automated versioning for our Golang microservices.
Semver automated versioning
With no surprise, we have chosen semver (https://semver.org/) as the versioning standard. It not only made sense to us to follow a convention that is a de facto standard, but it was also introduced in Golang community as a reference for the module system release in Go v1.11.
Go also suggest a standard library to manage versioning (https://godoc.org/golang.org/x/tools/internal/semver)
As a small team, automation is an every day challenge. We wanted to get rid of this annoying work that consists in parsing your commit list to define if your need to release a minor or patch version.
We tested some libraries and pickup the node library semantic release.
semantic-release automates the whole package release workflow including: determining the next version number, generating the release notes and publishing the package.
This removes the immediate connection between human emotions and version numbers, strictly following the Semantic Versioning specification.
All commits following conventional commits messages are taken into account to determine the new release version.
CICD pipeline presentation
To make it seamless to us, we embedded it in our CICD pipeline. We are happy with Gitlab-CI as a daily precious tool to automate all our development workflow. And we found it natural to insert a new job in our pipeline to generate versions automatically for our services.
Here is a representation of our build process:
The release job use a docker container made from the semantic release project.
Read the rest of the article here: https://medium.com/intercloud/microservices-automated-versioning-with-gitlab-ci-5d465940142f