导读：

敏捷DevOps的一个主要目的是要达成持续的最短的周期进行价值交付，这就离不开快速的部署和发布。那么问题就来了，部署和发布到底是一个概念还是不同的概念？有哪些常见的部署和发布策略？本文将会剖析不同的概念，以及介绍不同的部署和发布的策略，在文章的最后，会对所有的策略和技术进行总结。

什么是部署与发布

在谈持续部署之前，让我们澄清一下什么是部署，什么是发布。

1、在互联网和SaaS之前的时代，通常是，先有发布（Release），再有部署（Deployment）

发布

研发团队发布一个版本，代表着开发完成并且测试完成是一个可以销售的软件，也代表着这个软件的上市

将软件售卖之前，需要把版本复制到软盘、U盘或者刻录到光盘上，通常叫做发布到工厂（RTM，Release to manufacturing）

软件正式上市售卖代表着软件已经Gone Live，上线

部署

如果是面向个人的桌面系统软件，那么由个人担当部署的人员，将软件（来源于软盘、光盘、U盘）进行安装，安装后自行进行配置

如果是面向企业的软件，那么由甲方的IT工程师负责安装和配置，或者是由乙方的服务人员负责安装和配置

还有另外一种情况，在甲方真正安装和配置软件之前，有一个用户验收测试（UAT，User Acceptance Test），在甲方的机房，先安装和配置一套，然后由甲方进行测试，如果测试通过，代表验收成功，就可以正式的去安装和配置

2、在互联网、移动互联网和SaaS时代，通常是，部署就代表着发布

发布

用户能看见软件或者直接使用软件，概念上和互联网之前的年代是一样的，目的都是上市

通常是将一个版本发布到网上（RTW，Release to the web）或者叫做网上发布(Web release）

在中国互联网行业，通常称之为上线（Release to production）

部署

部署变成了将软件包发布到生产环境的一个动作，或者是一个步骤

即通过部署的动作，达成了发布的结果

3、敏捷DevOps时代，部署和发布解耦，变成了持续部署，按业务需要发布

持续部署

持续的，自动化的，将软件包发布到生产环境

SaaS和网站类型的，就是直接部署到网站上

移动应用App类型的会通过各种APP分发渠道，发到应用市场，例如苹果的AppStore，安卓的各种应用市场

按需发布

根据业务需要，发布功能

发布，代表用户看见软件或者可以直接使用软件的功能，即release the functionality to end users

补充说明

对于一些ToB的企业级软件，例如电信行业，通常是软件+硬件整体销售给运营商（例如中国移动），仍然会涉及到发送硬件（例如交换件、路由器）到运营商，然后设备商（例如华为）的服务人员在客户现场进行机房、硬件等的安装和配置，之后才会割接上线

而2011年建立的开放网络基金会开始在业界大力提倡软件定义网络（SDN，Software-defined networking）和OpenFlow协议，在一定程度上解耦了软件和硬件，那么DevOps的理念就有可能被达成，例如在华为生产的软件通过网络直接在中国移动的网络上升级软件

如下图所示，是规模化敏捷框架SAFe（Scaled Agile Framework）的持续交付流水线，部署和发布是解耦开的，部署不意味着用户可见，发布才是功能对用户可见，部署仅仅是将软件部署在生产环境，新的代码变更对于用户来说还是“黑/暗”（dark）的。

让我们正式的定义一下部署和发布，《DevOps实践指南》的定义如下：

部署

是指在特定的环境中安装指定版本的软件（例如，将代码部署到集成测试环境中，或者部署到生产环境中）。

具体的说，部署可能与某个特性的发布无关

如果部署与某个特性发布有关，部署后即时生效，即代表着发布，部署=发布

发布

是指把一个特性（或者一组特性）提供给所有客户或者一部分客户（例如，向5%的客户群开放特性）。

代码和环境架构要能够满足这种要求：特性发布不需要变更应用的代码。

部署和发布是解耦开的，也就是：让部署可以独立于发布单独进行；而特性部署后，业务可以灵活决定什么时候发布，向哪些目标客群发布。如果部署周期过程，就会限制向市场频繁地发布新特性的能力。如果能做到按需部署，或者持续部署，那么什么时候发布新特性，就成了业务和市场决策，而不再是技术决策，所以部署是技术范畴，而发布时业务范畴。

什么是持续部署

持续部署（CD，Continuous Deployment）是将在预发、类生产环境中经过验证确认的特性部署到生产环境的过程，部署后这些特性就已经就绪，需要发布的时候随时发布。

按需发布（Release on Demand）是团队和企业的关键能力。按需发布使得业务具备持续的在最短的前置时间（Lead Time）内，以高频率的方式，让客户使用新功能，从而通过高价值方案响应市场机会。

为了支持业务具备按需发布的能力，特性在业务需要它们之前，必须在生产环境得到验证和等待发布。所以需要将部署过程优化并从发布过程中分离出来，这样将代码变更部署到生产环境，并不会影响整个系统的行为。持续部署的能力使团队可以进行更小的增量的代码变更，并持续地部署到生产环境，但是并不发布，直到业务需要的时间才正式发布给客户。

而对于持续部署的“持续”，每个公司的程度是不一样的。如下图所示，《凤凰项目》提到国外的一些大厂2012年的部署频率和每次部署花费的时间（Deploy Lead Time）。

笔者于2020年在苹果的App Store查看了国内各大主流IOS APP的版本发布情况，大多数的APP是在2周以内发布一次。拿京东来说，在APP市场，大多数情况下，京东商城APP是两周一个版本，京东金融APP也是两周一个版本。对于京东的服务端的发布，基本上是每周有两次上线窗口进行小批量的上线，当然对于紧急的线上问题的修复根据情况随时上线。

如下图所示，《发布！设计与部署稳定的分布式系统 第2版》提到：部署间隔时间有更长的延迟，将会导致每次的部署包含更多的代码变更，结果就是出现更多缺陷和宕机的风险，因此会增加更多的评审环节，那么又大大增加了部署之间的间隔时间。这是一个越来越差的增强回路。正如《发布》这本书所说的“如果每次部署都很痛苦，那么就频繁多次做”，所以高频的持续部署可以颠覆这个恶性循环，并且从以上国外大厂和国内大厂发布的频率来看，充分说明持续的部署是业务按需发布的必要条件。

持续部署实践

蓝绿部署（Blue-Green Deployments）

蓝绿部署是指有两个完全相同的、互相独立的生产环境，一个叫做“蓝环境”，一个叫做”绿环境“。绿环境是用户正在使用的生产环境。当要部署一个新版本的时候，先把这个新版本部署到蓝环境中，然后在蓝环境中运行冒烟测试，来检查是否正常工作，当一切准备就绪以后，向新版本迁移就非常简单了，只要修改一下路由配置，将用户流量从绿环境导向蓝环境就可以，这个时候蓝环境就变成了生产环境，这种切换通常在一秒钟之内就能搞定。如果出了问题，把路由器切回到绿环境上即可，然后在蓝环境中调试，找到问题的原因。所以蓝绿部署，是在部署之后，仅仅一次切换，立刻就向所有用户推出新版本，新功能对所有用户立刻生效可见。

如果由于成本和投资回报的考虑，不能建设两套完全一样的生产环境，那么可以将蓝环境作为预发或预生产环境，将软件的新版本部署在预发环境，并进行验收测试，之后将访问流量引流到这个预发环境，那么蓝环境就是正式的生产环境，同时保持旧版本所在的绿环境不变，直至新版本没有问题后，再将旧版本所运行的环境作为下一个新版本的预发环境。

蓝绿部署中，如果是保持两份一样的数据库，需要处理的问题是数据库的问题，一个是如何快速复制数据库，一个是涉及数据库的事务时如何处理数据的一致性问题。

在电信行业中，通常需要保证99.999%的时间是服务可用的，所以通常会投入冗余的设计和实现，例如一个设备的双CPU、双存储、多个板卡等，双机主备等，网络建设的时候进行冗余设备的设计，通信链路有保护协议时刻进行心跳式的检测，如果某个链路数据不通，就自动切换到另外的链路等等。例如交换机或路由器有两个CPU，一个是主，一个是备，主备之间内存使用内存数据库进行同步，备机如果内存数据库被更新了，就立刻同步到备机的持久化存储中。这样可以保证设备如果有问题的时候主备之间进行切换，同时可以被用来零停机部署、不中断业务升级（ISSU，In-Service Software Upgrade）在standby备机CPU中升级到新版本，再将其切换成主服务CPU，而原来的主活CPU变成了备机待机状态，再将其升级，这样既不影响实时业务，又升级了新版本。

那么在非电信行业，可以考虑两套环境使用同一个数据库，降低技术复杂度和节约成本。

滚动部署（Rolling Deployment）

滚动部署是指从服务集群中选择一个或多个服务单元，停止服务后执行版本更新，再重新将其投入使用，循环往复，直至集群中所有的服务实例都更新到新版本，而不是将所有的服务实例一次性的同时更新。

滚动部署分批进行部署，每次同时更新的服务实例数称之为窗口大小（Window size），根据需要配置每个批次服务实例的窗口大小，例如首先部署2%的服务实例，第二批为10%，第三批为50%，第四批为100%。

黑启动（Dark Launching）

黑启动原意是指将新版本部署到生产环境后，对用户无感。所以黑启动意味着暗部署。

当然，黑启动终极目的还是为了发布，对原有黑启动含义扩展之后，就会先让小部分用户感知新功能，再逐渐扩大感知到新功能的用户范围，那么黑启动就代表发布。

如下图黑启动的本意所示，马丁·福勒（Martin Fowler）在黑启动文章提到，黑启动针对的是后端行为，后端系统部署在生产环境之后，现有用户使用前端界面的时候，新部署的后端功能被调用，但是用户并没有感知，可以对新功能的性能进行监控。也就是说用户和系统的交互逻辑保持不变，用户在界面上没有地方选择新部署的功能，也就是对用户不可见。

《持续交付2.0》的例子如下图所示，用户对新算法的使用是无感知的：

对黑启动本意的扩展，是正式发布给所有用户之前发布给部分用户的过程。黑启动将部署和发布解耦，部署之后，发布给部分用户，这样可以获得部分真实用户的反馈，测试缺陷，评估基础设施性能等。黑启动的黑（Dark）代表用户无感知，也就是新版本的功能已经被部署到生产环境，但是用户无感知：

企业并没有广而告之声明有新版本发布，用户不知道软件已经升级，并且只有发布给选定的小部分用户，他们才能感知到新功能

用户不知道被选定在测试新功能，例如用户界面没有变化，仅仅是后端算法逻辑等发生变化

黑启动的另外一种做法，就是选定的部分用户实际上是公司内部员工，这样内部员工可以先吃自己的狗粮，对新功能进行测试，而真实用户并未真正使用新功能

贾斯汀·贝克（Justin Baker）描述了黑启动有如下几种场景：

场景A——我想发布一个实验性质的功能，验证下是否能增加总成交额GMV

要黑启动这个功能，先发布给1%用户给他们启动这个功能，然后再分别发布给5%，30%用户

在这个过程中评估结果。如果结果是增加了成交额，就可以逐渐增加推出的百分比，否则可以简单地回滚该功能，以便进一步评估和优化这个功能

场景B——我想测试应用的新基础设施，而不必切换所有流量

在将所有流量切换到新的系统架构之前，可以通过专门用于配置管理的开关/标志（toggle/flag）切换路由流量，以黑启动新的基础架构。例如，假设要停止维护自己的队列系统并切换到托管服务。可能会创建一个标志，将一些作业发送到新的托管服务，同时仍将大多数作业发送到旧的队列系统（并且设置了守护程序来监听这两个作业）。然后，可以在监视性能和其他指标时逐渐过渡到全托管服务。

这个发布策略和笔者2009年在敏捷中国大会参加会前Kent Beck的响应式设计培训是一致的，Kent Beck提到响应式软件设计的四个策略：飞跃Leap，并行Parallel，踏脚石Stepping stone，简化Simplification。针对风险比较大的重构或者新的基础设施，可以采用新老两套架构并行的方式，逐步迁移，并且两个架构同时向前发展，直到最终新架构代替老架构。

场景C——我想发布一个新功能给特定的人群进行β测试

新功能对原有用户与系统的交互逻辑进行了修改

通过ID（例如邮件或者用户名等）来圈出特定的要进行测试的β用户群，黑启动新功能给这些特定人群，企业随时可以添加或者删除β用户。

这种场景，被选定的用户群是可以感知新的功能的，这也被称作金丝雀发布，金丝雀发布时黑启动的一种类型

场景D——我想首先给我的VIP用户发布一个新功能

在全面发布给所有用户之前，黑启动允许向VIP用户推出新功能

可以允许用户自己选择加入或者退出黑启动功能

黑启动按用户百分比分批发布，就是在国内互联网常用的灰度发布。黑启动仅仅针对部分机器、服务实例或者客群发布，就是金丝雀发布。

按需发布实践

金丝雀发布（Canary release）

软件行业的金丝雀发布这个术语来自20世纪初期英国煤矿工人在下井采矿之前会把笼养的金丝雀携带到矿井中，如果矿井中一氧化碳等有毒气体的浓度过高，在影响矿工之前，金丝雀相比人类表现的更加敏感快速，金丝雀中毒之后，煤矿工人就知道该立刻撤离。金丝雀发布，在将整个软件的新版本发布给所有用户之前，通过将新版本发布给部分用户，用真实的客户流量来测试，以保证软件不会出现严重问题，降低发布风险。

金丝雀发布也被称之为按阶段发布或者增量发布。

第一批金丝雀用户：先将新版本部署部分机器或者服务实例，并对部分选定用户开放

第二批所有用户：之后再将所有其他机器或者服务实例进行部署，并对所有用户开放

如下图所示，《DevOps实践指南》的Facebook的金丝雀发布模式，采用了不同的环境组A1组，A2组合A3组。

A1组：仅向内部员工提供服务的生产环境服务器。

A2 组：仅向一小部分客户提供服务的生产环境服务器，在软件达到某些验收标准后部署（自动化部署或手动部署均可）。

A3 组：其余的生产环境服务器，软件在A2 组中达到某些验收标准后再部署。

金丝雀发布通常包括以下步骤：

暂存用于部署的工件，包括：构建工件，测试脚本，配置文件和部署清单。

从负载均衡（Load Balancer）中删除“ 金丝雀”服务器。

在“ 金丝雀”服务器上升级新版本应用程序。

自动化测试应用程序。

恢复“ 金丝雀”服务器连接到负载均衡（连接性和完整性检查）。

如果用户实时使用情况下的“ 金丝雀”测试成功，则升级其余服务器。（否则回滚）

金丝雀发布，可以结合滚动部署一起使用，例如上图的A3组，如果服务实例或者机器非常多，可以滚动的部署。

灰度发布（Gray Release）

灰度发布是在金丝雀发布基础上进行延伸，不是将发布分成两批，而是将发布分成不同的阶段/批次发布，每个阶段/批次的用户数量逐级增加。如果新版本在当前阶段没有发现问题，就再扩展用户数量进入下一个阶段，直至扩展到全部用户。

如下图所示，《持续交付2.0》提到的金丝雀发布与灰度发布示意图。

灰度发布，可以结合滚动部署一起使用，通过分批部署，部署即发布，来让部分客群可见。

灰度发布，需要结合特性开关等技术，做更复杂灵活的灰度。

A/B测试（A/B Testing）

简单来说，A/B测试是针对用户的需要，提供两个版本的功能，一部分用户能看到版本A，一部分用户能看到版本B，经过对比实验，得出哪个版本更优的测试过程。

A/B测试基于科学方法，对假设进行对照实验，即其他条件相同，只有一个条件不同的实验。

实验目标：为同一个目标（例如优化转化率或改进某些业务指标等）

实验变量：针对单一变量（例如页面的按钮颜色发生了变化）

实验方案：制定两个版本（即A和B两个变体），在总体用户中取出一小部分，将这部分用户完全随机地分在两个组中，使两组用户在统计角度无差别，将两个版本分别展示给不同的用户组

试验分析：有可能版本A是老版本称之为对照组，B是新版本称之为实验组，收集对照组和实验组组对应的用户体验数据和业务数据，最后分析、评估出最好版本，正式采用。

虽然 A/B 测试名字中只包含 A、B ，但并不是说它只能用于比较两个版本的好坏，事实上，完全可以设计两个以上版本进行测试，比如A，Ｂ，Ｃ测试，即A/B/n测试，“A/B 测试”这个名字只是一个习惯的叫法。

A/B测试对单一变量，例如一个页面、功能等测试两个不同版本，而多变量测试会使用更多变量进行测试，可以提供更多的洞察。

A/B测试的场景包括：页面交互变化对比、文案变化对比、页面布局变化对比、产品功能对比、算法调优对比等等。

A/B 测试目的在于通过科学的实验设计、采样样本代表性、流量分割与小流量测试等方式来获得具有代表性的实验结论，并确信该结论在推广到全部流量可信。所以说，A/B测试和金丝雀发布、灰度发布的讨论维度是不一样的，A/B测试是发布之后，倾向于产品功能的受欢迎程度、可用性以及可见性等，而金丝雀发布、灰度发布等目的是安全稳定地发布新版本应用，并在必要时回滚。

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

特性开关（Feature Toggle/Feature Flag）

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

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

特性开关的原理如下图所示：

特性开关本质上就是一个“if … else …”的代码。而开关本身的配置可以是一个配置文件，或者是一个集中化的开关管理中心。

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

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

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

ToC的例子，所有的用户使用同样的单体软件部署到PC上之后，根据用户的购买的License，打开和关闭某些特性

ToB的例子，电信行业，例如华为和中兴卖给中国移动的设备，在部署到客户网路之中后，不用升级软件，只要购买了新的License，相应的特性就会被打开

同时这种方式也可以支持持续集成的主干开发，所有开发人员在一个主干上开发代码，针对比较大的、周期长的、风险大的功能使用特性开关，可以保证主干出版本的时候，带上了部分未完成的代码，这些半成品代码通过开关关闭掉，发布给用户之后，半成品功能对用户不可见，也不会破坏已经完成的代码功能。

如下图所示，特性开关对选定的用户群有效。

如下图所示，特性开关可以增量的进行灰度发布，逐步扩大开关匹配的人员百分比。

与特性开关所配对的不同范围的客群，需要结合其他手段识别和分流，例如不同的设备 id、user_id、pin、用户画像、地域、渠道（PC，微信，IOS，安卓等）、机房、网关、IP网段、Cookie、白名单等，可以支持金丝雀发布、灰度发布、A/B测试等。

还有一种情况是，在用户侧，用户可以自由选择使用开关，打开或关闭某个特性。

特性分支（Feature Branch）

为了对特性进行物理隔离，以及支持不同的发布方式，在版本控制系统中例如Git上，针对每个特性创建一个特性分支。无需采用特性开关，根据发布需要，对要发布的特性进行代码的合并和集成，这样可以创建多个集成不同特性的新版本，结合其他部署策略，这些新版本部署之后，根据需要使用不同分支版本进行灰度或者A/B测试等。

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

抽象分支（Branch By Abstraction）

不采用特性分支方式来隔离大规模软件重构的代码，而是在不创建真实分支的情况下，通过设计手段，将大的架构/重构分解成多个架构切片，迭代增量的实现小的代码变更，逐步完成整体的架构。

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

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

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

在你想改变的那部分代码之上创建一个抽象层。

对其余部分的代码进行重构，使其使用这个抽象层使用其之下的代码提供的功能。

在新的实现代码里实现一些新的类，让其上的抽象层根据需要，选择性的导向旧代码或新增的类上。

剔除原有的旧实现。

清理，并重复前两步，如果需要，可同时交付你的软件。

一旦旧实现完全被代替后，如果你愿意，可以移除那个抽象层。

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

具有代表性的Facebook案例

Facebook网站持续部署

Facebook网站2003-2017年的分支策略，采用主干开发（Trunk/Master），分支发布（Production/Release）。如下图所示意，每天2-3个小版本，每周一个大版本。

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

Facebook网站采用一周的迭代周期，在一周之内频繁发布上线给用户。同时Facebook使用了一个内部特性开关（Feature Toggles/Flags）系统Gatekeeper，可以在服务端打开和关闭某个特性。

新版本是从主干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。

在2016年4月，如上图所示的主干开发，分支发布，达到了瓶颈，因为开发人员每天将就绪的代码提交到主干上可以达到1000+次提交，然后从主干上将代码合并到发布分支上，最多的时候一周需要合并一万次。一周的代码手工合并以及各种协调所需的人力耗费巨大，不可持续。

Facebook从2016年4月到2017年四月开始建设主干开发主干发布的持续推送系统（push from master to production）。如上图所示，每天都有成百上千的小的增量的代码变化，几小时后被发布到100%的生产环境。首先最新变化的代码经过自动化测试之后，提交到Master分支，再被推送给Facebook员工（吃自己的狗粮）。如果进行了回归测试发现了问题就会产生推送阻塞（Push-blocking）告警。如果一切顺利就推送给2%的生产环境用户，直到最后推送给100%的生产环境用户。经过统计，每个小版本平均包括92行新增或者修改的代码，每个开发人员每周推送到生产环境3.5个软件更新，总体结果是Facebook网站每天可以达到上千次的部署。每个开发人员对自己提交的代码负责，没有单独的测试团队，仅仅要求提交代码之前做代码的同行评审。

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

Facebook移动端App持续部署

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

如上图所示，Facebook安卓APP的分支策略，采用了2017年4月以前的网站的主干开发，分支发布的模式，开发到部署过程如下：

预推送测试（Pre-Push Testing）：每个开发人员从主干Master上拉一个本地分支，在本地分支开发，在本地经过单元测试，静态代码扫描，以及部分集成测试之后，进行代码评审

推送中（On push）：代码评审之后就启动合并到Master的推送请求，代码在真正的push到master分支之前，触发了自动化测试，包括：单元测试，黄金流程（被大量使用的功能以及核心流程）的冒烟测试，以及简单的新功能测试确保新构建没有问题（build test）；所有的自动化测试通过后，本地分支代码就被允许自动合并到master分支，如果出现合并冲突，相关的开发人员就解决冲突

在主干和发布分支上持续测试：每隔几个小时，并行的在主干和发布分支上，持续的运行所有的自动化测试，包括：全面的的build test, 回归测试以及性能测试等

一周的开发中，在主干上每天进行1次构建，产生1个α版本，通过Google Play Store发布给几万个外部用户。在第一周周日下午6点创建发布分支，在第二周的前三天对前一周的开发进行稳定化和收尾，采用cherry pick将缺陷修复从主干上合并到发布分支上，同时每天进行3次构建，最终推出一个β版本，并通过Google Play Store发布给3百万外部用户，第一天覆盖20%用户，第二天覆盖50%用户，第三天覆盖100%用户；然后周四周五是Soak“渗透”阶段 ，周四冻结代码，处理问题，提交市场上线。

Facebook的苹果App采用了和安卓App同样的模式，但是时间被拉长了，是一个2+2的模式，2周开发测试，2周的灰度和提交市场。

笔者经过研究Facebook IOS App 2019年的发版记录，如下图所示，基本上可以得出结论，现在IOS App也是一周一个版本，可以推测出IOS App是1周开发，1周灰度。至少从2019年来看，Facebook苹果和安卓的迭代和持续部署的模式都是一致的，都是1+1模式，1周开发测试，1周的灰度和提交市场。

Facebook使用了黑启动的部署策略，通过特性开关实现黑启动，Facebook的黑启动工具为Gatekeeper，如下图所示：

总结

主干开发TBD（Trunk-Based Development）先锋保罗·哈曼特（Paul Hammant）将分支模型映射到发布频率，如下图所示，并且可以看到，特性开关作为一个必不可少的技术，可以很好的支持更频繁的发布。

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

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