Continuous integration and continuous delivery with git-flow

Question

We have been doing continuous integration and continuous delivery since a while with Subversion commits as the pipelines triggers. Recently, we started using git in some projects with git-flow and we are trying to decide which of the branches of git-flow should we use to trigger the continuous integration and continous delivery pipelines.

Here are two approaches:

1. Use develop branch

Problem: With git-flow we are supposed to deploy the release (or master) branch in production, so we would have to build two different pipelines, one for continuous integration (branch develop) and one for continuous delivery (branch master). This could introduce bugs in production because the version in production will not be the same that the one in other environments (integration, test, staging).

2. Use master branch:

Problem: This way, we would not have a truly continuous integration, since changes to these branches are pushed not very frequently.

Which is the rigth branch to use in the pipelines?

Answer 1

Git-flow and continous integration are, by definition, incompatible. Branches are a mechanism for delaying integration: when you commit to a branch other than master (or trunk, if you come from Subversion), you are avoiding continous integration. Doing continous integration is simple, but not easy.

Answer 2

The truth lies between the two. If you want to adopt git-flow in a strict CD pipeline, you should use the release-branch for your CI:

1. For every (batch of) develop-branch commit(s), let your CI server automatically create a release-branch and run all your tests on it.
2. If it fails, let it report and/or delete the branch, otherwise merge it to master.

The basic idea comes from John Ferguson Smart's slide about CI/CD in Java Maven projects (BDD in Action, Jenkins Definite Guide).