Release management

Prolog

Gitlab with mono repository

Since we are using gitlab and a mono repository, the release effects all submodules. More precisely at the moment we can not have individual releases (e.g. REST 0.1.0, TemplateStore 0.2.0) rather one release for all or product version (e.g. REST 0.1.0, TemplateStore 0.2.0). Which means if a module has a bug needed to be fixed, we have to release always a new product version.

Gitlab does not support individual pipelines inside a mono repository. So if we want to have this, we need to implement it on our own.

Trunk Based Development - Better alternative to gitflow

Gitflow is a best practice Git workflow design. It defines a strict branching model designed around the project release.

Small (or even bigger) development teams are not using gitflow anymore, cause it causes more problems than it helpes (merge conflicts). So a new, much simpler, way, was introdruced - Trunk Based Development.

Fore more information see: https://trunkbaseddevelopment.com/

Semantic versioning

We are using the common semantic versioning followed by this:

Given a version number MAJOR.MINOR.PATCH, increment the:

  1. MAJOR version when you make incompatible API changes,
  2. MINOR version when you add functionality in a backwards compatible manner, and
  3. PATCH version when you make backwards compatible bug fixes.
    Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

For more information see: https://semver.org/

VERSION.txt

Create for every module a file, that can be used to display it when starting the module. In the best case the VERSION.txt is being adapted from the latest git tag release.

Docker tagging

Each Docker image should be tagged multiple times when building and pushing to the registry.

  1. Tag the image using a semver label, and push all individual version components separately. (e.g registry.goingrid.io/{image}:v1, registry.goingrid.io/{image}:v0.1, registry.goingrid.io/{image}:v0.1.5)
  2. Tag the image with a tag to indicate that it’s the “latest”. Docker uses latest as the default tag name, but the latest tag is not automatically applied when pushing a new image. (e.g registry.goingrid.io/{image}:latest)
  3. For testing individual commit before releasing it, tag the image with the commit number. (e.g registry.goingrid.io/{image}:ad3b8f50) (@Dario Not sure about this one yet!)