1.4.2　持续交付

持续交付（Continuous Delivery，CD）是“软件开发的一种理念，按照这种方式构建的软件能够在任意时间发布到生产环境”。[12]借助持续交付，团队能够在短周期内实现特性，确保软件在任意时间都能可靠地发布。它是确保“轻松地对系统做出频繁和可预测的重大变更”（来自CNCF的云原生定义）的关键。

[12]　M. Fowler, “Continuous Integration Certification”, http://mng.bz/xM4X。

持续集成（Continuous Integration，CI）是持续交付中的一个基础实践。开发人员会持续（至少每天一次）将代码提交至主线（main分支）。在每次提交时，软件会自动编译、测试和打包成可执行制品（比如JAR文件或容器镜像）。它的理念是在每次新的变更后，得到软件状态的快速反馈。如果探测到错误的话，应该立即修正，确保主线是一个稳定的基础，以便于后续开发。

持续交付构建在CI之上，它的关注点在于，确保主线始终是健康的，处于可发布状态。在与主线集成所形成的可执行制品生成之后，软件会部署到一个类生产环境中。它会经历额外的测试以验证可发布性，比如用户验收测试、性能测试、安全性测试、合规测试，以及有助于增加软件可发布信心的其他测试。如果主线始终处于可发布状态，那么发布软件的新版本将会是一个业务决策，而不是技术决策。

正如Jez Humbleh和David Farley在合著的基础性图书Continuous Delivery（Addison-Wesley Professional，2010）中所述，持续交付鼓励整个过程通过“部署流水线”（也称为持续交付流水线）实现整个过程的自动化。部署流水线会从代码提交开始，一直延续到可发布的输出，它是通向生产环境的唯一方式。在本书中，我们将会构建部署流水线以保证main分支始终处于可发布状态。最后，我们会使用它将应用自动部署到Kubernetes生产环境中。

有时候，人们会将持续交付与持续部署（continuous deployment）相混淆。持续交付会确保在每次变更之后，软件都能处于一种可部署至生产环境的状态。至于何时进行真正的部署，这是一个业务方面的决策。而持续部署则是在部署流水线中添加最后一个步骤，在每次变更发生之后，将新的发布版本自动部署到生产环境中。

持续交付并不是工具，它是涉及组织中文化和结构变化的理念。搭建自动化的流水线来测试和交付应用并不意味着你在践行持续交付。与之类似，使用CI服务器来自动化构建并不意味着你在践行持续集成。[13]这就把我们引入到了下一个话题，它也通常被认为仅仅是一些工具而已。

[13]　M. Fowler, “Continuous Integration Certification”, http://mng.bz/xM4X。

持续交付与CI/CD

由于持续集成是持续交付的基础实践，该组合通常被称为CI/CD。因此，部署流水线经常被称为CI/CD流水线。我对这个术语有一些保留意见，因为持续集成并不是持续交付的唯一实践。例如，测试驱动开发（TDD）、自动化配置管理、验收测试和持续学习同样重要。

Jez Humble和Dave Farley在他们合著的Continuous Delivery一书中没有使用CI/CD这个术语，在他们写的关于这个主题的任何其他书中也没有使用。此外，它还会造成困惑。CD是代表持续交付还是持续部署呢？在本书中，我将把“更快交付更好的软件”[14]这一整体方法称为持续交付，而不是CI/CD。

[14]　D.Farley, Continuous Delivery Pipelines,2021。