<p>DevOps should take part in this decision, but so are developers, product managers, testers, support and possibly even sales and marketing to some degree.</p>

<p>Branch strategy might affect the final product release, so it shouldn't be a one team decision.</p>

CC BY-SA 3.0
2017-03-10T16:01:17.550Z
I think you should try to somehow rephrase this answer, to address the prior comment as good as you can ... just my 2 cents ... drop me a comment if you ever do, ok?
Pierre.Vriens
CC BY-SA 3.0
2017-03-03T13:53:49.970Z
This is seing DevOPs as a role, which is more an employer buzz word than a reality in this case. If the team is responsible of its own product, the team is obviously warranted to choose its way of working. Multiples products team working on a large number of different branch strategies may become a problem for a shared CI/CD and quality metrics collection in the company.
Tensibai
CC BY-SA 3.0
2017-03-03T13:39:23.663Z
2017-03-03T13:39:23.663Z
Rsf
<p>Branching strategy is a very clearly a business decision in which the DevOps engineer should be the primary expert, explaining all the trade offs. There are some strong positions on this issue in the community, very clearly Jez Humble is on one side with his book of Continuous Delivery. You could see him talking about it <a href="https://www.youtube.com/watch?v=ZLBhVEo1OG4" rel="nofollow noreferrer">here</a>. Here would be a <a href="https://www.youtube.com/watch?v=30yN4hefrt0" rel="nofollow noreferrer">video</a> by panel of experts on the topic. And here is my highly up-voted <a href="https://stackoverflow.com/questions/597707/best-branching-strategy-when-doing-continuous-integration/605337#605337">answer</a> on StackOverflow specifically on topic of feature branches. So clearly this is a big topic for DevOps.</p>

<p>One thing that people often say (Jez Humble mostly) is that feature branches are evil. You will need a (n-1)(n-2)/2 merges <em>[combination number n-1 over 2]</em> for n independent feature branches. Which comes to some very high numbers at 10+ feature branches. And because merging is hard and no publicly available version control systems do it will, then the entire Software Industry is moving away from software releases and software on premises to Software as a Service, where the only way is forward and software is both developed and maintained for you by the vendor.</p>

<p>As far as I know, there is only one company that can do high quality, business critical software on premises, with maintaining 10+ years of past major releases, back-porting patches through multiple waves of code refactoring and capable of working regularly on dozens of major feature branches per release and thousands small features developed on their individual feature branches and being continually merged as full features and not individual commits. The code has also been released on 14 different architectures. That company is Oracle, the product is RDBMS and they have been practicing what is now called DevOps since at least 1990. Hundreds of code deployments a day back in 2001 would be pretty standard. The reason why they are able to do it is through rigorous coding standards, invariant test suite and a proprietary version control system I've spent 10+ years of my life developing. A system that can do 99% of all merges through automation.</p>

<p>Everyone else pretty much only patches the most recent major release version past a certain stage/size of a project or it takes extreme amounts of human resources to merge all the patches to all the possible release versions and extreme amounts of human or compute resources to test them all. For example in Linux kernel you would have a maintainer for X.odd development version and later stability branch maintainer for X.even version, but you would see not patches for X-1.Y versions. Sometimes Linux distributions would maintain kernel version in their LTS release, but only at high cost and with varying code quality among distributions. And that is a high visibility project with enormous resources poured into it. </p>

<p>The primary reasons for this discrepancy are differences in:</p>

<ol>
<li>Adherence to Coding Standards and Code Styles</li>
<li>Complete coverage by invariant test suite, which can catch bugs for which no tests were written specifically.</li>
<li>Version Control System capable of high levels of Automation.</li>
</ol>

CC BY-SA 3.0
2017-03-07T06:05:20.610Z
2017-03-07T06:05:20.610Z
2017-05-23T12:39:34.013Z
Jiri Klouda
<p>In a <strong>mature</strong> DevOps organisation would choosing a product/product line integration branch strategy be part of DevOps?</p>

<p>What do I mean by integration branch strategy?</p>

<p>For example a product team has to integrate 20 features in a certain interval of time to meet some time to market release requirements. </p>

<p>One potential approach would be to use feature branches in a waterfall manner as they've deen doing for years - each feature is developed and tested in their own branch and only merged into the main branch (from which the release branch will be pulled) after metting the respective feature QA goals. </p>

<p>But the total integration time estimate - 20 feature branch merge windows multiplied by the average merge duration (from the team's branch merge historical data) is maybe too high.</p>

<p>Another approach is to pull say 4 intermediate integration branches, each of which being used by 5 of the features branches. This way all 20 features will be integrated into the 4 intermediate branches in a 5 branch merge windows interval. Which would be followed by a 4 other branch merge windows interval for integrating these 4 branches into the main branch, bringing the total integration estimate to 9 windows, much better than 20. Yes, some of the gain will probably be cancelled by higher degree of difficulty of last 4 merges.</p>

<p>Another approach would be to go straight for trunk-based development (true CI integration into the main branch) with practically no branch merges.</p>

<p>The process of selecting one such strategy is what I'm referring to as branch strategy.</p>

<p>Note: the actual SCM repository is irrelevant, it can be any combination of repos managed together as a single one, the term <code>branch</code> denotes just the common logical representation of whatever physical/actual repo branches exist in that combination.</p>

CC BY-SA 3.0
2017-03-07T06:12:47.750Z
You cannot avoid merges by aggregating them. It does not work. There will be the same number of conflicts regardless of the aggregation. Aggregation will actually make things worse, because a branch with 5 aggregated branches in it, might for conflict resolution require all 5 of those developers with their individual level of knowledge of the code. If the version control system cannot distribute merge conflicts among multiple developers, then they have to all gather at a single computer or somwhow pass the torch among themselves in merging the branch, which requires the coordination.
Jiri Klouda
CC BY-SA 3.0
2017-03-02T16:14:20.330Z
you assume that DevOps is an entity in an organisation (a team, a person) ... many would disagree.
Evgeny Zislis
CC BY-SA 3.0
2017-03-02T16:15:52.387Z
Indeed, dropped that part :)
Dan Cornilescu
CC BY-SA 3.0
2017-03-02T16:40:13.253Z
I'd say yes, but that's not an answer per se.
Tensibai
CC BY-SA 3.0
2017-03-02T16:54:18.480Z
Can you please expand a bit on what "integration branch strategy" means in your eyes? It seems to be difficult to understand how to answer this question, since the definition of "integration branch strategy" is not clear.
Evgeny Zislis
CC BY-SA 3.0
2017-03-03T00:46:09.397Z
I would say yes, totally. I would even say the the question of the body is completely useless here. DevOps is about building, testing and releasing more often. If you want to bring change to the way something is done, it fits the DevOps culture: https://en.wikipedia.org/wiki/DevOps
Alexandre
CC BY-SA 3.0
2017-03-03T00:53:11.750Z
On a side note, I've seen a few of your questions and it looks like you have a complicated situation on your hands (they all talk about many waterfall repo and the desire to go to a trunk based development). Yet, none of your questions really tackle the issue. I would suggest you take some time to reflect on the situation and come back with one or two clear questions here. So far, it seems like we've been addressing issues related to the problem, but not the problem itself.
Alexandre
CC BY-SA 3.0
2017-03-03T09:52:00.947Z
@DanCornilescu I agree with Alexandre; I don't think asking if it's classified as part of DevOps is really important, but asking directly about integration strategies would be a *very* good question. To your current question, I think the answer would either be "Yes, I think so" or "No, I don't think so", but if you refocused on the actual strategies, you could get really great answers. Thanks for editing so far though; it really does help the site.
Aurora0001
CC BY-SA 3.0
2017-03-03T19:17:20.813Z
Duh, I thought I'm on meta.devops. No, this question doesn't belong here, will delete it shortly. Sorry for the noise :(
Dan Cornilescu
<culture><branch>
Would choosing the integration branch strategy be part of DevOps?
Dan Cornilescu
# Would choosing the integration branch strategy be part of DevOps?

(Asked by: username_0 on 2017-03-02)

In a **mature** DevOps organisation would choosing a product/product line integration branch strategy be part of DevOps?

What do I mean by integration branch strategy?

For example a product team has to integrate 20 features in a certain interval of time to meet some time to market release requirements.

One potential approach would be to use feature branches in a waterfall manner as they've deen doing for years - each feature is developed and tested in their own branch and only merged into the main branch (from which the release branch will be pulled) after metting the respective feature QA goals.

But the total integration time estimate - 20 feature branch merge windows multiplied by the average merge duration (from the team's branch merge historical data) is maybe too high.

Another approach is to pull say 4 intermediate integration branches, each of which being used by 5 of the features branches. This way all 20 features will be integrated into the 4 intermediate branches in a 5 branch merge windows interval. Which would be followed by a 4 other branch merge windows interval for integrating these 4 branches into the main branch, bringing the total integration estimate to 9 windows, much better than 20. Yes, some of the gain will probably be cancelled by higher degree of difficulty of last 4 merges.

Another approach would be to go straight for trunk-based development (true CI integration into the main branch) with practically no branch merges.

The process of selecting one such strategy is what I'm referring to as branch strategy.

Note: the actual SCM repository is irrelevant, it can be any combination of repos managed together as a single one, the term `branch` denotes just the common logical representation of whatever physical/actual repo branches exist in that combination.

**Tags:** culture, branch

> **Comments:**
> **username_2**: you assume that DevOps is an entity in an organisation (a team, a person) ... many would disagree.  
> **username_0**: Indeed, dropped that part :)  
> **username_3**: I'd say yes, but that's not an answer per se.  
> **username_2**: Can you please expand a bit on what "integration branch strategy" means in your eyes? It seems to be difficult to understand how to answer this question, since the definition of "integration branch strategy" is not clear.  
> **username_4**: I would say yes, totally. I would even say the the question of the body is completely useless here. DevOps is about building, testing and releasing more often. If you want to bring change to the way something is done, it fits the DevOps culture: https://en.wikipedia.org/wiki/DevOps  
> **username_4**: On a side note, I've seen a few of your questions and it looks like you have a complicated situation on your hands (they all talk about many waterfall repo and the desire to go to a trunk based development). Yet, none of your questions really tackle the issue. I would suggest you take some time to reflect on the situation and come back with one or two clear questions here. So far, it seems like we've been addressing issues related to the problem, but not the problem itself.  
> **username_5**: @DanCornilescu I agree with username_4; I don't think asking if it's classified as part of DevOps is really important, but asking directly about integration strategies would be a *very* good question. To your current question, I think the answer would either be "Yes, I think so" or "No, I don't think so", but if you refocused on the actual strategies, you could get really great answers. Thanks for editing so far though; it really does help the site.  
> **username_0**: Duh, I thought I'm on meta.devops. No, this question doesn't belong here, will delete it shortly. Sorry for the noise :(  
> **username_1**: You cannot avoid merges by aggregating them. It does not work. There will be the same number of conflicts regardless of the aggregation. Aggregation will actually make things worse, because a branch with 5 aggregated branches in it, might for conflict resolution require all 5 of those developers with their individual level of knowledge of the code. If the version control system cannot distribute merge conflicts among multiple developers, then they have to all gather at a single computer or somwhow pass the torch among themselves in merging the branch, which requires the coordination.  

---

## 2 answers

### Answer by username_1 on 2017-03-07. Score: 3 | Accepted answer

Branching strategy is a very clearly a business decision in which the DevOps engineer should be the primary expert, explaining all the trade offs. There are some strong positions on this issue in the community, very clearly Jez Humble is on one side with his book of Continuous Delivery. You could see him talking about it [here](https://www.youtube.com/watch?v=ZLBhVEo1OG4). Here would be a [video](https://www.youtube.com/watch?v=30yN4hefrt0) by panel of experts on the topic. And here is my highly up-voted [answer](https://stackoverflow.com/questions/597707/best-branching-strategy-when-doing-continuous-integration/605337#605337) on StackOverflow specifically on topic of feature branches. So clearly this is a big topic for DevOps.

One thing that people often say (Jez Humble mostly) is that feature branches are evil. You will need a (n-1)(n-2)/2 merges *[combination number n-1 over 2]* for n independent feature branches. Which comes to some very high numbers at 10+ feature branches. And because merging is hard and no publicly available version control systems do it will, then the entire Software Industry is moving away from software releases and software on premises to Software as a Service, where the only way is forward and software is both developed and maintained for you by the vendor.

As far as I know, there is only one company that can do high quality, business critical software on premises, with maintaining 10+ years of past major releases, back-porting patches through multiple waves of code refactoring and capable of working regularly on dozens of major feature branches per release and thousands small features developed on their individual feature branches and being continually merged as full features and not individual commits. The code has also been released on 14 different architectures. That company is Oracle, the product is RDBMS and they have been practicing what is now called DevOps since at least 1990. Hundreds of code deployments a day back in 2001 would be pretty standard. The reason why they are able to do it is through rigorous coding standards, invariant test suite and a proprietary version control system I've spent 10+ years of my life developing. A system that can do 99% of all merges through automation.

Everyone else pretty much only patches the most recent major release version past a certain stage/size of a project or it takes extreme amounts of human resources to merge all the patches to all the possible release versions and extreme amounts of human or compute resources to test them all. For example in Linux kernel you would have a maintainer for X.odd development version and later stability branch maintainer for X.even version, but you would see not patches for X-1.Y versions. Sometimes Linux distributions would maintain kernel version in their LTS release, but only at high cost and with varying code quality among distributions. And that is a high visibility project with enormous resources poured into it.

The primary reasons for this discrepancy are differences in:

1. Adherence to Coding Standards and Code Styles
2. Complete coverage by invariant test suite, which can catch bugs for which no tests were written specifically.
3. Version Control System capable of high levels of Automation.


---

### Answer by username_6 on 2017-03-03. Score: -7

DevOps should take part in this decision, but so are developers, product managers, testers, support and possibly even sales and marketing to some degree.

Branch strategy might affect the final product release, so it shouldn't be a one team decision.

> **Comments:**
> **username_3**: This is seing DevOPs as a role, which is more an employer buzz word than a reality in this case. If the team is responsible of its own product, the team is obviously warranted to choose its way of working. Multiples products team working on a large number of different branch strategies may become a problem for a shared CI/CD and quality metrics collection in the company.  
> **username_7**: I think you should try to somehow rephrase this answer, to address the prior comment as good as you can ... just my 2 cents ... drop me a comment if you ever do, ok?  

---

