文：华为云DevCloud 姚冬
前言
写了一篇《持续交付，持续部署，傻傻分不清楚》 ，引起不少讨论，也是预料之中，毕竟连Jez Humble对持续交付和持续部署的看法和定义也发生了改变，我们纠结一下太正常不过。
不能说融会贯通了，只是想通了一件事情而已，归结为一句话，就是那篇文章的主旨：将技术行为与业务决策解耦。
说来也巧，持续交付(FU)，持续部署(SHU)，持续发布(BU) ，尾音都一样，傻傻分不清楚貌似也理所应当。U can do IT，IT这事儿啊，还得靠U氏三兄弟来搞定。
以终为始，要想将持续交付、持续部署与持续发布讲清楚，就必须了解它们最终的目的，所有这些实践都是围绕着这一目的展开，并且相互关联的。
个人认为，持续交付也好，DevOps也罢，终极目标是快速的交付价值。
正如Jez Humble对持续交付的定义：”The ability to get changes—features, configuration changes, bug fixes, experiments—into production or into the hands of users safely and quickly in a sustainable way.“
在交付价值前面，除了快速以外，还需要有其他定语，稳定可持续的，安全高质量的。
前面说了，上一篇的核心在于一句话，将技术行为与业务决策解耦。
本篇的核心也是一句话：Develop on Cadence, Release on Demand。这前后两句话其实说的是同一件事儿。
按节奏开发是技术域的事儿，按需发布是业务域的。我们这篇就分别从这两个领域来聊聊持续交付流水线。
技术域
我们先来看技术域。
“客户并不一定需要每一个green build，PM/发布经理按业务需求可选择任意一个，在任何时候自动化交付给客户；在部署、交付、发布的上下文里，dev和ops的最高境界是无为，赋能PO那帮人做业务决策，别烦我” ——Martin Liu
对Martin这句话很是认同，从业务上，并非每一个功能都需要发布给每一位用户，而是根据不同的业务上下文，来决定哪些功能发布出来，针对哪些用户进行开放。发布决策，由业务来做。而技术需要的，是提供高效的交付能力，并保持随时可发布的版本状态。
技术层面的核心，在于保障价值的交付能够顺畅、频繁且快速的通过整个价值交付流水线 。
-
SAFe的持续交付流水线
最近刚考了SAFe的SPC认证，对SAFe的持续交付流水线这张图的划分很认可，事实上，Develop on Cadence, Release on Demand，也是来自于SAFe的内容。中间的持续集成与持续交付，正是关系部署前置时间的部分，前端的持续探索，属于产品、设计与开发内容。而这三部分，组成了技术域的发布火车。后面何时发布，如何发布，则是按业务的需求决定。
https://www.scaledagileframework.com/continuous-delivery-pipeline/
-
聚焦于部署前置时间
“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的终极目标。
流水线确保代码和基础设施始终处于可部署状态，所有提交到主干的代码都可以安全的部署到生产环境。
所有在流水线上面挂载的任务，理论上都应该服务于这一目的，所有不对这一目的提供价值的任务，理论上都不应该存在于流水线之上，都应该被消灭。
-
解决开发与运维之间“根本的、长期的冲突”
通过流水线，让部署成为日常的、低风险的工作，来解决开发与运维之间“根本的、长期的冲突”：开发负责对市场变化做出响应，以最快的速度将新功能或者变更上线。而IT运维则需要为客户提供稳定、可靠和安全的IT服务。同时公司对不同部门的考核和激励不同，更是让开发部门与运维部门的目标和动因之间存在巨大的冲突。
通过小批量的、独立的快速交付周期，让各个功能/服务团队之间彼此解耦，快速获取反馈，快速验证问题，DevOps并不能解决问题，它只是让你快速失败，If you fail，fail fast。（所以在DevOps里，失败原本就是学习的一种方式）
通过频繁、快速的生产环境部署，保证稳定可重复的自动化部署。
通过Feature Toggle，Black 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次部署”
https://codeascraft.com/2010/05/20/quantum-of-deployment/
从上述的例子，可以看出技术对业务极大的赋能。如果我们能做到每天几十次的部署到生产环境，那么每次的变更又能有多大，一个月一次的版本，发布的时候的确需要严格审核，一天几十次呢？不难想象，此时的业务决策该有多简单，甚至可能不需要决策过程，这就是技术能力赋能给业务决策的体现，也是精益中强调小批量的原因。
-
低风险发布
按需发布，让特性发布成为业务和市场决策，而不是技术决策。
通过金丝雀发布，可以小批量的选择环境进行试验，待金丝雀验证通过再发全量。而滚动发布，使得这一流量切换过程更加平缓，一旦出现问题，可以自动回滚。
通过特性开关，可以保证应用上线后，功能开关先不打开，然后由业务人员根据场景进行决策，通过开关中心打开新功能，经过流量验证新功能。特性开关将部署与特性发布解耦，结合基于环境和用户群的蓝绿或是滚动发布，可以实现对不同的用户群进行不同功能的投放，实现A/B测试，进一步增强了假设驱动开发的能力，可以基于不同的假设路径，进行快速灵活的发布验证。
（有关金丝雀发布、蓝绿部署、灰度发布等内容，下面这篇写的很详细：
http://www.10tiao.com/html/773/201803/2247487627/1.html）
小结
最后，用著名的Deployment g-forces图，来结束整篇内容。
http://apprize.info/usability/lean/8.html
量变产生质变，每100天一次发布，与每天100次发布，无论是从技术上，实践上，还是对业务的帮助上，都不可同日而语。更重要的，是mindset的转变，做具体的一个工程实践不难，但要把它做好做到极致很难，这里么的困难更多不是技术本身，而是思维方式的转变。
持续交付流水线，将整个价值交付过程贯穿起来，即使只是后半段的DevOps实践，也同样的牵一发动全身，发布频度这一个关键指标，就需要分支策略，测试自动化，部署自动化，架构解耦，发布策略，数据库等多方面的支持。
关于作者
姚冬 资深DevOps与精益/敏捷专家，软件工程专家；中国DevOpsDays社区核心组织者之一；Exin DevOps Professional 认证讲师；SAFe SPC规模化敏捷咨询师；认证Scrum Master, SAFe Agilist；曾任IBM DevOps产品线大中华区技术总监，金融行业Technical Leader；现任华为资深解决方案架构师。
华为云DevCloud作为一站式云端DevOps平台，集成华为近30年研发实践和前沿理念，面向开发者提供研发工具服务，让软件开发简单高效。现支持5人以下额度范围内，可以免费使用，并且可以预约免费的产品演示和技术交流，详情查看华为云官网