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

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

才怪。

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

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

主干开发、主干发布；

主干开发、分支发布；

分支开发、主干发布。

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

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

“主干开发、分支发布“则是在临近发布时，从主干上复制一份代码作为发布分支，在此发布分支上进行测试、缺陷修复，质量达标后将此分支的代码部署到生产环境。这种方式将分支上的缺陷修复与主干上的新功能开发分离，测试不影响新功能的开发工作。同时发布分支与生产环境中运行版本对应，某个线上版本出现问