问题描述
在一个成熟的DevOps组织中，是否选择产品/产品线集成分支策略属于DevOps的一部分？什么是“集成分支策略”？
解决方案
集成分支策略是一个重要的业务决策，需要DevOps工程师作为主要的专家来解释其中的权衡考虑。在社区中，有一些对这个问题有着明确立场的观点。举例来说，Jez Humble在他的《持续交付》一书中阐述了一种立场。你可以在这里观看他对此的演讲：链接。这里还有一个专家小组讨论这个话题的视频：链接。此外，我在StackOverflow上对特性分支（feature branches）这个主题有一个备受赞誉的回答：链接。因此，可以明确地说，这是DevOps领域一个重要的话题。
特性分支（feature branches）被一些人视为“邪恶”。当有n个独立的特性分支时，你将需要(n-1)(n-2)/2次合并操作（组合数公式，n-1取2），在有10个以上特性分支时，这个数字会变得非常大。由于合并操作很复杂，并且公开可用的版本控制系统并不能自动完成，因此整个软件行业正在转向“软件即服务”（Software as a Service），在这种模式下，前进是唯一的方式，软件的开发和维护都由供应商来完成。
据我所知，只有一个公司可以在本地实现高质量、业务关键的软件，同时维护10多年的过去主要发布版本，通过多次代码重构进行补丁后端口，并能够定期在几十个主要特性分支上进行开发，并将成千上万的小特性作为它们各自的特性分支进行开发，然后将其作为完整特性进行持续合并，而不是单个提交。该公司是Oracle，产品是关系数据库管理系统（RDBMS），他们至少从1990年以来一直在实践现在所谓的DevOps。每天进行数百次代码部署，在2001年是相当标准的。他们之所以能够做到这一点，是因为严格的编码标准，不变的测试套件以及我花了10多年时间开发的专有版本控制系统。这个系统可以通过自动化完成99%的合并操作。
除此之外，其他公司基本上只会在项目达到一定阶段/规模后，仅对最新的主要发布版本进行补丁，或者需要极大的人力资源来将所有的补丁合并到所有可能的发布版本上，并且需要大量的人力或计算资源来测试它们。例如，在Linux内核中，你会看到对X.odd开发版本的维护者，以及X.even版本的稳定分支维护者，但在X-1.Y版本中你几乎不会看到补丁。有时候Linux发行版会在他们的LTS版本中维护内核版本，但只是以高成本为代价，并且在不同的发行版之间的代码质量不同。这是一个具有巨大资源投入的高能见度项目。
导致这种差异的主要原因包括：
- 对编码标准和代码风格的遵循程度
- 被不变测试套件完全覆盖，这可以捕捉到没有针对特定问题编写测试的错误
- 版本控制系统具备高度自动化的能力
因此，集成分支策略的选择涉及到以上这些因素的权衡。DevOps团队需要综合考虑业务需求、开发效率、版本维护成本等方面的因素来做出决策。这个过程需要跨部门的合作，确保最终的集成分支策略能够符合产品发布的需求。