This document will try to discuss how we use tags in docker. When assigning docker tags we leverage of knowledge both from the GIT workflow used, as well as the actual release. First the GIT Workflow used will be described, next the semantic versioning is described and finally docker tags are described.
In most of the projects we follow the git branching strategy as described in "A successful Git branching model". This describes a development model where there are two main branches (master and develop) that will always exist. All development is done on feature branches, which after a code review will be merged back into these main branches.
The master branch is the branch that contains the latest released version of the software (production ready). The develop branch contains the newest code will have all the latest features (and some of the bugs). Any new features that are developed will be merged into this develop branch.
Once the decision is made to create a new release of the software we will branch from the develop branch and create a release branch. We will test this release branch and fix any issues. Once we are done testing and there are no more bugs we merge the release branch into the master branch.
To recap, there are two major branches:
- master: contains the latest production ready and release code
- develop: contains the code will all the newest features
Most of the software released will be released with a version number. The version number we use is based on the semantic versioning schema. In this schema the version number is made up of numbers separated by a period. The version number is frequently made up of three numbers MAJOR.MINOR.PATCH:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards-compatible manner, and
- PATCH version when you make backwards-compatible bug fixes.
To simplify the installation of the software we develop we are distributing the build software as docker images. These docker images makes it easy for anybody to run the software without having to learn how to install the dependencies. Upgrading the software is also easier, since all that is required is to download the newer docker image, stop the old image, update any configuration settings and starting the new docker image. There is no need to upgrade any of the dependencies since they come bundled in the docker image.
To make it easy to pick the version of the software that is being used we will tag the docker images with a version. This makes it easier to pick the appropriate version and in case of more complex stacks, will make sure we are running the same version of all the containers that make up the stack.
We will use two special tags, latest and develop, which follow the branches in GIT. The latest tag in docker will always point to the code as it is available in the master branch and will always be the latest production version of the software. The develop tag points to the code in the develop branch and will be images with the newest features available.
Additionally, the software will be tagged with the actual version released. If the software released is version 1.6.2, there will be an image with the tag 1.6.2. To make it easier to install we will not only tag the software with the full version number, but we will have additional tags that, in the case of the 1.6.2 release we will also have images tagged with 1.6 and 1. This allows you to decide that you always want the latest released image (latest), or the latest released image in the major version (1), or you want all the patches for a specific release (1.6) or you want a specific release (1.6.2).
Docker images are tagged using the following schema (newest code at the top)
- develop : the software with the latest features, but not released to production
- latest, 1.6.2, 1.6, 1 : the current and latest released to production software
- 1.6.1 : older version of the released software
- 1.6.0 : the first released software in 1.6
- 1.5.1, 1.5 : the 1.5 version of the software with a patch
- 1.5.0 : the first release software in the 1.5
The workflow's name is
Gitflow, right?https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow