Reconciling Git Flow and QA

Question 1

Where does QA fit in? All over.

I get your problem: if you're wanting master to be always ready to release, then you want to make sure your work is tested before you merge to master. But if you don't test against master, what if the combination of your changes and someone else's causes an issue? And if you do both, isn't it a lot of work?

The solution IMO is a combination of automated checks and spreading test effort over hotfix branch & master rather than all on one or the other. It does assume that you (as dev) and I (as tester) are working pretty closely on the same team, rather than in different teams with a load of bureaucratic overhead and formal handovers that stop us collaborating effectively.

Feedback from a tester is most useful when you get it as early as possible. I am happy to test interim work, because if I can save someone having to go back and rip out a load of stuff by finding issues early, that's great, and it also enables me to learn more about the feature earlier (building up my mental model, test data, ideas for automated checks) so I'm not scrambling to catch up when the final build is ready. Ideally, I'd have written you some automated acceptance checks while you were developing, so that you can run those and your unit tests against your branch and master without a lot of extra effort. (In practice, I don't always get to this in time, but when I have it's worked well). And I'd also expect that whatever checks you have running against master, that you also run them against your hotfix branch just before committing.

If there is a lot of work going on in the same area of the app, then I'd want to do at least some quick exploration against master after your merge - possibly more if it's a critical area. Our automated suite has caught some regression issues and I wouldn't want to be without it, but having automation is never a good reason to not do a little critical thinking about risks.

This is one approach: there are plenty of others that may work for you, dependent on your environment. For one interesting approach I heard recently, look up "Improve The Process By Taking Control" by Amy Phillips from Songkick - where they moved some of their test effort after release, on the grounds that hey, production is the closest you can possibly get to a production environment right? Obviously this required use of feature toggles, and might not be acceptable in some environments, but it's a good example of thinking laterally about where it makes sense to put your test effort.

Question 2

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.

Question 3

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.