持续交付，持续部署，傻傻分不清楚
“持续交付与持续部署，到底谁应该包含谁？”
曾经在内部的培训课上提出这个问题，曾经就类似的问题和张乐讨论过，也曾经在某“德无哦普斯”群里和赵卫沟通过。
但是在准备DevOps Professional课件的过程中，再一次颠覆了原先的理解，不得不给张乐发微信说 “晕菜了”。
用了一晚上时间，仔细翻看DevOps Handbook相关内容，在网上也查阅了大量资料，试图去解读这两个概念的含义，以及背后的原因。
Jez Humble说，“在过去的5年里，人们对持续交付和持续部署的区别有所误解。的确，我自己对两者的看法和定义也发生了改变。每个组织都应该根据自己的需求做出选择。我们不应该关注形式，而应该关注结果：部署应该是无风险、按需进行的一键式操作。”
本文不去争辩持续交付的定义，关键是在这个概念背后，都有哪些实践，以及原因和产生的结果。比叫什么更重要的是为什么。
“持续交付：发布可靠软件的系统方法”
持续交付是最早由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 Deployment means 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, bug fixes, experiments—into production or into the hands of users safely and quickly in a sustainable way.
从整个讲座的内容来看，Continuous Delivery更像是后半段的DevOps，即从CI开始到发布为止。
前面林林总总说了这么多持续交付的各种定义，各种出处，目的是从不同的视角看各个大师对持续交付的诠释。
对于持续交付以及持续部署等概念的解读，个人认为核心就是一句话：将技术行为与业务决策解耦。
目前较为认同的是DevOps Handbook上对持续交付、持续部署的定义
“持续交付是指，所有开发人员都在主干上进行小批量工作，或者在短时间存在的特性分支上工作，并且定期向主干合并，同时始终让主干保持可发布状态，并能做到在正常工作时段里按需进行一键式发布。开发人员在引入任何回归错误时（包括缺陷、性能问题、安全问题、可用性问题等），都能快速得到反馈。一旦发现这类问题，就立即加以解决，从而保持主干始终处于可部署状态。”
“持续部署是指，在持续交付的基础上，由开发人员或运维人员自助式的定期向生产环境部署优质的构建版本，这通常意味着每天每人至少做一次生产环境部署，甚至每当开发人员提交代码变更时，就触发一次自动化部署。”
“持续交付是持续部署的前提，就像持续集成是持续交付的前提条件一样。”
这里面涉及到的有几个层面：持续集成、持续交付、持续部署，以及持续发布。
持续集成
持续集成的概念没有什么歧义，要求每当开发人员提交了新代码之后，就对整个应用进行构建，并对其执行全面的自动化测试集合。根据构建和测试结果，我们可以确定新代码和原有代码是否正确的集成在一起。
如果失败，开发团队就要停下手中的工作，立即修复它。（这正是丰田安灯系统的实践）
（以下几张图出自如下链接，对持续集成、持续交付、持续部署等描述相对比较清晰。https://www.mindtheproduct.com/2016/02/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/）
持续集成的目的是让正在开发的软件始终处于可工作状态。同时强调，代码的提交是一种沟通方式，而既然是沟通就需要频繁，下图中代码的提交过程，事实上就是各条分支之间的对话过程。
持续交付
Continuous Delivery (CD) 持续交付是持续集成的延伸，将集成后的代码部署到类生产环境，确保可以以可持续的方式快速向客户发布新的更改。如果代码没有问题，可以继续手工部署到生产环境中。
持续部署
如果真的想获得持续交付的好处，应该尽早部署到生产环境，以确保可以小批次发布，在发生问题时可以轻松排除故障。
于是有了持续部署。持续部署是在持续交付的基础上，把部署到生产环境的过程自动化。
持续测试
持续测试是贯穿整个内部研发流程始终的，从持续集成到持续部署，都有自动化测试的存在。
“没有自动化测试，持续集成就只能产生一大堆没有经过编译并且不能正确运行的垃圾”。自动化测试是持续集成的基础，同样也是其他实践的基础，越靠前的测试越应该自动化。
测试是获取反馈最有效的方式，从部署流水线中，能够看到在不同的环节，不同环境上运行的不同层面的测试。
从理想的测试自动化金字塔来看，截止到持续交付阶段，在开发环境、测试环境以及类生产环境，已经把开发内部需要运行的所有测试全都跑完了。
所以在这个点，从技术的层面上讲，代码是可以被部署到生产环境的；从业务的层面上讲，需要判断是否发布特性给用户，以获取最终的用户反馈。
将部署与发布解耦
让上帝的归上帝，凯撒的归凯撒。
需要将部署和发布解耦，部署和发布是不同的动作。部署更多是一个技术行为，而发布更多是业务决策。
不要把技术与业务决策混为一谈。部署与发布的解耦过程，也就是前面讲到的技术与业务的解耦过程。
-部署：在特定的环境上安装制定版本的软件。部署可能与某个特性的发布有关，也可能无关。
-发布：把一个/组特性提供给（部分或全部）客户的过程。
要实现部署与发布解耦，需要代码和环境架构能够满足：特性发布不需要变更应用的代码。
如果混淆了部署和发布，就很难界定谁对结果负责。
而这恰恰是传统的运维人员不愿意频繁发布的原因，因为一旦部署，他既要对技术的部署负责，又要对业务的发布负责。
解耦部署和发布，可以提升开发人员和运维人员快速部署的能力，通过技术指标衡量；同时产品负责人承担发布成功与否的责任，通过业务指标衡量。
按需部署，视技术的需要进行部署，通过部署流水线将不同的环境进行串联，设置不同的检查与反馈。
按需发布，让特性发布成为业务和市场决策，而不是技术决策。
“持续部署更适用于交付线上的Web服务，而持续交付适用于几乎任何对质量、交付速度和结果的可预测性有要求的低风险部署和发布场景，包括嵌入式系统、商用现货产品和移动应用。”
从理论上讲，通过持续交付，已经可以决定每天、每周、每两周发布一次，或者满足业务需求的任何频度。
而对于互联网应用，从持续交付走到持续部署，只是一个按键决策，是否将其自动化的过程。持续交付，更像是没有特性开关支持之下的业务决策。
当有了低风险发布的各种手段，例如基于环境的蓝绿部署、金丝雀发布；以及基于应用的特性开关、黑启动等；尤其是特性开关，使得部署到生产环境，并不意味着特性的发布，具体何时发布，对谁发布，都可以由业务决定。
也就是说，从技术上可以支撑持续的部署，同时与业务决策进行解耦。
所以此时只需要视不同的业务场景，来决定是否以及打开哪些特性开关，持续部署已经几乎可以完全脱离业务层面。
持续交付、持续部署、持续发布，更多的是技术行为与业务决策的区别。
John Allspaw说，“我不知道，在过去5年里的每一天，发生过多少次部署…我根本就不在乎，黑启动已经让每个人的信心大到几乎对它冷漠的程度”。
解耦不是分家，最终整体团队的衡量，还是要由业务形成闭环。持续发布是以持续部署为基础，持续部署提供技术能力，使得业务呢个个根据市场需要，随时进行特性发布，或是进行特性实验。
正是因为技术的支持，持续部署到生产环境，才能让业务前所未有的具备如此灵活的能力，任何业务的决策，可以不再如此紧耦合的依赖于IT。
这也是DevOps Handbook全书的重点，关注在”部署前置时间“，而并非前置时间。即全书都在围绕着代码提交那一刻往后的过程，因为作者们认为，在提交前的阶段，需要更多的创造性，具有更多不确定因素。而提交后的阶段，则相对是确定的，力求可预见性和自动化，将可变现降到最低，以此来支撑业务需要。
引用：
Jez Humble “Continous Delivery 1-day tutorial"
乔梁 “持续交付精要”
《DevOps Handbook》
《持续交付：发布可靠软件的系统方法》
（其他参考均在文中加注了链接）
（本文作者是DevOpsDays中国区核心组织者）
一起参加8月上海站DevOpsDays，Do something awesome！