连续交付与连续部署

在上一课中，我们学习了持续集成（CI），其中代码更改会被频繁合并和测试。但是，代码完成集成并通过测试后会发生什么呢？

这正是持续交付和持续部署发挥作用的地方。它们对于快速、可靠地将软件交付给用户至关重要。

持续交付（CD）是一种软件开发实践：代码更改会被自动构建、测试，并准备好发布到生产环境。

• 其核心理念是，软件始终处于可部署状态。
• 不过，部署到生产环境的最终步骤需要手动完成，由人工决定是否触发。

您可以把它想象成一台运转良好的机器：它负责准备产品，但产品离开工厂前，仍需要由人员发出最后的“开始”指令。

• 提交代码：开发人员推送代码。
• 持续集成流程：代码经过构建、单元测试和集成。
• 自动化测试：进一步的测试（集成测试、端到端测试）自动运行。
• 创建制品：创建可部署的软件包（例如 Docker 镜像）。
• 部署到预发布环境：软件包自动部署到预发布环境，以进行最终检查。
• 手动发布：团队成员手动批准并触发部署到生产环境。

持续交付能为开发流程带来显著优势：

• 降低风险：每次更改的规模都很小，因此更容易发现和修复问题。
• 更快的反馈：团队能更快获得有关更改的反馈，从而提高质量。
• 更高的质量：严格的自动化测试能在人工批准前减少错误。
• 更快推向市场：软件始终准备就绪，从而加快发布速度。

持续部署（CDep）将持续交付又向前推进了一步。它意味着，每项通过全部自动化测试的更改都会自动发布到生产环境。

• 部署到用户之前没有人工批准步骤。
• 这要求您对自动化测试和监控具有极高的信心。

您可以把它想象成一座完全自动运行的工厂：产品在没有人工干预的情况下完成构建、测试，并立即发货。

• 提交代码：开发人员推送代码。
• 持续集成流程：代码经过构建、单元测试和集成。
• 自动化测试：所有集成测试、端到端测试和性能测试自动运行。
• 创建制品：创建可部署的软件包。
• 部署到预发布环境：软件包自动部署到预发布环境。
• 自动部署到生产环境：如果所有测试都通过，软件包就会自动部署到生产环境。

持续部署将发布速度和反馈循环的速度提升到最大：

• 超快速发布：新功能和错误修复几乎可以立即到达用户手中。
• 即时反馈：真实使用数据和错误报告能更快反馈回来。
• 真正的敏捷性：团队可以以前所未有的速度迭代，并响应市场变化。
• 减少额外开销：省去手动协调发布所需的时间和精力。

持续交付和持续部署的主要区别在于，由谁（或什么）决定将软件部署到生产环境：

• 持续交付：自动化确保软件始终准备好发布，但由人工决定何时按下按钮，将其部署到生产环境。
• 持续部署：自动化处理全部流程；软件一旦通过所有测试，就会自动部署到生产环境。最终发布无需人工干预。

选择持续交付还是持续部署，取决于团队的成熟度、对自动化的信心以及风险承受能力。

• 从持续交付开始：这是更安全的起点，有助于逐步建立对流程的信心。
• 转向持续部署：只有在自动化测试、监控和回滚策略都极其可靠时才应这样做。
• 考虑具体情况：受到严格监管的行业（例如金融和医疗）通常会因合规要求而更倾向于持续交付。

以下哪项最准确地描述了持续交付与持续部署之间的主要区别？

现在，您已经了解了持续交付和持续部署之间的关键区别！

• 持续交付（CD）：软件始终准备好发布，但由人工触发最终的生产环境部署。
• 持续部署（CDep）：软件一旦通过所有自动化测试，就会自动发布到生产环境。

这些实践建立在持续集成之上，是在 DevOps 文化中实现快速、可靠的软件发布的基础。