Continuous integration and continuous delivery with git-flow

39
votes

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?

3
gitcontinuous-integrationgit-flowcontinuous-delivery
In my experience git-flow is more suitable for packaged software (something you release on occasion; with discrete version numbers; having possibly several older versions in the wild). It that your case? For a more web based approach (released constantly; the only version that matters is the one live) I’ve found the simpler feature branch workflow or github flow approaches much more suitable. – Hugo Ferreira
Is it possible to do integration, test and staging in other branch then master? – Bernardo Dal Corno

3 Answers

19
votes

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.

11
votes

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).

8
votes

In my view, if you want to apply git-flow in Continuous Delivery, you should have two different pipelines as you said in your first approach.

I'd suggest this approach:

1. Develop branch

  • Develop branch will trigger the Commit Build: As soon a feature is added to the develop branch (on merge or pull request), the CI will build, test (Unit Testing & Code revision) and package the solution (with a "-develop-vX" suffix). So the team is able to react fast in case of failure.
  • Once the Commit Build has finished successfully, the task is done (otherwise, the change is reverted and the developer who committed the change must fix it immediately). In parallel, the Acceptance Test Stage starts deploying the previous build to the Development environment for executing the Acceptance Test Suits (e.g. Functional & Regression testing) without blocking the developer's work. Once it's finished, the develop branch status is communicated to the team. Therefore, the team is aware of the solution's stability during the current Sprint: if the Acceptance Test Stage finishes successfully, the product is ready for merging with the Master branch (Otherwise, it'll be fixed).

2. Master branch

  • Once the Sprint is finished, the stable Developer branch (it's stable) is merged and tagged to Master Branch. So the Master Branch will trigger the Trunk Commit Build that will build the solution, test it and package for deployment (the package now is stored with a release candidate or master suffix).
  • If the Trunk Commit Build finishes successfully (it should work), the Acceptance Test Stage will deploy and validate the acceptance tests against an Integration environment. And in case of success, the new version is ready for production. Otherwise, in case of error at Commit Build or Acceptance Test Stage, the merge is reverted.