Automated Semantic-Release Versions

For more than 12 months, Scandio has been developing a Golang-based gateway system for a major industrial customer to connect several million IoT devices. Thus, this gateway is the single point of contact for every access to the customers cloud services. A new, fully automated tooling had to be developed for the complex release management due to the significant growth of the project and the dependence on other software components.

So far, a new release was initiated on the master branch using git tagging. The tag name (33.0.0), which was based on the respective sprint, determined the version. This was wrong in terms of content and the version did not provide any information about the actual content.

For this reason, the team decided to introduce semantic versioning.

The solution

Semantic-release combined with Commitlint

Semantic-release automates the creation of releases and replaces manual tagging by assigning a new version number, based on the commits accumulated since the last release, and creating a git tag. It uses the title of the commit messages to increase the version number of minor or patch. Therefore, the title of each commit message must follow a fixed format and start with a type specification. To ensure that these rules are followed, Commitlint comes into play.

As an example, the configurations of the current web socket manager are attached here:

.commitlintrc.yaml

This Commitlint configuration file contains an overview of the possible commit types, and is based on the Config-Conventional ruleset.

To run Commitlint we use this command in Bamboo:

npx commitlint --from master

Prior to this, only the current status has to be checked out.

Then the output could look like this:

The type (subject) was forgotten here, so the input starts directly with “Add”.

.relaserc.yaml

The configuration file of semantic-release first maps “releaseRules”. Commit types are assigned to release types.

The next block creates links to related issues and comparisons (diffs) of the new and the previous version, which are then included in the changelog.

Semantic-release can also be used to execute simple bash scripts. In this case, we use an inline script to maintain the new version in our helmet charts as well.

Semantic-release can perform so much more, but these features are currently not used. For example, new versions can be published via npm.

To perform semantic-release in Bamboo, a docker container was built with the necessary npm packages pre-installed. To run the tool in Bamboo, the build stage is started in this container and the following command is executed:

npx semantic-release

The new changelog is also filled automatically. Thanks to our colleague Joschi, who has repeatedly pointed us to this blogpost about meaningful commit messages, we’ve been writing valuable commit messages for quite some time now. This ensures that we now have a human-readable changelog. In the future we will be able to answer questions from partners such as “What version of the websocket manager have you deployed? Is our feature request already included?” with a reference to the changelog.

After raising the version and making changes to files, a new commit is created and pushed by the semantic-release bot. In consequence, Bamboo triggers another build, which can then be released and deployed in Bamboo.