以终为始,再谈持续交付流水线

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

0
364

前言

上周写了一篇”持续交付,持续部署,傻傻分不清楚“ ,引起不少讨论,也是预料之中,毕竟连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 quicklyin 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的内容。中间的持续集成与持续交付,正是关系部署前置时间的部分,前端的持续探索,属于产品、设计与开发内容。而这三部分,组成了技术域的发布火车。后面何时发布,如何发布,则是按业务的需求决定。

  • 聚焦于部署前置时间

“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次部署”

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

  • 低风险发布

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

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

通过特性开关,可以保证应用上线后,功能开关先不打开,然后由业务人员根据场景进行决策,通过开关中心打开新功能,经过流量验证新功能。特性开关将部署与特性发布解耦,结合基于环境和用户群的蓝绿或是滚动发布,可以实现对不同的用户群进行不同功能的投放,实现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;现任华为资深解决方案架构师。

以下分别是作者姚冬的个人公众号AgileRunner的二维码和DevOps公众号的二维码,欢迎关注。


- leansoftx.com -