持续交付，持续部署，傻傻分不清楚

曾经在内部的培训课上提出这个问题,曾经就类似的问题和同事讨论,也曾经在某“德无哦普斯”群里和相关专家沟通过。但是在准备DevOps Professional课件的过程中,再一次颠覆了原先的理解。

用了一晚上时间,仔细翻看DevOps Handbook相关内容,在网上也查阅了大量资料,试图去解读这两个概念的含义,以及背后的原因。

Jez Humble说,“在过去的5年里,人们对持续交付和持续部署的区别有所误解。“的确,我自己对两者的看法和定义也发生了改变。每个组织都应该根据自己的需求做出选择。我们不应该关注形式,而应该关注结果:部署应该是无风险、按需进行的一键式操作。”

这次不去争辩持续交付的定义,关键是在这个概念背后,都有哪些实践,以及原因和产生的结果。比叫什么更重要的是为什么。

Continuous Delivery持续交付的各种说法“持续交付:发布可靠软件的系统方法”

持续交付是最早由Jez Humble和David Farley提出,并在“持续交付:发布可靠软件的系统方法”一书中对其实现进行系统说明。

全书并没有找到明确的持续交付定义,原书英文版书名是“Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation”。自然的,持续交付是将部署自动化包含在内的,而且也把Release和Delivery关联在一起。这里的自动化部署,更多的是部署流水线,不是持续部署的概念。

在Jez Humble的以下文章中,对他为什么会选择Continuous Delivery有详尽的描述https://continuousdelivery.com/2010/08/continuous-delivery-vs-continuous-deployment/

事实上,continuous deployment的概念是Timothy Fitz,在Jez的Continuous Delivery出版的前一年2009年提出的。Jez认为:

“What makes continuous deployment special is deploying every change that passes the automated tests (and optionally a short QA gate)to production. Continuous deployment is the practice of releasing every good build to users - a more accurate name might have been "continuous release”.”因此此处的持续部署是将所有通过自动化测试以及QA环境的构建,自动发布给客户的动作,Jez说更准确的名称应该是“持续发布”(又引入一个词汇,进一步混乱)。

“Continuous delivery is about putting the release schedule in the hands of the business, not in the hands of IT”

持续交付更像是一个业务行为,而不是技术行为。

“So when can you say you're doing continuous delivery? I'd say it's when you could flip a switch to go to continuous deployment if you decided that was the best way to deliver value to your customers.”

所以持续交付是在部署到生产环境之前,加了一个业务判断,决定是否交付给客户,然后一键部署到生产环境。这一定义与随后的大部分文档相似,包括DevOps Handbook。

Martin Fowler的持续交付

https://martinfowler.com/bliki/ContinuousDelivery.html

Martin 2013年的持续交付文章中,也对持续交付与持续部署进行了比较。观点与Jez的相似,同时也援引了Jez的文章。

持续部署是自动化的将一切变更放到生产环境,而持续交付则有判断决策过程,并直接说“In order to do Continuous Deployment you must be doing Continuous Delivery.”

“Continuous Delivery is sometimes confused with Continuous Deployment.Continuous Deploymentmeans that every change goes through the pipeline and automatically gets put into production, resulting in many production deployments every day. Continuous Delivery just means that you are able to do frequent deployments but may choose not to do it, usually due to businesses preferring a slower rate of deployment. In order to do Continuous Deployment you must be doing Continuous Delivery.”

对持续交付与持续部署的关系,Martin也承认两个概念容易造成困惑,持续部署代表将所有变更自动通过流水线推到生产环境,持续交付则意味着你有能力这样做,但可以基于业务选择不这样做。

所以我不觉得两者有谁包含谁,两者在这个层面讲,一个是技术领域,一个是业务领域。

乔梁的持续交付

而同时期乔梁的演讲资料中,持续交付的说明,被定义为交付业务价值,而不是IT内部团队之间的交付。

并且进一步描写说,持续部署是一个技术操作,持续交付是一个业务行为(此处的持续交付,更像是前面Jez说的发布概念)。

IBM的持续交付

IBM在2014年前后的持续交付方案中,将Continuous Delivery持续交付,等同于端到端的DevOps,所以自然的,交付的是端到端的价值,至于是否自动并没有说明,同时持续发布与部署被包含在整个持续交付的方案中。

DevOps Handbook上对持续交付、持续部署的定义

DevOps Handbook是2015年出版的,上面也有对持续交付和持续部署的说明,此处不详述,在后面有具体内容。也是我目前较为认同或者遵循的一个定义。

维基百科上的持续交付

https://en.wikipedia.org/wiki/Continuous_delivery

维基百科上的描述也有些不清不楚,对CD的定义中,最后一句话用了“repeatable deployment process”,似乎持续交付应该包含部署,只是没有用持续部署:

Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time.[1] It aims at building, testing, and releasing software with greater speed and frequency. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.

在后面有关“Relationship to continuous deployment”段落中,直接引用了前面说过的Martin Fowler的文章

https://martinfowler.com/bliki/ContinuousDelivery.html

此外,关于“Relationship to DevOps”段落中,DevOps是端到端的产品持续交付,而CD是后段的Dev to Ops,即狭义的DevOps概念。

Continuous delivery and DevOps are similar in their meanings and are often conflated, but they are two different concepts. DevOps has a broader scope, and centers around the cultural change, specifically the collaboration of the various teams involved in software delivery (developers, operations, quality assurance, management, etc.), as well as automating the processes in software delivery. Continuous delivery, on the other hand, is an approach to automate the delivery aspect, and focuses on bringing together different processes and executing them more quickly and more frequently. Thus, DevOps can be a product of continuous delivery, and CD flows directly into DevOps.

Jez Humble 2018年的持续交付

在Jez Humble今年北京站DevOpsDays闭门培训的内容中,对Continuous Delivery的定义,尤其是与Continuous Deployment的关系有了不一样的解读。在培训现场,大家还就此定义与Jez有过一番讨论。

同时,Jez对持续交付的定义是:The ability to get changes—features, configuration changes, bugfixes, experiments—into production or into the hands of userssafelyandquicklyin asustainableway.

从整个讲座的内容来看,Continuous Delivery更像是后半段的DevOps,即从CI开始到发布为止。

我对持续交付的理解

前面林林总总说了这么多持续交付的各种定义,各种出处,目的是从不同的视角看各个大师对持续交付的诠释。

对于持续交付以及持续部署等概念的解读,个人认为核心就是一句话:将技术行为与业务决策解耦。

小结

持续交付、持续部署、持续发布,更多的是技术行为与业务决策的区别。

John Allspaw说,“我不知道,在过去5年里的每一天,发生过多少次部署…我根本就不在乎,黑启动已经让每个人的信心大到几乎对它冷漠的程度”。

解耦不是分家,最终整体团队的衡量,还是要由业务形成闭环。持续发布是以持续部署为基础,持续部署提供技术能力,使得业务呢个个根据市场需要,随时进行特性发布,或是进行特性实验。

正是因为技术的支持,持续部署到生产环境,才能让业务前所未有的具备如此灵活的能力,任何业务的决策,可以不再如此紧耦合的依赖于IT。

这也是DevOps Handbook全书的重点,关注在”部署前置时间“,而并非前置时间。即全书都在围绕着代码提交那一刻往后的过程,因为作者们认为,在提交前的阶段,需要更多的创造性,具有更多不确定因素。而提交后的阶段,则相对是确定的,力求可预见性和自动化,将可变现降到最低,以此来支撑业务需要。

对于持续交付,持续部署的业界各种说法与实践,作为华为资深DevOps与精益敏捷专家的他,又是如何定义理解的呢?10月12日,2018华为全连接大会DevOps专场,华为资深DevOps专家会为您解答以上困惑,分享最新的DevOps理念。

诚邀您,出席2018华为全连接大会DevOps专场。业界大咖在DevOps的路上,等你来。