Continuous integration and continuous delivery with git-flow

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.

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

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.