GitFlow: merging for the first or after the release of prod?

Question

Studying GitFlow, and I have some problems that I do not see in any of the documents / articles that I read about this.

At some point, the code in the develop branch must be deployed to a QA / midpoint validation environment and checked strictly. Thus, with GitFlow, you shorten the release branch from develop , and then deploy release to the specified staging environment.

Firstly, I just wanted to clarify something real: the first time a particular project / repo goes through this process, you will actually fork / create this new release branch from develop , right ? And that all other times in the future, you just combine develop into release , right ?

So, QA checks the release branch on an intermediate env, everything looks good, and we are ready to deploy in prod. You:

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

I ask because in the first case you need to expand the release branch to prod, then expand to prod, and then merge to master . Which sounds fine, but often prod and non-prod products are not identical, and the code that works fine in intermediate chokes, the second runs on prod servers. I know that GitFlow supports patch branch concepts, but they are reserved for minor fixes. In the case of a complex fix requiring rollback / rollback, we now have a "dirty code" (a code that breaks prod for some reason) merged into master .

And in the latter case, it can take several hours or even days (especially if you need to use IT / Ops to deploy prod) from the moment of merging and entering a request for release of prod at a time when prod deployment is actually happening. And during this time, you have a master branch, which says: "the functions X, Y and Z are in prod", but in fact they are not.

I am wondering if GitFlow really solves this or by some known workaround for both cases.

Answer 1

The release branch you created is short-lived, similar to the function branches you created. Once the release is complete, you will 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, that is, before deploying, I will merge the release branch into master,

GitFlow is more about moving forward rather than backward. Therefore, why fixes are used to create fixes for identified issues.

From the point of view of the time taken to get into Production, this is really not a GitFlow problem, and I do not think it will provide much help in this area. This will be a problem for you, no matter what branching strategy you use.

Answer 2

The project in which I work is very chaotic, decisions change within minutes , so my strategy is to postpone as many software configuration management decisions as possible .

In particular, the merger with the master: we leave only after we deployed in the production process , and we have confirmation by e-mail, in which smoke tests work fine . In this way, we take chaos by managing decision risks, rollbacks in deployment, technical issues, or whatever happens.

In the beginning, we merged with the master before starting production, but technical problems, kickbacks, management decisions at the last minute ... caused a lot of problems, so we changed the strategy, and it works great for the last 3 years.

If, after all, after some production regression is discovered, this correction should be processed as follows :)