Release Management and the Release Manager

The tasks of a release manager - besides overseeing the release - is to ensure that the components are in a position where they can be released.

Gitflow formalizes a workflow that enables clear communication of the release processes.

The gitflow semantics are illustrated in the diagram below:

In general, gitflow operates with two main branches: master, where the code that forms the basis for the current release (production) is found, and develop, where code that forms the basis for the next release is to be found.

The gitflow model further operates with feature, release and hotfix branches.

Neither of master or develop are ever committed directly upon, only merged into from feature, release or hotfix branches.

A feature branch is made off the develop branch and represents development effort that stretches over multiple commits, ie. development spanning commits where (some of) the intermediate commits potentially  break functionality, compile-time and/or runtime. There can be multiple feature branches at any given time.

A hotfix branch is made off the master branch and represents development effort that aims at solving a concrete problem in the codebase immediately. A hotfix branch references a single issue and upon completion is  merged into both master and develop. There should be at most one hotfix branch at any given time, but of course a situation could warrant otherwise.

Versioning of releases

OpenNCP has decided to follow the Semantic Versioning Scheme. Each component follow its own version schedule, so at any given release point, the release manager will know whether or not that specific component has seen any changes since last release. Furthermore, we take advantage of the maven SNAPSHOT functionality, meaning that while the components are being developed upon (concretely: that the code can be found in either the develop branch or a features branch), the version number of the component will have -SNAPSHOT postfixed to the version number.

Once a release candidate is branched off, the first thing to do is to remove the -SNAPSHOT postfix and replace it with -rc1. E.g. 1.1.1-SNAPSHOT becomes 1.1.1-rc1

Each bugfix on the release branch shall warrant an increment-like change on the version number: 1.1.1-rc1 becomes 1.1.1-rc2

Once a release candidate has reached a stable level and has been approved by the release manager, with the possible addition of the involved developers, the release branch is merged with the master branch (and the develop branch), and the version number is changed to reflect a release number: 1.1.1-rc2 becomes 1.1.1

Release Schedule

In the ideal world, a release branch has a lifetime of about two weeks. That is, two weeks before a scheduled release, a release branch is created off the development branch, and no further development is allowed to take place on the release branch. This is known as 'code freeze'. The aim is to weed out all remaining bugs and generally harden the release candidate(s).

Working with gitflow in a release setting

The premise for working with gitflow in the release process is, that the repository is gitflow enabled. Basically it just means that when you do a git branch -a, you will see, as a minimum the following picture:

* develop
  master
  remotes/origin/HEAD -> origin/master
  remotes/origin/develop
  remotes/origin/master

Further Reading

For the concrete release project, see Release Plan and Actions