关于部署:万字长文一文看懂持续部署按需发布DevOps部署和发布方法大全-IDCF

一、前言

麻利 DevOps 的一个次要目标是要达成继续的最短的周期进行价值交付，这就离不开疾速的部署和公布。

那么问题来了，部署和公布到底是一个概念还是不同的概念？有哪些常见的部署和公布策略?

本文将会分析不同的概念，介绍不同的部署和公布的策略，在文章的最初，会对所有的策略和技术进行总结。

二、什么是部署与公布

在谈继续部署之前，让咱们廓清一下什么是部署，什么是公布。

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

1）公布

• 研发团队公布一个版本，代表着开发实现并且测试实现是一个能够销售的软件，也代表着这个软件的上市。
• 将软件售卖之前，须要把版本复制到软盘、U 盘或者刻录到光盘上，通常叫做公布到工厂（RTM，Release to manufacturing）。
• 软件正式上市售卖代表着软件曾经 Gone Live，上线。

2）部署

• 如果是面向集体的桌面系统软件，那么由集体担当部署的人员，将软件（来源于软盘、光盘、U 盘）进行装置，装置后自行进行配置。
• 如果是面向企业的软件，那么由甲方的 IT 工程师负责装置和配置，或者是由乙方的服务人员负责装置和配置。
• 还有另外一种状况，在甲方真正装置和配置软件之前，有一个用户验收测试（UAT，User Acceptance Test），在甲方的机房，先装置和配置一套，而后由甲方进行测试，如果测试通过，代表验收胜利，就能够正式的去装置和配置。

在互联网、挪动互联网和 SaaS 时代，通常是，部署就代表着公布。

1）公布

• 用户能看见软件或者间接应用软件，概念上和互联网之前的年代是一样的，目标都是上市 通常是将一个版本公布到网上（RTW，Release to the web）或者叫做网上公布(Web release）。
• 在中国互联网行业，通常称之为上线（Release to production）。

2）部署

• 部署变成了将软件包公布到生产环境的一个动作，或者是一个步骤。
• 即通过部署的动作，达成了公布的后果。

麻利 DevOps 时代，部署和公布解耦，变成了继续部署，按业务须要公布。

1）继续部署

• 继续的，自动化的，将软件包公布到生产环境。
• SaaS 和网站类型的，就是间接部署到网站上。
• 挪动利用 App 类型的会通过各种 APP 散发渠道，发到利用市场，例如苹果的 AppStore，安卓的各种利用市场。

2）按需公布

• 依据业务须要，公布性能。
• 公布，代表用户看见软件或者能够间接应用软件的性能，即 release the functionality to end users。

3）补充阐明

• 对于一些 ToB 的企业级软件，例如电信行业，通常是软件 + 硬件整体销售给运营商（例如中国移动），依然会波及到发送硬件（例如替换件、路由器）到运营商，而后设施商（例如华为）的服务人员在客户现场进行机房、硬件等的装置和配置，之后才会割接上线。
• 而 2011 年建设的凋谢网络基金会开始在业界大力提倡软件定义网络（SDN，Software-defined networking）和 OpenFlow 协定，在肯定水平上解耦了软件和硬件，那么 DevOps 的理念就有可能被达成，例如在华为生产的软件通过网络间接在中国移动的网络上降级软件。

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

让咱们正式的定义一下 部署和公布，《DevOps 实际指南》的定义如下：

1）部署

• 是指在特定的环境中装置指定版本的软件（例如，将代码部署到集成测试环境中，或者部署到生产环境中）。
• 具体的说，部署可能与某个个性的公布无关。
• 如果部署与某个个性公布无关，部署后即时失效，即代表着公布，部署 = 公布。

2）公布

• 是指把一个个性（或者一组个性）提供给所有客户或者一部分客户（例如，向 5% 的客户群凋谢个性）。
• 代码和环境架构要可能满足这种要求：个性公布不须要变更利用的代码。

部署和公布是解耦开的，也就是：让部署能够独立于公布独自进行；而个性部署后，业务能够灵便决定什么时候公布，向哪些指标客群公布。如果部署周期过程，就会限度向市场频繁地公布新个性的能力。如果能做到按需部署，或者继续部署，那么什么时候公布新个性，就成了业务和市场决策，而不再是技术决策，所以部署是技术领域，而公布时业务领域。

三、什么是继续部署

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

按需公布（Release on Demand）是团队和企业的要害能力。按需公布使得业务具备继续的在最短的前置工夫（Lead Time）内，以高频率的形式，让客户应用新性能，从而通过高价值计划响应市场机会。

为了反对业务具备按需公布的能力，个性在业务须要它们之前，必须在生产环境失去验证和期待公布。所以须要将部署过程优化并从公布过程中分离出来，这样将代码变更部署到生产环境，并不会影响整个零碎的行为。继续部署的能力使团队能够进行更小的增量的代码变更，并继续地部署到生产环境，然而并不公布，直到业务须要的工夫才正式公布给客户。

而对于继续部署的“继续”，每个公司的水平是不一样的，例如，亚马逊 2011 年 5 月的部署数据，在工作日均匀每 11.6 秒部署一次，一个小时部署最多的一次是部署了 1079 次部署，一次部署均匀部署到一万台云主机，最多的时候一次部署是部署到三万台云主机。

如下图所示，《凤凰我的项目》提到国外的一些大厂 2012 年的部署频率和每次部署破费的工夫（Deploy Lead Time）。

笔者于 2020 年在苹果的 App Store 查看了国内各大支流 IOS APP 的版本公布状况，大多数的 APP 是在 2 周以内公布一次。

拿京东来说，在 APP 市场，大多数状况下，京东商城 APP 是两周一个版本，京东金融 APP 也是两周一个版本。对于京东的服务端的公布，基本上是每周有两次上线窗口进行小批量的上线，当然对于紧急的线上问题的修复依据状况随时上线。

如下图所示，《公布！设计与部署稳固的分布式系统 第 2 版》提到：部署间隔时间有更长的提早，将会导致每次的部署蕴含更多的代码变更，后果就是呈现更多缺点和宕机的危险，因而会减少更多的评审环节，那么又大大增加了部署之间的间隔时间。这是一个越来越差的加强回路。

正如《公布》这本书所说的“如果每次部署都很苦楚，那么就频繁屡次做”，所以高频的继续部署能够颠覆这个恶性循环，并且从以上国外大厂和国内大厂公布的频率来看，充分说明继续的部署是业务按需公布的必要条件。

四、继续部署实际

4.1 蓝绿部署（Blue-Green Deployments）

蓝绿部署是指有两个完全相同的、相互独立的生产环境，一个叫做“蓝环境”，一个叫做”绿环境“。

绿环境是用户正在应用的生产环境。当要部署一个新版本的时候，先把这个新版本部署到蓝环境中，而后在蓝环境中运行冒烟测试，来查看是否失常工作，当所有准备就绪当前，向新版本迁徙就非常简单了，只有批改一下路由配置，将用户流量从绿环境导向蓝环境就能够，这个时候蓝环境就变成了生产环境，这种切换通常在一秒钟之内就能搞定。如果出了问题，把路由器切回到绿环境上即可，而后在蓝环境中调试，找到问题的起因。

所以蓝绿部署，是在部署之后，仅仅一次切换，立即就向所有用户推出新版本，新性能对所有用户立即失效可见。

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

蓝绿部署中，如果是放弃两份一样的数据库，须要解决的问题是数据库的问题，一个是如何疾速复制数据库，一个是波及数据库的事务时如何解决数据的一致性问题。

在电信行业中，通常须要保障 99.999% 的工夫是服务可用的，所以通常会投入冗余的设计和实现，例如一个设施的双 CPU、双存储、多个板卡等，双机主备等，网络建设的时候进行冗余设施的设计，通信链路有爱护协定时刻进行心跳式的检测，如果某个链路数据不通，就主动切换到另外的链路等等。

例如交换机或路由器有两个 CPU，一个是主，一个是备，主备之间内存应用内存数据库进行同步，备机如果内存数据库被更新了，就立即同步到备机的长久化存储中。这样能够保障设施如果有问题的时候主备之间进行切换，同时能够被用来零停机部署、不中断业务降级（ISSU，In-Service Software Upgrade）在 standby 备机 CPU 中降级到新版本，再将其切换成主服务 CPU，而原来的主活 CPU 变成了备机待机状态，再将其降级，这样既不影响实时业务，又降级了新版本。

那么在非电信行业，能够思考两套环境应用同一个数据库，升高技术复杂度和节约老本。

4.2 滚动部署（Rolling Deployment）

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

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

4.3 黑启动（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 用户推出新性能。
• 能够容许用户本人抉择退出或者退出黑启动性能。

黑启动按用户百分比分批公布，就是在国内互联网罕用的灰度公布。

黑启动仅仅针对局部机器、服务实例或者客群公布，就是金丝雀公布。

五、按需公布实际

5.1 金丝雀公布（Canary release）

软件行业的金丝雀公布这个术语来自 20 世纪初期英国煤矿工人在下井采矿之前会把笼养的金丝雀携带到矿井中，如果矿井中一氧化碳等有毒气体的浓度过高，在影响矿工之前，金丝雀相比人类体现的更加敏感疾速，金丝雀中毒之后，煤矿工人就晓得该立即撤退。金丝雀公布，在将整个软件的新版本公布给所有用户之前，通过将新版本公布给局部用户，用实在的客户流量来测试，以保障软件不会呈现重大问题，升高公布危险。

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

• 第一批金丝雀用户：先将新版本部署局部机器或者服务实例，并对局部选定用户凋谢。
• 第二批所有用户：之后再将所有其余机器或者服务实例进行部署，并对所有用户凋谢。

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

• A1 组：仅向外部员工提供服务的生产环境服务器。
• A2 组：仅向一小部分客户提供服务的生产环境服务器，在软件达到某些验收规范后部署（自动化部署或手动部署均可）。
• A3 组：其余的生产环境服务器，软件在 A2 组中达到某些验收规范后再部署。

金丝雀公布通常包含以下步骤：

• 暂存用于部署的工件，包含：构建工件，测试脚本，配置文件和部署清单。
• 从负载平衡（Load Balancer）中删除“金丝雀”服务器。
• 在“金丝雀”服务器上降级新版本应用程序。
• 自动化测试应用程序。
• 复原“金丝雀”服务器连贯到负载平衡（连接性和完整性检查）。
• 如果用户实时应用状况下的“金丝雀”测试胜利，则降级其余服务器。（否则回滚）

金丝雀公布，能够联合滚动部署一起应用，例如上图的 A3 组，如果服务实例或者机器十分多，能够滚动的部署。

5.2 灰度公布（Gray Release）

灰度公布是在金丝雀公布根底上进行延长，不是将公布分成两批，而是将公布分成不同的阶段 / 批次公布，每个阶段 / 批次的用户数量逐级减少。如果新版本在以后阶段没有发现问题，就再扩大用户数量进入下一个阶段，直至扩大到全副用户。

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

• 灰度公布，能够联合滚动部署一起应用，通过分批部署，部署即公布，来让局部客群可见。
• 灰度公布，须要联合个性开关等技术，做更简单灵便的灰度。

5.3 A/ B 测试（A/B Testing）

简略来说，A/ B 测试是针对用户的须要，提供两个版本的性能，一部分用户能看到版本 A，一部分用户能看到版本 B，通过比照试验，得出哪个版本更优的测试过程。

A/ B 测试基于迷信办法，对假如进行对照试验，即其余条件雷同，只有一个条件不同的试验。

• 试验指标：为同一个指标（例如优化转化率或改良某些业务指标等）。
• 试验变量：针对繁多变量（例如页面的按钮色彩产生了变动）。
• 试验计划：制订两个版本（即 A 和 B 两个变体），在总体用户中取出一小部分，将这部分用户齐全随机地分在两个组中，使两组用户在统计角度无差别，将两个版本别离展现给不同的用户组。
• 试验剖析：有可能版本 A 是老版本称之为对照组，B 是新版本称之为实验组，收集对照组和试验组组对应的用户体验数据和业务数据，最初剖析、评估出最好版本，正式采纳。

尽管 A/B 测试名字中只蕴含 A、B，但并不是说它只能用于比拟两个版本的好坏，事实上，齐全能够设计两个以上版本进行测试，比方 A，B，C测试，即 A /B/ n 测试，“A/B 测试”这个名字只是一个习惯的叫法。

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

A/ B 测试的场景包含：页面交互变动比照、文案变动比照、页面布局变动比照、产品性能比照、算法调优比照等等。

A/B 测试目标在于通过迷信的实验设计、采样样本代表性、流量宰割与小流量测试等形式来取得具备代表性的试验论断，并确信该论断在推广到全副流量可信。所以说，A/ B 测试和金丝雀公布、灰度公布的探讨维度是不一样的，A/ B 测试是公布之后，偏向于产品性能的受欢迎水平、可用性以及可见性等，而金丝雀公布、灰度公布等目标是平安稳固地公布新版本利用，并在必要时回滚。

六、反对不同公布形式的技术实现

6.1 个性开关（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 测试等。

还有一种状况是，在用户侧，用户能够自由选择应用开关，关上或敞开某个个性。

6.2 个性分支（Feature Branch）

为了对个性进行物理隔离，以及反对不同的公布形式，在版本控制系统中例如 Git 上，针对每个个性创立一个个性分支。无需采纳个性开关，依据公布须要，对要公布的个性进行代码的合并和集成，这样能够创立多个集成不同个性的新版本，联合其余部署策略，这些新版本部署之后，依据须要应用不同分支版本进行灰度或者 A / B 测试等。

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

6.3 形象分支（Branch By Abstraction）

不采纳个性分支形式来隔离大规模软件重构的代码，而是在不创立实在分支的状况下，通过设计伎俩，将大的架构 / 重构分解成多个架构切片，迭代增量的实现小的代码变更，逐渐实现整体的架构。

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

简略来说，应用设计伎俩，例如设计模式、面向方面编程 AOP（Aspect Object Programming）等，容许在代码层面存在两个版本的代码。

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

• 在你想扭转的那局部代码之上创立一个形象层。
• 对其余部分的代码进行重构，使其应用这个形象层应用其之下的代码提供的性能。
• 在新的实现代码里实现一些新的类，让其上的形象层依据须要，选择性的导向旧代码或新增的类上。
• 剔除原有的旧实现。
• 清理，并反复前两步，如果须要，可同时交付你的软件。
• 一旦旧实现齐全被代替后，如果你违心，能够移除那个形象层。

老马（Martin Fowler）指出，这些步骤也能够变动一下。“在最简略的状况下，你能够创立一个形象层，而后重构，让所有的代码都调用它，而后再新写一个实现，最初切换一下就行了。然而，还能够将它离开做。比方，不创立整个形象层，而只是创立将要批改的性能的一个子集，迁徙这部分代码，而后再做下一部分（此时新旧代码共存）。

七、Facebook 的案例

7.1 Facebook 网站继续部署

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

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

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

同时 Facebook 应用了一个外部个性开关（Feature Toggles/Flags）零碎 Gatekeeper，能够在服务端关上和敞开某个个性。

认真看一下分支策略，如下图所示，每周周一完结时公布一次大版本给用户（图中最左侧周一绿色五角星，版本 293.7），在周一公布最新版本之后，周二将这个公布分支从 production 改名字为 defunct 分支，意味着是一个不再起作用的分支。

新版本是从骨干 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 的页面与聊天服务器建设连贯，查问状态信息，并模仿音讯发送，然而应用的是老用户页面，并没有批改界页面显示服务器端返回的音讯，这样就能够在全面上线前进行压力测试，模仿新性能带来的影响。

7.2 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 次采纳的是黑启动，蓝绿部署和金丝雀公布，如下图所下，图中将黑启动翻译成了灰度公布。

以上各种部署、公布以及撑持技术。

参考

1. 软件公布生命周期
2. 继续部署
3. 按需公布
4. 亚马逊均匀每 11.6 秒部署一次
5. 《凤凰我的项目：一个 IT 运维的传奇故事》
6. 《继续交付：公布牢靠软件的零碎办法》
7. 《继续交付 2.0：业务引领的 DevOps 精要》
8. 《公布！设计与部署稳固的分布式系统 第 2 版》
9. Facebook 大规模疾速公布
10. Facebook 如何实现大规模疾速公布
11. Facebook 的挪动端软件的继续部署
12. Facebook 挪动公布流程
13. Facebook 的 DevOps 案例钻研与相干工具
14. 咱们常常聊的金丝雀公布、滚动公布、蓝绿公布到底有什么差异？
15. 利用部署和测试策略
16. 利用部署的六个策略
17. 什么是蓝绿部署
18. 为什么当先公司应用黑启动
19. Facebook Chat
20. Facebok 黑启动
21. 黑启动
22. Kent Beck 响应式设计
23. 动物哨兵
24. 国内金丝雀
25. 金丝雀公布
26. 金丝雀测试
27. 蓝绿部署，A/ B 测试和金丝雀公布
28. A/ B 测试
29. A/ B 测试知识点总结
30. A/ B 测试实际全总结
31. A/ B 测试
32. 多变量测试与 A / B 测试
33. 个性开关
34. [部署新版本：个性开关还是猪增量公布？[(https://opensource.com/articl…
35. 个性开关驱动开发
36. 摸索如何在生产环境逐渐地为局部或者全副用户启用个性
37. 个性开关应用场景
38. 利用形象分支做增量式大规模软件革新
39. 老马的形象分支
40. Facebook 骨干开发

作者：IDCF 社区分享嘉宾 赵卫 David
首发：精益麻利