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