【万字长文】一文看懂持续部署按需发布！DevOps部署和发布方法大全 （下）

一、支持不同发布方式的技术实现

1.1 特性开关（Feature Toggle/Feature Flag）

利用代码中的特性开关（Feature Toggle/Flag/Switch）来控制发布逻辑，在生产环境中不用编写代码，不用发布新版本，在线上运行时，通过开关，打开或关闭特性。

一般不需要复杂的发布工具和智能负载均衡（Load Balancer）的配合，是一种相对比较低成本和简单的发布方式。

当开关关闭的时候，实际上体现的就是部署，将新版本部署到生产环境的时候，用户不可见，当打开开关的时候，功能对用户可见。所以特性开关很好的支持了将部署和发布解耦。

同时特性开关的各种应用方式可以很好的支持黑启动发布，金丝雀发布，灰度发布，A/B测试等。

如下图所示，特性开关对所有人有效。这是最简单的一种方式，与20年前的License许可证方式类似，例如：

• ToC的例子，所有的用户使用同样的单体软件部署到PC上之后，根据用户的购买的License，打开和关闭某些特性。
• ToB的例子，电信行业，例如华为和中兴卖给中国移动的设备，在部署到客户网路之中后，不用升级软件，只要购买了新的License，相应的特性就会被打开。

1.2 特性分支（Feature Branch）

通常使用分支隔离不同版本代码，生产环境是老版本，新的发布使用特性分支对应的新版本；而使用不同特性分支同时发布不同的版本进行A/B测试也不少见。

1.3 抽象分支（Branch By Abstraction）

增量上线的版本，在生产环境，部分功能业务逻辑运行在老代码上，部分功能运行在新版本上。

简单来说，使用设计手段，例如设计模式、面向方面编程AOP（Aspect Object Programming）等，允许在代码层面存在两个版本的代码。

抽象分支通过如下几个步骤进行大规模增量式修改：

• 在你想改变的那部分代码之上创建一个抽象层。
• 对其余部分的代码进行重构，使其使用这个抽象层使用其之下的代码提供的功能。
• 在新的实现代码里实现一些新的类，让其上的抽象层根据需要，选择性的导向旧代码或新增的类上。
• 剔除原有的旧实现。
• 清理，并重复前两步，如果需要，可同时交付你的软件。
• 一旦旧实现完全被代替后，如果你愿意，可以移除那个抽象层。

老马（Martin Fowler）指出，这些步骤也可以变化一下。“在最简单的情况下，你可以创建一个抽象层，然后重构，让所有的代码都调用它，然后再新写一个实现，最后切换一下就行了。但是，还可以将它分开做。比如，不创建整个抽象层，而只是创建将要修改的功能的一个子集，迁移这部分代码，然后再做下一部分（此时新旧代码共存）。

二、Facebook的案例

2.1 Facebook网站持续部署

开发人员的分支代码每天都会提交代码到主干Master分支，可以说开发人员的特性分支是一个短生命周期的开发分支，可以忽略不计，视作主干开发分支发布。

Facebook网站采用一周的迭代周期，在一周之内频繁发布上线给用户。

新版本是从主干Trunk上开一个分支，名为为latest，代表着最新的发布分支，包含着上周就绪但没有cherry pick摘取到上一个版本代码，即最新的代码代表着所有的代码，一部分代码已经在上个版本发布，一部分是未发布但是就绪完成的代码，然后在周二的时候，因为上一个版本发布分支的名字已经从production改为defunct, prodution名字被释放，就可以将latest分支重新命名为produciton。

总结下，这个发布分支从上周日到周一的时候叫做latest分支，周二到下周一的时候叫做production分支，无论如何改名字，都代表着发布分支，在下面的描述汇中我们统一称之为发布分支。

对于新版本，从周一到周日这个七天里，每天都会选取这个新版要发布的代码，就是下图中主干上字母C带红色框的图标，这个提交被摘选合并到发布分支上，就在发布分支上构成了一个最新发布（紫色五角星代表的版本）但是这个发布仅仅对Facebook员工可见，而最终用户不可见。

从周二开始，每天正式发布给用户1-2次（绿色的五角星，版本号294.0，294.1，294.2 …… 294.6），下周一结束时发布最后一个版本294.7。

经过统计，每个小版本平均包括92行新增或者修改的代码，每个开发人员每周推送到生产环境3.5个软件更新，总体结果是Facebook网站每天可以达到上千次的部署。每个开发人员对自己提交的代码负责，没有单独的测试团队，仅仅要求提交代码之前做代码的同行评审。

Facebook通过黑启动（Dark Launch）阶段，路由一部分真实用户访问后端服务，这时候Facebook的页面与聊天服务器建立连接，查询状态信息，并模拟消息发送，但是使用的是老用户页面，并没有修改界页面显示服务器端返回的消息，这样就可以在全面上线前进行压力测试，模拟新功能带来的影响。

2.2 Facebook移动端App持续部署

2016年3月公开的报告显示，Facebook安卓App采用了一周的迭代，开发测试的周期是一周，而为了上线需要灰度和提交市场，还需要花费一周的时间，所以它的模式是1+1模式，而对于用户来说，每周都可以在应用市场上看到最新的版本。京东商城APP的模式是2+1模式，即开发测试周期是二周，再加上一周的灰度和提交市场时间，京东金融APP的模式将会在2021年对齐京东商城APP的2+1模式。

• 预推送测试（Pre-Push Testing）：每个开发人员从主干Master上拉一个本地分支，在本地分支开发，在本地经过单元测试，静态代码扫描，以及部分集成测试之后，进行代码评审。
• 推送中（On push）：代码评审之后就启动合并到Master的推送请求，代码在真正的push到master分支之前，触发了自动化测试，包括：单元测试，黄金流程（被大量使用的功能以及核心流程）的冒烟测试，以及简单的新功能测试确保新构建没有问题（build test）；所有的自动化测试通过后，本地分支代码就被允许自动合并到master分支，如果出现合并冲突，相关的开发人员就解决冲突。
• 在主干和发布分支上持续测试：每隔几个小时，并行的在主干和发布分支上，持续的运行所有的自动化测试，包括：全面的的build test, 回归测试以及性能测试等。

八、总结

Jez Humble在《精益企业》中引用保罗·哈曼特（Paul Hammant）的部署加速度（Deployment g-forces），每天发布100次采用的是黑启动，蓝绿部署和金丝雀发布，如下图所下，图中将黑启动翻译成了灰度发布。

以上各种部署、发布以及支撑技术，对比总结如下：

参考