GitFlow: Properly Testing Release Branches & Master

Question

I have been looking for a good branching model in git and found GitFlow would fit our development environment pretty well. However, one outstanding question is how and where to test our releases.

Release branches sound like a place to run all of the regression tests prior to the release. However, release branches are then merged into master, tagged, and that is what finally goes out to production. What happens if there are merging conflicts from release branch to master? Sounds like master needs to be completely re-tested (which could be costly). Even if there are no conflicts, is it safe to simply push that merge to production, or is there a need to run additional basic smoke tests?

Answer 1

After carefully tracing the GitFlow diagram, I convinced myself that there should never be any conflicts when merging into master (that is if the process is strictly followed). The reason, is because of the timeline:

1. Develop branch is created from Master
2. Features are committed on Develop branch
3. Release branch is created (which includes all the commits from Develop so far)
4. Bugs are fixed in Release branch
5. When ready, the Release branch is merged into Master
6. Master must contain all of the commits from Develop + Release branches. Conflicts should not occur because there was nothing done on Master after Develop branch was created (that's the only way conflicts would happen). In addition, the code at this point should be identical to the latest commit on the Release branch, which is means there is no need for additional testing.

I simplified the GitFlow diagram to convince myself of this:

Answer 2

I think that testing should be done at every stage of release. Create a light subset of release tests that you can run directly against production to at least test the basic functionality. Don't load/perf test against production, of course.

Depending on what your product is, and how you push it out, the actual testing can change. We've got a few production servers to which we deploy new release code. Those servers are tested thoroughly, but are not accessible by our customers. When those check out, we swap them out with the rest of our production servers. The deployment and testing is repeated. After everything passes, all production servers are put back into out live pool of customer-facing servers.

In case of some failure, we roll back in much the same way.