Reconciling Git Flow and QA

Question

Our project is using gitflow as detailed here My question is how does QA fit into this.

Consider I have one master branch and one hotfix branch. Once hotfix is done then I believe QA should do its stuff on a release from hotfix. If it doesn't pass then hotfix is updated with this fix. QA gets a release again. Now when the hotfix RC passes QA then the code is merged back to master (should be no conflicts and just a straight copy as master is not changed). The production release is then done from master. The concern is though that QA haven't verified this build. They have verified a hotfix build.

How do we reconcile master only be for the production code but have QA testing on near enough production code? Any one got any experience with this scenario? I cannot see anything that details how QA and testing fits into gitflow.

Answer 1

I will try to explain how QA fits into the Gitflow. Here it goes briefly:

It all depends on your definition of "done" as agreed in your team. In my view the definition of done involves only the developer(s) working on the feature hence it is satisfied when the devs finish their work and peer review approves this work to be merged into the main (whatever that is) branch.

QA should kick in only when the release branch (as described in gitflow) is going to be cut.

So, developers do their work from a backlog say of 3 items. That probably means 3 feature branches (I do not use the hotfix term as in gitflow that is reserved for emergency fixes on issues found in production). One at a time (probably at different times) the branches are merged to master. When all are merged then a release candidate branch is cut and from that an artifact is generated for the QA team to run and test.

At the same time the team can be developing and merging other features into the main line (master). Any issues found in the application are fixed in the release candidate branch and the fixes are merged into the main line so they are there in the next release. A new release is given to QA that includes the fixes and the cycle continues.

When QA is happy the production artifact is generated (merge the release branch to master and fire a prod build).

Now I think you are worried that the 2 releases (one from hotfix branch and the one from master) are different releases. This is and isn't true. It is true as the binaries tested by the QA are different and it isn't true as the binaries contain the same code. That is of course assuming that no other code go into master in between and that you build process does not updated assemblies (via maven or nuget automatically) to newer versions.

If your place of work wants you to release the same binaries as the ones verified by QA then you need to produce the production release from the hotfix branch (or by the giflow's scheme the release branch [the green ones on the diagram]). Otherwise you should be ok to release from master.

Answer 2

I extended Vincent Driessen's git flow branching model to include branches which represent the environments TEST, QA and PRD.

Instead of letting MASTER contain the last code in production , I choose to let MASTER by default point to the last version in QA. Then deploying to PRD is just a promotion of a release candidate already on QA to PRD.

You can now do hotfixes on the version on QA, which will probably occur more then doing hotfixes for the production version. Doing a hotfix for production is still possible by resetting the master branch to the version on production you want to fix.

With this in mind your case can be solved with

1) reset master branch to the production version

2) create hotfix branch from master

3) apply the fix to the hotfix branch

4) finish the hotfix branch and merge into master and development

You can now build a release candidate from the master branch which can be deployed on QA for testing and later promote it to PRD when it's ok.