<blockquote>
  <p>What is the recommended practice?</p>
</blockquote>

<p>The book ”Accelerate” by Forsgen, Humble and Kim documents their research that teams that use fewer long-lived branches are more successful.</p>

<p>The question is then what is the best minimum set of branches for a given team. The answer to that, like many things, is ”it depends”. A team that pushes into production a dozen times a day will prefer tag then release from master. A team that releases once a sprint into an integration test environment for a week before it goes live will generally prefer two branches. </p>

<blockquote>
  <p>Should I use a release branch to push changes out to production or release it off master branch </p>
</blockquote>

<p>My personal experience is that adding branches later if you need them is easy but removing branches is very hard. So given that we want to minimise the number of branches I recommend that small teams who release often always release from a tag applied to master. It's very easy to create a branch from the tag that was last put live if you do need to create a short-live patch release branch. The point is that you want that to be the exception not the rule give the research in the book named above.</p>

<p>I have seen many teams use a two branch approach. To common ones are:</p>

<ol>
<li>Integrate code into a ”develop” branch and deploy to an integration test environment. Then cherry-pick signed-off work down to master where it is tagged to release.</li>
<li>Integrate code into ”master” and deploy into a test environment. Then cherry-pick signed-off onto a long-lived ”release”  branch where it is tagged to released.</li>
</ol>

<p>These approaches are actually identical. The reason to take this “two branches” approach is so that features can be released independently and reordered. </p>

<blockquote>
  <p>Not to mention, there is still some amount of manual testing and that happens on the master branch after developer has completed the changes in feature branch and automation testing, code review is completed and changes are merged to master.</p>
</blockquote>

<p>There isn’t really enough information in your question about how your team actually works to know whether a one or two branch strategy would be a good fit. Your actual release, testing and support ways-of-working dictate the best strategy for your team.</p>

CC BY-SA 4.0
2020-01-26T20:03:56.490Z
2020-01-26T20:09:20.863Z
2020-01-26T20:09:20.863Z
simbo1905
<p>It depends on what do you want/expect from your release strategy.</p>

<p>Since you're at peace with using feature branches, it means you're also at peace with potentially complicated branch merges and the risks they bring into your master branch: breakages, delays, etc.</p>

<p>If you have strict release deadlines you'll have a hard time meeting them directly from master, pulling release branches off master after the needed feature branches are merged will give you a chance to stabilize the release codebase by isolating it from changes for future releases which I presume continue to be merged into master. The smaller changes with a lower commit rate should significantly lower the risks compared with the master branch.</p>

<p>Release branches also allow you to provide to your customers release hot fixes and complex release stories: multiple simultaneously supported releases, major/minor/incremental releases, etc. It would be very difficult if not impossible to achieve these while releasing directly from master.</p>

<p>The drawbacks of using release branches:</p>

<ul>
<li>your costs will increase as each release branch will require maintenance resources, your teams will have to split focus between the master and release branches (which will diverge), context switching may not be insignificant.</li>
<li>issues uncovered either on the release branch or on the master branch but also affecting the release branch(es) may have to be separately developed and committed on each of the affected branches (since the branches diverge the fixes may not necessarily be identical in all branch contexts).</li>
</ul>

<p>If the advantages the release branches offer are of no interest or if their disadvantages are show-stoppers for you and you're fine with an "as-is/take it or leave it" basis for your releases then just use selected master branch refpoints for release candidates and, if they meet your release quality criteria, tag them as releases. If after that any issue is being found with a release - just wait for a subsequent release with the fix (but it may contain other stuff as well).</p>

<p>The major disadvantage of this approach is the difficulty of picking your release candidates in full flow of changes going into master (drinking from the fire hose?). The chances of finding good candidates can be pretty low. What if you don't find any? Attempting to throttle the rate of commits going into master in an effort to stabilize it prior to a release will translate into delayed integration (features staying in their dev branch silos longer than absolutely needed), increasingly complicated branch merges, which will eventually cause compounding delays/slips in all your future releases.</p>

<p>Up to you to chose the lesser evil. This is why I'm a fan of continuous integration - at least the complicated merges are out of the picture. The release strategy considerations still apply with CI - the release strategy kicks in after the integration is done - but the 2 evils are "less bad" :) From my experience significantly less. And with a gating CI system in place it's possible to keep master stable regardless of the commit rate.</p>

CC BY-SA 4.0
2020-01-26T18:11:08.183Z
2020-01-26T18:11:08.183Z
Dan Cornilescu
<p>A common practice is to build and test off of a pull request to master. Your developers create feature branches, and submit a pull request to master when it is complete. This then triggers a build job based on the PR. </p>

<p>For example, if you are using Github and Jenkins, you could use the <a href="https://wiki.jenkins.io/display/JENKINS/GitHub+pull+request+builder+plugin" rel="nofollow noreferrer">Github pull request</a> plugin to run a Jenkins job when a PR is submitted to master. If it passes, then perform your code review and manual testing. </p>

CC BY-SA 4.0
2020-02-28T08:36:02.653Z
Can you back this "common practice" up with some examples or cite some evidence?
Bruce Becker
CC BY-SA 4.0
2019-08-28T17:41:54.153Z
2019-08-28T17:41:54.153Z
Preston Martin
<p>Should I use a release branch to push changes out to production or release it off master branch - the main pipeline where changes are merged by developers of their feature branches?</p>

<p>Not to mention, there is still some amount of manual testing and that happens on the master branch after developer has completed the changes in feature branch and automation testing, code review is completed and changes are merged to master. </p>

<p>What is the recommended practice?</p>

<release-management><release><branch>
Should I use release branch to push my changes?
Zanky
# Should I use release branch to push my changes?

(Asked by: username_0 on 2019-08-28)

Should I use a release branch to push changes out to production or release it off master branch - the main pipeline where changes are merged by developers of their feature branches?

Not to mention, there is still some amount of manual testing and that happens on the master branch after developer has completed the changes in feature branch and automation testing, code review is completed and changes are merged to master.

What is the recommended practice?

**Tags:** release-management, release, branch


---

## 3 answers

### Answer by username_1 on 2020-01-26. Score: 1

> What is the recommended practice?

The book ”Accelerate” by Forsgen, Humble and Kim documents their research that teams that use fewer long-lived branches are more successful.

The question is then what is the best minimum set of branches for a given team. The answer to that, like many things, is ”it depends”. A team that pushes into production a dozen times a day will prefer tag then release from master. A team that releases once a sprint into an integration test environment for a week before it goes live will generally prefer two branches.

> Should I use a release branch to push changes out to production or release it off master branch

My personal experience is that adding branches later if you need them is easy but removing branches is very hard. So given that we want to minimise the number of branches I recommend that small teams who release often always release from a tag applied to master. It's very easy to create a branch from the tag that was last put live if you do need to create a short-live patch release branch. The point is that you want that to be the exception not the rule give the research in the book named above.

I have seen many teams use a two branch approach. To common ones are:

1. Integrate code into a ”develop” branch and deploy to an integration test environment. Then cherry-pick signed-off work down to master where it is tagged to release.
2. Integrate code into ”master” and deploy into a test environment. Then cherry-pick signed-off onto a long-lived ”release” branch where it is tagged to released.

These approaches are actually identical. The reason to take this “two branches” approach is so that features can be released independently and reordered.

> Not to mention, there is still some amount of manual testing and that happens on the master branch after developer has completed the changes in feature branch and automation testing, code review is completed and changes are merged to master.

There isn’t really enough information in your question about how your team actually works to know whether a one or two branch strategy would be a good fit. Your actual release, testing and support ways-of-working dictate the best strategy for your team.


---

### Answer by username_2 on 2020-01-26. Score: 0

It depends on what do you want/expect from your release strategy.

Since you're at peace with using feature branches, it means you're also at peace with potentially complicated branch merges and the risks they bring into your master branch: breakages, delays, etc.

If you have strict release deadlines you'll have a hard time meeting them directly from master, pulling release branches off master after the needed feature branches are merged will give you a chance to stabilize the release codebase by isolating it from changes for future releases which I presume continue to be merged into master. The smaller changes with a lower commit rate should significantly lower the risks compared with the master branch.

Release branches also allow you to provide to your customers release hot fixes and complex release stories: multiple simultaneously supported releases, major/minor/incremental releases, etc. It would be very difficult if not impossible to achieve these while releasing directly from master.

The drawbacks of using release branches:

* your costs will increase as each release branch will require maintenance resources, your teams will have to split focus between the master and release branches (which will diverge), context switching may not be insignificant.
* issues uncovered either on the release branch or on the master branch but also affecting the release branch(es) may have to be separately developed and committed on each of the affected branches (since the branches diverge the fixes may not necessarily be identical in all branch contexts).

If the advantages the release branches offer are of no interest or if their disadvantages are show-stoppers for you and you're fine with an "as-is/take it or leave it" basis for your releases then just use selected master branch refpoints for release candidates and, if they meet your release quality criteria, tag them as releases. If after that any issue is being found with a release - just wait for a subsequent release with the fix (but it may contain other stuff as well).

The major disadvantage of this approach is the difficulty of picking your release candidates in full flow of changes going into master (drinking from the fire hose?). The chances of finding good candidates can be pretty low. What if you don't find any? Attempting to throttle the rate of commits going into master in an effort to stabilize it prior to a release will translate into delayed integration (features staying in their dev branch silos longer than absolutely needed), increasingly complicated branch merges, which will eventually cause compounding delays/slips in all your future releases.

Up to you to chose the lesser evil. This is why I'm a fan of continuous integration - at least the complicated merges are out of the picture. The release strategy considerations still apply with CI - the release strategy kicks in after the integration is done - but the 2 evils are "less bad" :) From my experience significantly less. And with a gating CI system in place it's possible to keep master stable regardless of the commit rate.


---

### Answer by username_3 on 2019-08-28. Score: 0

A common practice is to build and test off of a pull request to master. Your developers create feature branches, and submit a pull request to master when it is complete. This then triggers a build job based on the PR.

For example, if you are using Github and Jenkins, you could use the [Github pull request](https://wiki.jenkins.io/display/JENKINS/GitHub+pull+request+builder+plugin) plugin to run a Jenkins job when a PR is submitted to master. If it passes, then perform your code review and manual testing.

> **Comments:**
> **username_4**: Can you back this "common practice" up with some examples or cite some evidence?  

---

