文档首页 > > 理论实践> 持续部署与发布> 持续交付流水线

持续交付流水线

分享
更新时间: 2020/05/26 GMT+08:00

以终为始,要想将持续交付、持续部署与持续发布讲清楚,就必须了解它们最终的目的,所有这些实践都是围绕着这一目的展开,并且相互关联的。

所以,持续交付也好,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。

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

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

  • 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的最终目标。

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

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

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

    在流水线方面,DevCloud提供可完全自定义的自动化部署流水线,关联版本库、编译构建、部署等多环节的功能,提交代码自动触发流水线,帮助团队轻松实现持续交付。

      

    任务配置中支持挂载子流水线,流水线分层分级管控。

      

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

    通过流水线,让部署成为日常的、低风险的工作,来解决开发与运维之间“根本的、长期的冲突”:开发负责对市场变化做出响应,以最快的速度将新功能或者变更上线,而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实践,也同样的牵一发动全身,发布频度这一个关键指标,就需要分支策略、测试自动化、部署自动化、架构解耦、发布策略、数据库等多方面的支持。

  

分享:

    相关文档

    相关产品

文档是否有解决您的问题?

提交成功!

非常感谢您的反馈,我们会继续努力做到更好!

反馈提交失败,请稍后再试!

*必选

请至少选择或填写一项反馈信息

字符长度不能超过200

提交反馈 取消

如您有其它疑问,您也可以通过华为云社区问答频道来与我们联系探讨

智能客服提问云社区提问