<p>There are different strategies and, depending on your specific problem domain, you need to decide what makes sense for you.</p>

<p>For server side applications, especially micro services, you typically don't need release branches. You can work with pull requests, but once they hit master, it is common to deploy (from master) and never look back. Managing release branches comes with a cost and for server applications, there is not much benefit from my experience.</p>

<p>For other type of applications, release branches do make a lot of sense. In my current job, I'm working partly on Browser extensions where releases need to be planned. In contrast to the server side, pushing a broken extension release is something that you want to avoid at all costs, especially as rolling back is not possible. That is why we have code freezes (every two weeks or so).</p>

<p>At code freeze, we create a release branch from the current master. Trunk based development continues as before, but all new changes will not make it in the upcoming release. Instead there is a testing and stabilization window, where only bug fixes will be accept on the release branch. When a bug is found, it will be fixed on master first, and only then cherry-picked to the release branch. Once bugs are fixed, the release goes out and the whole process repeats.</p>

<p>Stable cycles of around 2-3 weeks tend to work well. Shorter is also good, but longer cycles can be problematic, as it encourages people to squeeze as much as possible in the upcoming release. Otherwise, if you miss it, you might have to wait for months. I would strong recommend to favor multiple small and predicable release cycles over big and unpredictable ones.</p>

<p>Our CI system runs for all development relevant branches (i.e., on master and all pull requests). To be best of my knowledge, we do not run tests for the release branches. Normally, a well-tested bug fix from master does not create problems on the release branch. However, I see no fundamental reason not to run tests on the release branch, too.</p>

<p>If you set it up from scratch, I would include release branches. However, from my personal experience, master (and pull requests) alone should give you most of the benefits already. Running tests on master helps to enforce that development does not break existing tests, or introduces warnings or other coding style violations.</p>

<p>In our setup, the CI system (Jenkins) runs after each commit. If there are no changes, it will not be triggered. However, in my previous job, we had costly integration tests, which were executed once a day but only on master, while unit tests ran after each commit. Again, that depends on your specific project.</p>

CC BY-SA 4.0
2019-11-19T20:19:09.910Z
Thanks @philipp-claßen for such a detailed reply. In my case deployments to production are so tightly controlled by change management with gates etc. that its almost impossible to get changes to prod quickly. While we are moving toward changing our processes, it will take time. Unfortunately, I don't see an alternative other than batching up changes in a release branch.
VKR
CC BY-SA 4.0
2019-11-19T19:49:33.750Z
2019-11-19T19:49:33.750Z
Philipp Claßen
<p>We are currently using Git flow branching strategy and looking to go to a trunk based strategy - although we are quite a ways away from getting there I am trying to get all my ducks in a row, prioritize and eventually get there. I feel that its not practical to go from having multiple branches with merges etc directly to just having one branch with automated CD from that branch. I want to do this in steps while we work up our automated tests, code coverage etc. So, until then we will have to batch up our features for releases. </p>

<p>I was looking at something similar to this:
<a href="https://i.sstatic.net/6I9aE.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/6I9aE.png" alt="Release flow from Azure Devops  -https://docs.microsoft.com/en-us/azure/devops/learn/devops-at-microsoft/release-flow"></a></p>

<p>I could have a release branch where I would cherry pick the commits and batch them up. Obviously, we would have automated tests etc. running on the master branch. But, what about the release branches? What sort of tests should run on the release branch and at what frequency? Running all tests on both branches seems like an overkill. Since the commits are already tested in master branch, should we run only regression tests on release branch to identify any potential issues? Maybe also a CI build on the release branch that at least makes sure that the release branch is in a buildable state after a cherry-pick commit is completed?</p>

<p>I would appreciate your thoughts about this. Thanks for your time...VK</p>

<azure-devops><testing><cicd><branch>
Trunk Based Development - release branch testing
VKR
# Trunk Based Development - release branch testing

(Asked by: username_0 on 2019-11-19)

We are currently using Git flow branching strategy and looking to go to a trunk based strategy - although we are quite a ways away from getting there I am trying to get all my ducks in a row, prioritize and eventually get there. I feel that its not practical to go from having multiple branches with merges etc directly to just having one branch with automated CD from that branch. I want to do this in steps while we work up our automated tests, code coverage etc. So, until then we will have to batch up our features for releases.

I was looking at something similar to this:
[![Release flow from Azure Devops  -https://docs.microsoft.com/en-us/azure/devops/learn/devops-at-microsoft/release-flow](https://i.sstatic.net/6I9aE.png)](https://i.sstatic.net/6I9aE.png)

I could have a release branch where I would cherry pick the commits and batch them up. Obviously, we would have automated tests etc. running on the master branch. But, what about the release branches? What sort of tests should run on the release branch and at what frequency? Running all tests on both branches seems like an overkill. Since the commits are already tested in master branch, should we run only regression tests on release branch to identify any potential issues? Maybe also a CI build on the release branch that at least makes sure that the release branch is in a buildable state after a cherry-pick commit is completed?

I would appreciate your thoughts about this. Thanks for your time...VK

**Tags:** azure-devops, testing, cicd, branch


---

## 1 answers

### Answer by username_1 on 2019-11-19. Score: 3

There are different strategies and, depending on your specific problem domain, you need to decide what makes sense for you.

For server side applications, especially micro services, you typically don't need release branches. You can work with pull requests, but once they hit master, it is common to deploy (from master) and never look back. Managing release branches comes with a cost and for server applications, there is not much benefit from my experience.

For other type of applications, release branches do make a lot of sense. In my current job, I'm working partly on Browser extensions where releases need to be planned. In contrast to the server side, pushing a broken extension release is something that you want to avoid at all costs, especially as rolling back is not possible. That is why we have code freezes (every two weeks or so).

At code freeze, we create a release branch from the current master. Trunk based development continues as before, but all new changes will not make it in the upcoming release. Instead there is a testing and stabilization window, where only bug fixes will be accept on the release branch. When a bug is found, it will be fixed on master first, and only then cherry-picked to the release branch. Once bugs are fixed, the release goes out and the whole process repeats.

Stable cycles of around 2-3 weeks tend to work well. Shorter is also good, but longer cycles can be problematic, as it encourages people to squeeze as much as possible in the upcoming release. Otherwise, if you miss it, you might have to wait for months. I would strong recommend to favor multiple small and predicable release cycles over big and unpredictable ones.

Our CI system runs for all development relevant branches (i.e., on master and all pull requests). To be best of my knowledge, we do not run tests for the release branches. Normally, a well-tested bug fix from master does not create problems on the release branch. However, I see no fundamental reason not to run tests on the release branch, too.

If you set it up from scratch, I would include release branches. However, from my personal experience, master (and pull requests) alone should give you most of the benefits already. Running tests on master helps to enforce that development does not break existing tests, or introduces warnings or other coding style violations.

In our setup, the CI system (Jenkins) runs after each commit. If there are no changes, it will not be triggered. However, in my previous job, we had costly integration tests, which were executed once a day but only on master, while unit tests ran after each commit. Again, that depends on your specific project.

> **Comments:**
> **username_0**: Thanks @philipp-claßen for such a detailed reply. In my case deployments to production are so tightly controlled by change management with gates etc. that its almost impossible to get changes to prod quickly. While we are moving toward changing our processes, it will take time. Unfortunately, I don't see an alternative other than batching up changes in a release branch.  

---

