Git branch-, CI- and release strategy

[Michiel-s]

Intro

Based on some practical experience with working in small development teams (incl. ours here), I would like to propose a slight change in our Git branching strategy and CI and release strategy.

I've also read this blog about 4 branching workflows with Git: https://medium.com/@patrickporto/4-branching-workflows-for-git-30d0aaee7bf. Those are Git Flow, GitHub Flow, GitLab Flow and One Flow.

Our current situation (flavor: Git Flow)

Long ago we decided to have a development and master branch. The development branch is our "working" branch, which contains finished features and working code. Once every month we "release" by merging to master. So master branch is basically only used for releases. With this way of working it takes some time before fixes/features are available for end users (incl. the prototype framework repo). Furthermore, for every step (1. merge to dev, 2. merge to master, 3. release) a full CI workflow is triggered. In our case, bottleneck is the Windows build (+/- 1h), which takes some time.

Proposal (flavor: GitHub Flow)

When working in small teams a simpler setup is possible:

Branching strategy:

• We have a main branch. Not master and development anymore
• Anything in the main branch is deployable/usable
• Fixes/features are performed in feature branches
• We use PR for all changes. PR are signed off/reviewed and then merged into main directly

CI:

• All

Releases:

• We do releases with Github and tags. A release is not more than to flag a certain point in time.
• For releases a Docker image is pushed to Docker Hub
• For releases binary files for Linux, MacOS and Windows are attached to the release

Visually represented

Note! images reused from project where code is deployed. That is not the case is our situation here. "Release to production" in our case means releasing the compiler (on DockerHub and as binary files)

[Michiel-s]

@hanjoosten, what do you think?

I'll try to call you tomorrow to discuss this and also share my experiment of this evening. I've implemented the main branch, the new CI workflows and also did a (test) release v4.4.3 to see if all is working.

[Michiel-s]

If we proceed this way we should:

• [x] remove development and master branch
• [x] change default branch setting on Github
• [x] add branch protection rules for main

[Michiel-s]

Today @hanjoosten and I concluded this is the way forward. @stefjoosten, @RieksJ, @sjcjoosten, please be informed that as of now we have neither master nor development branch. Only a main branch. For features/fixes you can branch of main directly and submit a pull request to main.

Once in a while (at least every month) @hanjoosten will bump the version (using a commit + PR) and create a release tag. Release tags now have the format vX.Y.Z instead Ampersand-vX.Y.Z.

Binary files are automatically added to the releases (see releases)

Docker images are pushed automatically using semantic versioning tags (see: Docker hub). That means that if release with git tag v4.4.3 is created, automatically a docker image with tags v4, v4.4 and v4.4.3 are available. When releasing v4.4.4, the docker images with tags v4 and v4.4 are updated, likewise for Y-releases, the X-tag is updated.