Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Reconciling Git Flow and QA

Tags:

git

git-flow

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.

like image 536
RNJ Avatar asked Dec 03 '13 11:12

RNJ


1 Answers

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.

like image 141
tolism7 Avatar answered Oct 11 '22 07:10

tolism7