3

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.

Improve this question
2
  • you deploy to production from master. so you have to have merged in the release branch before you deploy to prod Commented Mar 31, 2020 at 14:42
  • Yes sorry - that is what I meant by closing the release branch - merging it into master and other associated tasks. But would you only do that just before you go to production or would you do that just before you go to uat? Commented Mar 31, 2020 at 14:52

3 Answers 3

Reset to default
3

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.

Improve this answer
3
  • I can see where you're coming from RE the example about production crashing but if you're going to redeploy without making changes then you'll have the original artifacts to deploy from, the branch won't be required. If you need to hotfix a production issue then you can pull using the release tag of the version that is on production. I guess there are solutions for every scenario someone comes up with and if your answer is the best practice then I would be happy with that. Commented Apr 1, 2020 at 7:39
  • I think the quote you have referenced answers my question and this can be considered the best practice when using gitflow. "We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state". In other words, don't merge the release into master until it has been signed off my the client. Thanks Commented Apr 1, 2020 at 7:55
  • That's a good point about using tags. We don't use them where I currently work, but I can see the value. RE keeping the build artifact, another good point, but I can still imagine a scenario where the required artifact is no longer around and must be rebuilt from the master branch. Commented Apr 1, 2020 at 14:32
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.

Improve this answer
0

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.

Improve this answer
8
  • This is one of my concerns. The fact that your release branch (on the uat environment) should match your master branch after you close the release is just the theory and can't be guaranteed - which is why I feel that closing the release (merging it into master) and then deploying master to uat and then production once signed off by the client seems safer to me - but i'd like to follow a best practice - but I can't seem to find a best practice Commented Mar 31, 2020 at 14:56
  • it's a flaw in the git flow model unfortunately. I would suggest forgoing the release branch completely. merging dev into master for UAT. You run the risk of having to fix the currently deployed version before signoff, but you can always branch from an earlier commit on master if required. Commented Mar 31, 2020 at 15:04
  • In theory release before merging is the same as master after the merge. But in practice this might not be the case. I'm struggling to think of an example where a release branch before merging to master and master after merging the release branch are different. Do you have an example of this? Commented Mar 31, 2020 at 21:01
  • sure, just check something to master without merging to the other branches Commented Mar 31, 2020 at 22:49
  • @Ewan I suppose, but that's no longer gitflow. That's such a huge deviation from gitflow that I'm not sure how it's applicable to a question about gitflow. Commented Mar 31, 2020 at 23:19

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.