Skip to content

Versioning & Deployment

Jump to bottom
Jens Kutzsche edited this page Jul 19, 2021 · 6 revisions

Versioning

Versioning is automated with help from GitHub Actions, semantic-release and the Git-flow branching model.

Branches

According to Git-flow we have the following permanent branches with special roles:

  • develop: Reflects the current development status. Feature branches are created from this and merged back to it, when complete.
  • release: Reflects the current testing status. When a stable state is reached on develop branch, it can be merged to release. This will result in creating a release candidate.
  • main: Reflects the current productive status. When a release candidate is well tested, it can be merged (from release) to main. This will result in creating a productive release. Furthermore hot fix branches can be created from the main branch, when critical bugs have to be fixed. After merging them back to main they should be also merged back to release and develop. However, to get the correct versions, all releases must be marked back.

Determining version string

The version number follows the pattern major.minor.patch[-postfix] (Semantic Versioning) and is determined by semantic-release automatically from analyzing the commit comments by scanning for special keywords. Therefore we have the important convention to follow the Conventional Commits specification. Typical keywords are:

  • chore: TO BE DESCRIBED
  • fix: for bug fixes, leads to increment in patch
  • feat: for features, leads to increment in minor
  • BREAKING CHANGE: for incompatible changes, is written in addition to fix or feat in the commit message, leads to increment in major

Publishing

The services / deployment units are bundled as docker images and uploaded to a public docker hub repository with name inoeg. This publishing process is triggered by merging / pushing commits to the special branches mentioned above. A push to

  • develop leads to simply publishing the images with the floating tag 'develop'
  • release or main leads to determining a new version number as described above (in case of release with an RC-postfix) and publishes the images with the following tags:
    • exact version string
    • major.minor-latest (floating tag)
    • major-latest (floating tag)
    • fix string 'latest' (floating tag)
    • In case of a release additionally:
      • major.minor (floating tag)
      • major (floating tag)

Deployment

Deployment is automated with help from GitHub Actions, Maven, Docker and Watchtower. Currently only the IRIS client images with 'develop' tag are deployed on the DEV-Environment. This is achieved by a tool named Watchtower, which is itself a docker container running on the target machine. It polls every 60 seconds for updates of the concerned images at docker hub. For production environments, the Docker Compose configuration that matches the release will be available for download on Github.

Clone this wiki locally