GitFlow: merge to master first or after prod release?

Question

Learning GitFlow and I have some concerns that I don't see addressed in any of the docs/articles I've read about it.

At some point code on the develop branch needs to be deployed to a QA/staging environment and tested rigorously. So with GitFlow you cut a release branch off of develop, and then you deploy release to said staging environment.

First, just wanted to clarify something real quick: the very first time a particular project/repo goes through this process, you'll actually be forking/creating this new release branch from develop, yes? And that all other times in the future, you're simply merging develop into release, yes?

So then QA tests the release branch on the staging env, all looks good, and we're ready to deploy to prod. Do you:

• Deploy to prod and then merge release into master? ; or
• Merge release to master and then deploy to prod?

I ask because it seems like in the former case you would need to deploy the release branch to prod, then deploy to prod, and then merge to master. Which sounds OK, but often prod and non-prod environments are not identical and code that runs perfectly fine in staging chokes the second it fires up on prod servers. I know GitFlow supports the concepts of hotfix branches but they are reserved for minor fixes. In the case of a complicated fix that requires a rollback/backout release, we now have "dirty code" (code that breaks prod for some reason) merged into master.

And in the latter case, it might take hours or even days (especially if you need to involve IT/Ops to do prod deploys) from the time you merge and put in the prod release request in, to the time the prod deploy actually occurs. And during this time you have a master branch that says "features X, Y and Z are in prod" but they are actually not.

I'm wondering if GitFlow actually solves this somehow or what the known workarounds to either case are.

Answer 1

The project I work in is very chaotic, decisions change in a matter of minutes, so my strategy is to procrastinate as much as possible software configuration management decisions.

Particularly, merging into master: we only merge to master after we deployed in production and we have a confirmation e-mail that smoke tests worked fine. This way we embrace chaos by managing the risk of decision changes, rollbacks in the deploy, technical problems or whichever issue may happen.

At the beginning we merged into master before going into production, but technical issues, rollbacks, management decisions at the very last minute... caused lots of problems to us, so we changed the strategy, and it's been working fine for the last 3 years.

If, eventually, after going to production some regression is found, that's a hotfix and must be handled like that :)

Answer 2

The release branch that you create is a short lived one, similar to the feature branches that you create. Once the release is finished, you delete the branch. For example, I would create a release/0.1.0 branch, do the work, and then merge.

When deploying to production, I always take the code from the master branch, meaning that I merge the release branch into master first, before deploying.

GitFlow is more about moving forward, not back. Hence why hotfixes are used to create fixes for issues that are identified.

In terms of time taken to get into Production, that is really not a concern of GitFlow, and i don't think it will provide much help in this area. This would be an issue for you regardless of which branching strategy you use.