Kura Git Workflow

Introduction

Kura has always used the GitFlow branching model. While this model seems reasonable on the paper, in practice it is cumbersome, error-prone and ... The flaws of the GitFlow branching model are addressed in this anti-GitFlow article and its follow-up. The article proposes a simplified Git workflow which differs from the GitFlow model only on two fundamental aspects:

1. There is no develop branch. All the development is made on the master branch
2. Artifacts are released from the head of the release branch and the release tag is applied to the head of the release branch

Kura QA and Release Using the GitFlow Model

The GitFlow model describes the release process as:

1. Create a release branch off the develop branch
2. Start QA and fix bugs on the release branch
3. Merge the release branch on the master branch
4. Tag the master branch
5. Merge the release branch on the develop branch
6. Delete the release branch

This flow is cumbersome due to the need of merging the release branch both on the master and develop branches. It also contains a flaw. The released artifacts should be built from the release tag (4) but there is an implicit assumption that the merge of release branch on master (3) will not cause any conflict.

Having conflicts (and they happened in the past) has the potential to invalidate the last QA iteration.

This last consideration alone is enough to look for a better Git workflow

Kura QA and Release Using the Anti-GitFlow Model

The anti-GitFlow model drops the develop branch and describes the release process as:

1. Create a release branch off the master branch
2. Start QA and fix bugs on the release branch
3. Tag the release branch
4. Merge the release branch on the master branch
5. Delete the release branch

This workflow corrects all the GitFlow defects. When we are done with the QA (2), the release candidate artifacts (jars, installers, etc) are available from the latest CI build of the release branch. We just need to tag (3) the head of the release branch and publish/deploy the artifacts. The release is formally done.

Merging the release branch on the master branch (4) can be considered a finalization or post-release step. Conflicts occurring in this step will be addressed as part of the next development cycle.

Also note that deleting the release branch (5) does not delete the release tag.

Compared with the GitFlow model, there is one less merge and a better confidence that the released artifacts are the same binaries that have been validated by the QA process.

Continuous Integration

To support the new workflow we need a minimum of three jobs:

1. kura-master providing snapshot builds
2. kura-release-candidate providing release candidate builds for QA from the current release branch
3. kura-release deploying the artifacts from the last release candidate build

On Eclipse Hudson the kura-release job can use the Clone Workspace SCM Plugin to only publish/deploy the release candidate artifacts of the last kura-release-candidate build

Differences with the Anti-GitFlow Model

As suggested by Marko Erker we could slightly deviate from the anti-Gitflow model by using the develop branch instead of the master branch. This makes sense because the develop branch has always been used for the next development cycle and people is accustomed to using this branch. With this approach the master branch will basically die.