2

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.

  • 4
    you assume that DevOps is an entity in an organisation (a team, a person) ... many would disagree. – Evgeny Mar 2 '17 at 16:14
  • 1
    I'd say yes, but that's not an answer per se. – Tensibai Mar 2 '17 at 16:40
  • 1
    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 Mar 2 '17 at 16:54
  • 1
    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: en.wikipedia.org/wiki/DevOps – Alexandre Mar 3 '17 at 0:46
  • 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. – Alexandre Mar 3 '17 at 0:53
2

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. Here would be a video by panel of experts on the topic. And here is my highly up-voted answer 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.
-6

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.

  • 1
    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 Mar 3 '17 at 13:53
  • 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 Mar 10 '17 at 16:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.