Using gitflow, when do people tend to close off the release branch?

Question

We're using the gitflow branching strategy and it works well. What I can't seem to find though is a recommendation on what point people close their releases.

For example, suppose we got 4 environments:

1. develop
2. test
3. uat
4. production

We've been working on a selection of features on the develop environment and we are now creating a release from develop, v1.0.0.

So we take v1.0.0 to the test environment where bugs are raised and we can hotfix them on the release branch. QA pass the release and we want to take it to uat for the client to sign off before going to production.

Where in this process do people close the release branch? When they move from test to uat or when they move from uat to production?

Is there a standard that most people use or is it whatever suits your project? For me there are pros and cons of each option. TBH I see greater benefit closing the release as I take it from test to uat but having the release open until the client has signed it off and it's gone to production makes a lot of sense.

Answer 1

In my experience, the master branch should always be production-ready. If you merge changes to master before UAT takes place, you haven't actually approved those changes to go into production, and thus the master branch is not guaranteed to be production-ready. In fact, this is officially a requirement of git flow:

From https://nvie.com/posts/a-successful-git-branching-model/

We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state.

What if you merge your release branch to master for UAT and coincidentally your production environment completely crashes and must be redeplolyed? Will you deploy the un-verified changes to production, or risk deploying the wrong code by manually branching from the latest good commit on master? Choosing that commit and creating a deployment branch may be fairly straightforward for any with intermediate git knowledge, but convincing management that your branch is good for deploy can be a whole different story. It's much easier if you can definitively say, "Master is always good to go for production".

Regarding your concerns in the comments of Ewan's answer about not putting your production artifact through UAT: If you maintain a consistent workflow of merging only release branches into master and disallowing pushes directly to master, this is very unlikely to be a problem. You can (in my opinion, should) also code-review every release --> master merge as you would a normal feature review.

Answer 2

It depends on the kind of software system that you are building. For example, a multi-tenant SaaS solution where you only support one version in production is different than any type of software system where you may be supporting multiple versions simultaneously.

Regardless of the type of system, I tend not to close the release branch until after the version is no longer supported. This allows you to apply a hotfix to all of the supported versions and create the new release. If you're using good tagging (such as tagging your releases in the master branch), you can create a branch with any given tag as a starting point, but I find it easier if the branch exists.

It's up to you to define what it means by supporting a version.

Answer 3

I think most people prefer to test their development branch.

If you test on feature branches you need n environments for all the different features being developed at any one time, which is a pain.

Given that testing on development is complete and you have a UAT phase to your deployments it makes sense to test the release branch on your UAT env. Presumably testing of the next release continues using the test env and development branch.

When UAT is complete you would merge the release into master and deploy this to production.

You have a bit of a dilemma here in my view. I would like to release the exact same binary that has passed testing. But I would also like to release the exact code that is on master.

In theory release before merging is the same as master after the merge. But in practice this might not be the case.