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

大纲

• 蓝绿部署
• 滚动部署
• 黑启动

• 金丝雀发布
• 灰度发布
• A/B测试

• 特性开关
• 特性分支
• 抽象分支

一、前言

敏捷DevOps的一个主要目的是要达成持续的最短的周期进行价值交付，这就离不开快速的部署和发布。那么问题来了，部署和发布到底是一个概念还是不同的概念？有哪些常见的部署和发布策略?

二、什么是部署与发布

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

1）发布

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

2）部署

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

1）发布

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

2）部署

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

1）持续部署

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

2）按需发布

• 根据业务需要，发布功能。
• 发布，代表用户看见软件或者可以直接使用软件的功能，即release the functionality to end users。

3）补充说明

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

1）部署

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

2）发布

• 是指把一个特性（或者一组特性）提供给所有客户或者一部分客户（例如，向5%的客户群开放特性）。
• 代码和环境架构要能够满足这种要求：特性发布不需要变更应用的代码。

三、什么是持续部署

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

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

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

四、持续部署实践

4.1 蓝绿部署（Blue-Green Deployments）

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

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

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

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

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

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

4.2 滚动部署（Rolling Deployment）

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

4.3 黑启动（Dark Launching）

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

• 企业并没有广而告之声明有新版本发布，用户不知道软件已经升级，并且只有发布给选定的小部分用户，他们才能感知到新功能。
• 用户不知道被选定在测试新功能，例如用户界面没有变化，仅仅是后端算法逻辑等发生变化。
• 黑启动的另外一种做法，就是选定的部分用户实际上是公司内部员工，这样内部员工可以先吃自己的狗粮，对新功能进行测试，而真实用户并未真正使用新功能。

场景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）

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

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

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

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

5.2 灰度发布（Gray Release）

• 灰度发布，可以结合滚动部署一起使用，通过分批部署，部署即发布，来让部分客群可见。
• 灰度发布，需要结合特性开关等技术，做更复杂灵活的灰度。

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

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