持续交付流水线

技术域

“客户并不一定需要每一个green build，PM/发布经理按业务需求可选择任意一个，在任何时候自动化交付给客户；在部署、交付、发布的上下文里，dev和ops的最高境界是无为，赋能PO那帮人做业务决策，别烦我。”——Martin Liu。第三方非授权

从这句话中我们可以看出，从业务上，并非每一个功能都需要发布给每一位用户，而是根据不同的业务上下文，来决定哪些功能发布出来，针对哪些用户进行开放。发布决策，由业务来做。而技术需要的，是提供高效的交付能力，并保持随时可发布的版本状态。

技术层面的核心，在于保障价值的交付能够顺畅、频繁且快速的通过整个价值交付流水线 。

• SAFe的持续交付流水线

  下面让我们看看SAFe对持续交付流水线的划分，事实上，“Develop on Cadence, Release on Demand”也是来自于SAFe的内容。中间的持续集成与持续交付，正是关系部署前置时间的部分。前端的持续探索，属于产品、设计与开发内容，而这三部分，组成了技术域的发布火车。后面何时发布、如何发布，则是按业务的需求决定。

• 聚焦于部署前置时间

  "How long would it take your organization to deploy a change that involves just one single line of code? Do you do this on a repeatable, reliable basis?" ——Mary Poppendieck

  修改一行代码，上线需要多少时间？这一指标决定了能多持续、多稳定的交付，决定了MTTR，多久服务可以恢复、多快能够上线一个严重的缺陷修复、多快能够发布一个服务并获取价值反馈。这一指标，就是部署的前置时间。

  部署前置时间，开始于工程师在版本控制系统中提交一个变更，截止到变更成功的在生产环境中运行、为客户提供价值，并生成有效的反馈和监控信息为止。

  部署前置时间将整个价值流交付过程分成了两段，前一段的活动，主要是产品、设计和开发，具有高度的不确定性和变化性，需要创造性的工作，且很多工作无法复制。后一段的活动，主要在集成、测试和部署运维，相比起来，相对技术更可控。

  所以部署前置时间的核心，是把可控的部分做到极限，力求可预见性和自动化，将可变性降到最低，来支撑变化的部分。

• 目标是分钟级的部署前置时间

  通过小批量代码交付，在不同环境中通过不同层级的自动化测试与探索性测试，快速进行验证，同时持续将成功验证的变更部署到下一环境，从而在DTAP（开发、测试、验收、生产）不同环境中形成自动化的测试和部署节奏，这也就是部署流水线的概念。为实现部署流水线，需要版本管理、自动化测试、持续集成、自动化部署、环境管理，以及松耦合架构等的协调统一。

• 分层分级的部署流水线

  “高质量的交付”，质量如何界定？功能和非功能的都算上，质量验证的手段也是分层的，验证就是反馈，为了快速获取反馈，这些手段分布在整个流水线的各个阶段。

  部署流水线，是保障质量并缩短部署前置时间的有效支撑。同时，部署流水线，是分层分级的。

  • 从影响范围来看，分为个人级、项目级、版本级、解决方案级的流水线。
  • 执行的频度单位，分别是分钟级、小时级、以天为单位、和以周为单位。
  • 分别对应不同的环境（DTAP）：Development、Testing、Acceptance、Production。

  各个层级，在不同的环境上，执行不同的测试，这也与理想的测试金字塔分层测试相互对应。

  每个层级的目的、和预设的反馈回路、涉及的范围、验证的方法与内容、定位问题区间都有所不同。

  

• 流水线越来越成为开发运维一体化的代名词

  开发与运维之间“不可调和的矛盾”，可以通过流水线来解耦。流水线成为开发和运维人员最常使用的平台，从日常的提交代码自测，到提交到主干的持续集成，到测试和准生产环境的自动化与手工的验证，以及各级环境之间的部署和环境拉平。

  很多人对于自动化都喜欢强调或追求“一键”的概念，然而一键只是方式，不是目的，更不是唯一。事实上，在部署流水线里面，甚至可以消除掉一键那个动作。

  流水线的存在，接管了底层的基础设施，包括计算、存储、网络，无论是On Premise，还是On Cloud；接管了PaaS层，开发人员无需太关注是虚拟机，还是容器，也不必太多了解K8s的配置和编排，以及DTAP不同的环境的配置和差异；甚至接管了上面使用的自动化工具，包括版本库、制品库、持续集成、自动化构建、自动化测试工具、自动化部署工具。

  这些都将成为流水线的一部分，所以流水线越来越不可或缺。不同的语言也好、架构也好、环境也好、容器也好、微服务也好、K8s也好，都可以往流水线上挂，流水线也就成为Dev to Ops事实上的标配和代名词。

  所以流水线的作用，第一，接管和屏蔽底层环境的差异；第二，自动化流程引擎；第三，挂载执行分层分级的流水线任务。

  流水线也是“持续稳定可重复的提供高质量的价值”的重要不可或缺的实践，服务于持续交付，同时也是DevOps的最终目标。

  流水线确保代码和基础设施始终处于可部署状态，所有提交到主干的代码都可以安全的部署到生产环境。

  所有在流水线上面挂载的任务，理论上都应该服务于这一目的，所有不对这一目的提供价值的任务，理论上都不应该存在于流水线之上，都应该被消灭。

  说到这里就不得不说一说能支持自动化部署流水线的工具——CodeArts。

  在流水线方面，CodeArts提供可完全自定义的自动化部署流水线，关联版本库、编译构建、部署等多环节的功能，提交代码自动触发流水线，帮助团队轻松实现持续交付。任务配置中支持挂载子流水线，流水线分层分级管控。

• 解决开发与运维之间“根本的、长期的冲突”

  通过流水线，让部署成为日常的、低风险的工作，来解决开发与运维之间“根本的、长期的冲突”：开发负责对市场变化做出响应，以最快的速度将新功能或者变更上线，而IT运维则需要为客户提供稳定、可靠和安全的IT服务；同时公司对不同部门的考核和激励不同，更是让开发部门与运维部门的目标和动因之间存在巨大的冲突。

  通过小批量的、独立的快速交付周期，让各个功能/服务团队之间彼此解耦，快速获取反馈，快速验证问题，DevOps并不能解决问题，它只是让你快速失败，If you fail，fail fast。（所以在DevOps里，失败原本就是学习的一种方式）

  通过频繁、快速的生产环境部署，保证稳定可重复的自动化部署。

  通过Feature Toggle（功能开关/特性开关）、Dark Launch（灰度上线），让功能早在发布之前，就已经部署到生产环境中，并已经进行了多次小范围验证。为下游工作而优化，从而在业务需要时，可以不依赖于技术，可以自行进行功能的发布。

  因此技术提供给业务的是一个自服务平台，正如将运维能力封装成自服务提供给开发一样。

业务域

我们再来看看业务域。

“持续交付跟这三个（持续集成、持续部署、持续发布）都不同，它是一种组织的能力，这种能力让组织可以持续的交付价值，具体是否采用以上三种技术实践并不一定，而且还必须考虑其他非技术因素，比如团队管理模型，需求结构，项目管理方式，人员能力等等。所以这个持续交付和以上3个不是一个层次的问题，但他们之间确实有互相推动影响的关系。”——徐磊

• 发布策略与发布节奏

  持续集成与持续部署是技术域的事情，持续交付是业务域的。而持续发布，本文认为两者都有，但偏业务层面多一些。按需发布，因此发布还是业务的决策。

  业务需要决定发布策略：

  • 什么时候发布？
  • 发布哪些特性？
  • 发给哪些用户？

  发布节奏不需要与开发节奏保持一致，开发保证环境和功能是随时可用的，业务来决定发布策略。

• 假设驱动开发

  持续交付流水线是Flow，是价值交付的过程，但如何确定交付的就是客户想要的价值？

  所有交付的功能特性都是基于假设：We believe that [building this feature] [for these people] will achieve [this outcome]. We will know we are successful when we see [this signal from the market].

  这就是假设驱动开发的概念。所以单向的不叫持续交付（价值），要实现闭环还需要反馈回路来验证假设。完整的闭环才是价值交付的过程，只有验证了假设，才能说将价值交付给了客户。通过发布，获取反馈，验证假设，进一步完善价值，进而提出新的需求（假设）。

  SAFe的DevOps理论，大多来自于DevOps Handbook。SAFe的模型，是DevOps Handbook三步工作法的另一种解读。

• 多快的频度算是持续

  什么叫持续交付？多快的频度算是持续？一周一个版本还是一天多个版本？

  视不同类型的产品而定，在类生产环境验证之后，有两条路径：一条是传统的软件模式，部署到生产环境，或是商业软件产品的客户交付过程，就意味着发布给最终客户，那么这里需要有一个业务的决策过程，是否可以将特性交付给最终客户。另一条是通过技术解耦的手段，实现即使是部署到了生产环境，也并不意味着发布给了最终客户，例如特性开关和Dark Launch。相较于第一种，这里业务决策过程就相对灵活一些。

  以上两条路径，均需要技术手段来支撑，实现将特性先行发布给一部分用户，以及功能对用户是否可见。

• 持续部署对业务的赋能

  “黑启动已经让每个人的信心达到几乎对它冷漠的程度…...大家根本就不担心…...我不知道，在过去5年里的每一天中，发生过多少次代码部署…...我根本就不在乎，因为生产环境中的变更产生问题的概率极低……”，John Allspaw在Flickr担任运营副总裁时说了上述的话，随后他发表了一天十次部署的著名演讲，随后他来到Etsy，Etsy的自助式部署流水线，使得“任何想要执行部署的人都能直接部署……董事会成员也可以执行部署……甚至连小狗都可以！……在一个普通的工作日里，刚到上午8点整，就有大约15个人和小狗开始排队……”

  2010年时，Etsy的持续部署流水线工具已经将ChatOps集成进去，“提交代码之前，在自己开发环境执行了4500多个单元测试……UT运行仅需要不到1分钟，外部调用打桩……提交到主干后，CI服务器上立即执行7000多个自动化测试用例…...通过并行测试，11分钟执行完毕，MTTR20分钟……到2011年，每天25-50次部署”。

  从上述的例子，可以看出技术对业务极大的赋能。如果我们能做到每天几十次的部署到生产环境，那么每次的变更又能有多大，一个月一次的版本，发布的时候的确需要严格审核，一天几十次呢？不难想象，此时的业务决策该有多简单，甚至可能不需要决策过程，这就是技术能力赋能给业务决策的体现，也是精益中强调小批量的原因。

• 低风险发布

  按需发布，让特性发布成为业务和市场决策，而不是技术决策。

  通过金丝雀发布，可以小批量的选择环境进行试验，待金丝雀验证通过再发全量。而滚动发布，使得这一流量切换过程更加平缓，一旦出现问题，可以自动回滚。

  通过特性开关，可以保证应用上线后，功能开关先不打开，然后由业务人员根据场景进行决策，通过开关中心打开新功能，经过流量验证新功能。特性开关将部署与特性发布解耦，结合基于环境和用户群的蓝绿或是滚动发布，可以实现对不同的用户群进行不同功能的投放，实现A/B测试，进一步增强了假设驱动开发的能力，可以基于不同的假设路径，进行快速灵活的发布验证。

  

小结

量变产生质变，每100天一次发布，与每天100次发布，无论是从技术上、实践上，还是对业务的帮助上，都不可同日而语。更重要的，是mindset的转变，做具体的一个工程实践不难，但要把它做好做到极限很难，这里面的困难更多不是技术本身，而是思维方式的转变。

持续交付流水线，将整个价值交付过程贯穿起来，即使只是后半段的DevOps实践，也同样的牵一发动全身，发布频度这一个关键指标，就需要分支策略、测试自动化、部署自动化、架构解耦、发布策略、数据库等多方面的支持。