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:
release into master? ; orrelease 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.
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.