DevOps(4)之分支模型（ps4如何构建画布）

之前介绍了DevOps的研发效能整体价值，包括效率、质量、持续改进的文化等方面；

同时，针对DevOps实践，比如分支模型、多泳道、灰度、内建质量、度量、运维，也有一些概念性的输入。

接下来针对分支模型进行一个展开，从背景、常见分支模型、分支模型实践方案等方面说明。

背景：

分支模型应该说是DevOps中CI的一个最基础的技术实践，是CI的基座，其他的应用实践基本上是基于分支模型进行展开。

直接影响的是整个流水线，一般有整体流水线，在一个整体流水线中，包括多个子流水线，比如开发流水线、特性测试流水线、集成测试流水线、发布流水线。在这些子流水线中，发布子流水线是基于程序包，与分支模型关系不大，其他的子流水线都是密切相关的。

分支模型是基础，但最本质的问题是要解决研发的开发效率，而效率更高的方式就是让在制品尽量少，以降低需求间的影响。

常见的分支模型：

如何提升？取决于采取什么样的分支模型；

常见的分支模型主要是2大类，基于主干开发还是基于分支开发。

基于分支开发的比如Git Flow， GitHub Flow，基于主干开发的Trunk Based Development。

简单总结下几类的特点，具体参考文档：http://fresky.github.io/2020/03/10/common-branching-models/

Git Flow：

• 主分支有两个：master是部署分支，所有已经发布的版本都在这里。develop是开发分支。
• 有三种支持分支：feature用来做功能开发，release用来准备下一个要发布的版本，hotfix用来在已经发布的版本上打补丁。
• 对于测试来说，必须在release分支和hotfix分支做严格的发布前的测试。
• 在master分支上几乎不会有冲突。

此种分支模型应该是使用最多的模型，分支比较清晰，可以支持各种发布策略，灵活；核心问题就是分支太多，会带来比较高的复杂性。

GitHub Flow：

• master是部署分支
• 所有针对下一个发布的开发都在feature分支
• feature分支经过测试之后merge回master分支，然后发布
• 如果发布之后发现有bug，回滚到master分支的上一个发布版本

此种模型，最大问题是master分支不是都能发布的，比如有个特性有BUG，就需要进行复杂的回滚操作，结合数据库就会更加复杂。

是否能很好的应用，需要有强大的自动化测试能力，以确保开发质量。

Trunk Based Development：

此种模型，基于主干开发的分支模型，所有开发、测试人员基于主干进行开发，当达到一个稳定版本后，生成一个Release分支发布。

这种分支模型相比于Github Flow不能发布的分支可能更多，质量风险更大，所以必须要有系统、全面的自动化测试作为保障才能实施成功。

分支模型的实践：

结合公司的情况，由于自动化做得并不是太好、发布模式的多样式，采取了类似于Git Flow的分支模型，比较好的平衡了研发效率和质量。

具体分支模型如下（双主干开发分支模型）：

说明：

1、分支模型主要解决2类场景：紧急需求（Master）、日常迭代需求（MasterGray），不同需求类型分支隔离，2类需求交付相互之间不影响。

2、持续集成：基于不同需求的分支，持续集成，流式开发，不积压在制品。

3、2种分支模型以最快的方式实现融合集成，减少需求过程中的遗漏和冲突。

最核心的2类场景，2种分支模型，流式开发，持续集成，提高研发的效能。

同时分支模型作为多泳道、灰度的基础支撑实践，也是整个DevOps的基础。

总结：

采取基于分支开发的双分支模型，由于分支太多，复杂度还是蛮高的，对研发团队有一定的要求和挑战。

比如冲突会增加，流水线变多，协调增长不少，过程中的等待也变多变长，分支的数量都是非常大的内容。

理想的方式是基于主干开发分支发布的模式，但这种模式要求还是蛮高，核心是内建质量。

包括意识，开发单测，自动化测试，代码扫描、度量等内建质量的建设，只有这些达到，可以快速验证，缩短等待时间，快速呈现。