DevOps探索之旅（三）——代码分支策略

做了大量前期的学习和准备，小开的DevOps工程师迫不及待地打开Jenkins开始设计自己的持续集成流水线：第一步，下载代码，只要指定代码库的路径、凭证和分支就可以了，简单！

才怪。

路径和凭证是相对固定的。分支？每个项目/产品都有多个分支，他们之间也各不相同，我在脚本里应该写哪个？为什么会存在这些五花八门的分支形式？带着这些疑问，D工（小开的DevOps工程师的简称）对代码的分支策略进行了一番探索。

基本的代码分支模式有三种：

主干开发、主干发布；

主干开发、分支发布；

分支开发、主干发布。

最简单的分支策略就是没有分支。“主干开发、主干发布“的模式下，代码库中只有一份代码，大家所有的新开发代码都直接提交到这份主干代码上，发布时也直接将主干代码部署到生产环境中。看过武侠小说的同学都知道，用最简单的招式的都不是一般人，而是张三丰，是独孤求败，是SSS级的大BOSS。这时就有观众要问了，那么普通人使用会有什么问题呢？

想象一下，大家都往一个库里直接提交代码，每个人的代码质量直接影响到整体代码质量。在某个时间截面上，代码库中可能存在未经测试的代码、经测试需要修复的代码、甚至功能未完成的代码，代码质量乱作一锅粥。在一些追求卓越的公司里，每提交一行代码，就必须经历一系列代码评审和自动化测试的九九八十一难，确保这次提交不会糟蹋了主干分支；也有一些公司会采用“特性开关”技术来开启或隐藏某些功能特性。这都需要健壮的软件工程过程和完善的自动化工具链这种强大的内力支持，否则会导致代码逻辑和质量的失控。

“主干开发、分支发布“则是在临近发布时，从主干上复制一份代码作为发布分支，在此发布分支上进行测试、缺陷修复，质量达标后将此分支的代码部署到生产环境。这种方式将分支上的缺陷修复与主干上的新功能开发分离，测试不影响新功能的开发工作。同时发布分支与生产环境中运行版本对应，某个线上版本出现问题，能方便地找到对应的分支进行修复。但是这种基于“主干开发”的模式依然存在一颗老鼠屎坏了一锅粥，以及需要“特性开关”的问题，且如果对发布分支的数量不加约束，可能又会引起分支数量和版本号的混乱。

至于不是绝顶高手的我们大多数人，用的较多的还是“分支开发、主干发布“的模式。当开发新特性时，会基于主干拉出一条特性开发分支，开发人员在特性分支上完成功能开发和验证，合并时需要发起合并请求，对特性分支代码评审通过后合入主干，最后对主干进行集成和系统测试。

这种方式的好处在于：

对主干代码的质量起到了一定的保护作用，防止了把老鼠屎直接丢进一锅粥里；

在分支合并之前，每个分支之间的开发活动互不影响；

团队可以自由选择想要发布哪些分支的特性，而不是所有特性的代码混在一起分不出来。

而使用这种方式需要注意：

一般按照需求特性来建立分支，这就要求将需求拆分到一定细致的颗粒度，确保一条特性只在一条分支中；

在设计上降低特性之间的耦合性，尽量减少不同的分支修改同一份代码文件的情况；

分支存在的周期不宜太长，否则会和主干存在过大的差异而导致合并时的冲突问题；

在构建持续集成流水线时，需要进行参数化构建，定义分支名、环境等变量。

看过武侠小说的同学又知道，少林有南北之分，华山有剑气之争，不同的人和环境导致在相同的基础上衍生出不同的流派。同样地，基于上述第三种“分支开发“的模式也在各种使用场景中演进出更多的形式和模型，常见的有GitFlow、GitHub Flow、GitLab Flow以及阿里的AoneFlow等。

GitFlow的分支包括：

Master：正式版本的发布分支；

Development：对新功能进行集成的分支；

Release：用于测试和缺陷修复的预发布分支；

Feature：开发功能的特性分支；

Hotfix：紧急修复线上缺陷的分支。

各分支之间的创建和合并关系如下 

 GitFlow好复杂，GitHub表示不喜欢，就出了个简化版，专门配合持续集成和发布。当开发新特性或修改缺陷时，从Master上创建一个新分支，在这个新分支上提交代码并自测后，提交Pull Request，在审查团队或人员审查通过后对代码进行部署，并合并入Master。

GitHub Flow适合在特性分支合入master后就能马上部署到线上的那些项目，如果特性分支存在的时间够短，就接近主干开发主干发布的模式了。有些团队觉得这个对能力的要求还是有点高，自己这么玩不一定能保证质量，GitLab于是就在GitHub Flow的基础上又改良了一下，变成了GitLab Flow。此模式下开发人员向Master提交代码，需要发布时将Master上的待发布代码捡出（Cherry Pick）到预发布分支上，在预发布分支上进行测试和缺陷修复，质量稳定后再合入发布分支进行发布。

 

上述的模式都是先将新特性合并入主干或长期分支，再从主干直接发布或者拉出分支发布。阿里又想了个新套路AoneFlow：新开发的特性先不合入主干，而是从主干拉取临时的预发布分支和发布分支，新特性先合入这个预发布分支和发布分支，在此分支上测试部署通过后再合入主干。

 

这种方式适合面对上线之后频繁的需求变动情况。上线后的某些功能可能由于甲方的原因需要延迟或取消，或者某项功能存在严重缺陷需要排除。若此时功能特性已合入主干，就需要从码山中将这部分代码剔除出来，那可遭老罪喽。而在此模式下只需将临时的发布分支删掉再重新建一个，把需要的特性合并进来即可，避免了手工挑拣代码的问题。

说了这么多分支策略，是时候做出你的选择了。

《持续交付2.0》一书中讨论了分支策略与发布周期的关系。通常开发周期极长的项目制发布团队和发布频率极高的团队会采用“主干开发、主干发布”的分支策略；次之的团队会使用“主干开发、分支发布”的分支策略；发布周期和频率中等的团队会选择“分支开发、主干发布”的分支策略。

所谓大道至简，大象无形，“主干开发“的策略不用考虑分支创建和合并的成本，能够将发布频率提升至极致，这是很多团队努力的方向。但是这种策略需要有完善的自动化代码评审、测试和部署流程，以及特性开关等健壮的软件工程保障机制来达到快速迭代的目的，对自动化水平、工程能力和质量管理都有较高的要求。

达不到主干开发所需能力的团队，则可以在基于”分支开发“的诸多策略中进行选择：

如果有预定的发布周期，并执行严格的代码质量管控和发布流程，可采用Git Flow的形式，常见于大型项目；

如果是较频繁发布但发布周期不确定，同时对质量有一定要求，需要先在预生产环境中进行质量验证的，可选择GitLab Flow或AoneFlow，常见于互联网产品；

若代码经过评审和自动化测试的流程后就可以立即发布应用，不需要再次在预生产环境中进行质量打磨的，GitHub Flow最适合不过，这也常见于通过已有的自动化流程就可以满足业务上质量需求的互联网产品。

最后，基于项目和产品的业务特性，选择、组合、裁剪自己最合适的代码分支策略，创造自己的专属Flow吧。

 （未完待续）