什么是持续交付？

DevOps 的核心是思维方式的转变。 DevOps 倡导协作和从短的迭代周期中快速获取反馈，而不是将软件开发流程视为单向传送带，要求、代码和报告以线性方式从一个团队传递到另一个团队。

改变您对“完成”的定义可以帮助您形成这种心态：不要在将代码交给链条的下一个团队后就认为您的部分已经完成，只有您的新功能或代码更改发布上线后才算完成。 如果在管道的任何阶段发现问题，与必须由更改委员审批的冗长报告相比，及时传达反馈并展开协作可以更快地解决问题。 这就是持续交付的意义所在。

纵观整个软件开发生命周期，而不仅仅是其中的一部分，可以使您更好地了解如何向用户交付软件，并有机会与其他相关团队展开更多的交流。

持续交付就是要找出拖慢交付流程的痛点，并建立一个自动化管道，使发布速度更快、更可靠，让您可以随时准备发布。 建立好管道后，您应该能够使用一个命令将良好的构建部署上线。

持续集成为此奠定了基础，代码更改至少每天都会提交，然后通过自动化构建和测试流程向开发者提供快速反馈。 如果构建或测试失败，解决它就是所有人的首要任务。

及早发现错误，就可以在代码还未成型的时候进行修复，避免其他功能在错误的代码上构建后再被移除。 通过持续交付，包含 CI 流程最新更改的构建会经由一系列预生产环境自动升级。 虽然最终推送到生产的操作需要手动触发，但它仍然遵循一个脚本化流程，易于重复，可根据需要多次发布。

构建 CI/CD 管道是与发布流程中的各种利益相关者合作的机会，您可以将他们的需求纳入管道设计中。 希望您在设计自动化测试时已经让您的 QA 同事参与。

在（尽可能接近生产的）合适测试环境中增加一个手动探索性测试的阶段，将识别您未预料到的故障（随后可以由自动化测试覆盖）。 这是持续交付的一个重要步骤。

信息安全或网络安全团队通常被视为频繁发布的障碍，因为安全审核需要大量时间和长篇报告。 采用 DevSecOps 方法可以帮助您将安全要求融入到管道中。

所需的确切构建步骤、环境和测试取决于软件的架构和组织的优先级。 如果您要基于微服务构建系统，可以利用该架构对各个服务并行运行测试，然后再将其组合以进行更复杂的集成和端到端测试。

对管道上的每个错误修复都进行手动探索性测试可能有些不切实际，在这种情况下，根据更改类型设置可选步骤或替代管道可能更高效地持续交付。

确定管道的阶段后，包括每个阶段要运行的测试，就可以编写流程脚本，确保其可靠且可重复。 为了避免引入不一致，应将 CI 阶段的相同构建工件部署到每个预生产环境和生产本身。

理想情况下，应该为每个新构建刷新测试环境，并且将容器与基础架构即代码方法搭配使用意味着您可以编写这些步骤的脚本，还可以根据需要拆除和拆分新环境。

如果您的管道包括供支持、销售或营销团队熟悉新功能的过渡环境，您可能更希望手动控制新构建的更新时间，以避免干扰正在进行的工作。 与最终发布上线一样，部署仍可脚本化以保持流程的快速和一致。

持续交付承诺在不影响质量的情况下加快发布速度，但要实现这一目标，需要组织中的多个部门合作。

打破孤岛对短期来说是一项挑战，但也将带来长远的利益，因为这种协作将帮助您更有效地工作。

实施持续交付需要投入时间，前景可能令人生畏。 采取迭代方法并随着时间的推移构建流程将使其更易于管理，并让您能够向高级利益相关者展示其优势。 收集有关构建和测试时间的指标并将其与手动过程进行比较，可以简单明了地展示投资回报率和缺陷率。

在规划基础架构要求时，衡量持续交付的价值可能会非常有用。 随着发布流程规模的扩大，您可能希望并行运行多个构建和测试，而可用的机器可能会成为一个限制因素。 优化管道的性能后，您可能需要考虑迁移到云托管的基础架构，以根据需要进行扩缩。

构建 CI/CD 管道看起来是一项艰巨的任务，最初需要团队大量投入。 不过，如果操作得当，CI/CD 可以让团队在十分之一的时间内建起软件交付流程。 但是，重点是遵循 CD 最佳做法正确设置流程。

持续交付是自动执行将软件交付到生产所需的各个步骤的流程。 但是，它并不需要完全自动执行软件的发布 – 这是持续部署发挥作用的地方。 我们可以将持续交付和持续部署视为同一 CI/CD 流程的不同部分。

详细了解持续交付与部署

持续交付使发布软件变得更加轻松快捷，您可以更频繁地部署到生产。 更频繁交付的小型更新将取代大型的季度或年度发布。 这不仅意味着用户可以更快获得新功能和错误修复，还意味着您可以了解软件的实际使用情况并相应调整计划。

虽然某些组织倾向于对发布流程的最后一步保持控制，但对其他组织来说，CI/CD 管道的逻辑结论是使用一种称为持续部署的做法将发布自动上线。