基于状态的声明式表达： 在应用的整个生命周期中，应用始终处于可部署状态，我们可以随时、随地地往线上环境快速地发布我们的新功能特性。
基于过程的实现式表达： 在持续集成的基础之上，使用各种低风险的部署策略，部署/发布/交付功能或产品，并且在风险真正发生后，可以快速回退或更新修复的工程和流程实践。
什么是持续交付?
产品越快交付到客户手上，获得的用户反馈越早，从而来验证产品/功能的价值，以便在下一个交付中，持续提高和改善产品，形成良性的反馈循环，降低了开发无效产品的业务风险，减少了(成本)浪费，提高了业务成功性。
持续交付是一种方法论，思维方式的转变和领导力实践，重点关注于如何在整个应用程序的生命周期中实现快速交付
对 CD 实践的成功性，有一个关键的测试点：当项目利益干系人要求上线当前正在开发中的软件时，我们可以立即将其部署到生产环境中。
这里面隐含两点：
- 部署到生产环境中的未完成的软件，不会对线上已经发布的功能特性产生任何影响。
- 未开发完成的功能特性对用户来说是不可见的，或是用户可以选择是否可见。
持续交付，简称 CD，它能够以可持续的方式安全快速地将所有类型的变更（包括新功能，配置更改，错误修复和实验特性）部署到生产系统或交付给用户。
我们的目标是进行部署 - 无论是大规模分布式系统、复杂的生产环境或嵌入式系统还是应用可预测的日常事务，都可以随时发布。
我们通过确保我们的代码始终处于可部署状态来实现这些目标，即使面对的是数千名开发人员，每天都在提交变更的团队。 因此，我们完全消除了过去遵循的 “开发完整” 再集成，测试和硬化，以及代码冻结。
在持续交付实践中，关注的方面有：
- 使用持续集成构建高质量的软件
- 频繁小批量地提交代码变更
- 自动化地由计算机来执行重复性的任务，人来解决问题
- 不断追求对交付的过程和已交付软件的持续改进
- 在软件交付的整个生命周期中，每个人都有责任
为什么需要持续交付?
通常情况下，我们会认为，频繁的变更和部署应用软件，将给我们的系统带来更大概率上的不稳定性和不可靠性。事实上，近年来随着对持续集成和交付理念和实践的团队增多，通过对这些团队的调研，我们获取到的事实是：那些始终坚持快速交付的团队的可靠性要胜过低速交付服务的团队。即使是在有很多限制的金融和政府领域。
快速交付服务的能力给那些愿意投资执行持续交付的组织提供了很大的竞争优势。
持续交付实践的优势包括有：
- 低风险的发布
持续交付最主要目标就是保证应用软件的部署对用户来说是无感知的，通过使用部署流水线和一系列低风险发布的模式，来达到零宕机的部署的过程，最后实现无感知的发布。
频繁的集成和部署，导致我们每次部署的都是比较小的变更，所有会有更少的错误，即使出现了问题也是比较容易修复。
- 更快的交付到用户
持续交付是对持续集成实践的进一步扩展，在集成的基础上更关注于部署和交付的实践，那在持续集成的实践中所有实现了的价值也都将体现在持续交付中，这其中最重要的是持续集成实践解决了过去 “整体集成阶段” 这个老大难的问题，为持续交付中更快的交付应用软件提供了保障。
- 更高的质量
从用户价值交付和质量测试的角度来说，通过持续集成实践，它在帮助我们更快的发现和解决回归性问题的同时，这也意味着我们可以有更多的时间投入在用户价值研究或是其他更高级别的测试实践上，例如探索性测试、可用性测试、性能和安全测试。在整个交付流程中，通过构建部署流水线，这些测试活动，将可以被持续的执行，最终实现帮助我们交付更高质量和价值的产品。
- 更低的成本
任何一款成功的软件产品或是服务，在其终生的道路上都是在不断演化的。通过在构建/测试/部署和环境自动化上的投资，这将会帮助我们显著的减少在产品上创造和交付重大变化的成本。当然是排除发布过程中相关的固化成本。
- 更好的产品
在持续交付的实践中，不断地交付最小可行的产品。这意味着我们可以在贯穿整个交付生命周期内，根据可用的软件获取用户的反馈。技术上例如 A/B 测试帮助我们实现假设驱动的产品开发方法，以此我们可以在构建完整的功能之前，测试用户的想法。这意味着我们可以避免构建的 2/3 的功能特性，为业务交付了价值为零或是负值。
所以，只有越早和越频繁的从真实用户的那里获得到我们开发的应用软件的反馈，我们就能越快的获取我们开发的应用软件的真是价值所在。
- 更幸福的团队
频繁的交付使得在整个发布流程中团队之间的合作更加的紧密，一些非业务相关的团队也会更加的关注交付的产品特性和用户价值中来。团队内部和团队间的沟通更加紧密。
总的来说持续交付的好处有：
- 加速产品推向市场的时间
- 交付正确的产品
- 提高了生产力和效率
- 可靠的交付
- 提高了产品的质量
- 提高了客户满意度
如何实践持续交付?
为实现持续交付我们需要：
- 敏捷开发实践，CI/CD 是它的子集，也是 “持续” 这一系例实践的来源，保证了健壮的持续的小的变更提交 ( UT / Refactoring / Feature Switch / Deployable Change / US Split / etc …)
- 在交付过程中涉及到的每一个人，他们之间需要一个紧密的互相协作的关系（这就是我们经常提到的 DevOps 文化）
- 尽可能的自动化一切可以自动化的交付流程，这就需要我们的部署流水线来实现
实现持续交付是通过开发团队持续的集成、构建(可执行的软件包)和运行自动化测试(为构建的软件包)来检查问题，并且不断的把通过测试的软件包部署到类生产环境中来保证软件在正式的生产环境运行的成功性。
这一流程是持续交付的核心环节，我们称之为部署流水线。
- 建立持续交付的基本要求之一是建立一个自动化的持续集成系统，自动和一致地构建应用程序将程序组件和资源构建到可部署的软件包中。
- 采用自动化流程来精简手动流程，并在软件交付流程中中实现一致性和可重复性，以及在 Dev 和 Ops 团队之间增强协作和共享指标和流程。
- 持续部署可以理解为自动化的部署上线，不需要人工接入和触发，实践持续部署的前提条件是实践持续交付。
如何转型到持续交付流程：
引入持续交付的一个好方法是将当前的交付流程建模为一个部署流水线，然后其中对瓶颈、可以自动化的地方和可以加强各角色间的协作点进行检查。
- 持续集成程度和流水线 (基于 SCM 的开发工作流)
- 部署流水线
- 可持续的部署策略
- 部署后的持续反馈
小贴士：
- 没有标准化的流水线，只有符合原则下的最适合的流水线
- 接入 CD，不是一口吃成胖子，而是基于原则上聚焦于瓶颈（交付速度会有显著的提高）
- 流水线包括配置管理，集成环境也要代码化
- 部署策略的实践包括有无害的数据库结构变更、可回滚性、零宕机时间的策略等
实践持续交付的关键点：
- 环境一致性，可使用配置管理工具实现，自动化的同时保证一致性
- 不可变的基础设施，可使用镜像工具实现，系统镜像/依赖库镜像/程序运行时镜像等
- 基础设施/配置/流水线即代码，版本化、流程化、自动化基础设施/配置管理/流水线的开发变更流程
- 关闭对机器的人工登陆访问，所有需要登陆系统进行的人工操作，都是要避免的，需要使用其他更透明的方法代替
- 度量/监控和日志采集一切，如果说监控是整个系统的视觉那么日志采集便是整个系统的知觉
实践持续交付的反模式：
- 人工操作，构建/测试/部署/环境初始化等人工操作
- 漫长的流程，这其中包括工单和审批系统
实践持续交付的几个度量指标：
- 在应用软件的整个生命周期中，它始终处于可部署上线的状态。
- 在开发新的功能特性时，团队的优先级是始终保持(开发中的)应用软件处于可部署状态。
- 当有人对线上系统提交一个变更之后，任何人在任何时候都够快速的、自动的获取该变更的反馈。
- 我们可以随时部署任何版本的应用软件到任何环境，并且不需要向测试人员进行确认。