持续集成、交付与部署

我们首先了解 CI 和 CD 的主要特征及其区别。

持续集成 (CI)

持续集成 (CI) 是一种自动检查代码更改以快速获得工作反馈的做法。使用 CI，每次您提交更改，CI 服务器都会运行构建并执行自动化测试。这些测试通常包括单元测试、集成测试和其他检查，例如 Lint 分析或静态分析。如果 CI 流程的某一阶段失败，您会收到自动反馈，以便您可以解决问题。当您提交修正时，流程将再次开始。

持续交付和持续部署

持续交付和持续部署之间的区别在于发布到生产的最后阶段。

采用持续交付，将构建工件发布到生产时需要手动输入。发布流程通常完全自动化，但必须有人决定是否以及何时发布具体版本。采用持续部署，每次完成流程的先前阶段时，构建都会自动发布到生产中。

在持续交付和持续部署之间进行选择

持续交付和持续部署的适用度取决于您的实际情况。

对于移动应用或 API 等软件产品，每次成功提交就发布一个新版本可能并不理想。相反，您可能更愿意按计划发布，或者等到最少数量的更改可供部署。

在这种情况下，您可以使用持续交付来验证所做更改，并在预生产环境中预览发布。持续交付还可以在每次发布之前提供手动验收测试的机会。

另一方面，持续部署非常适合基于 Web 的应用和服务，因为频繁（每日甚至每小时）的更新是标准。

持续部署使您能够逐步提供更新并获得快速反馈。您还可以使用持续部署来运行实验并与真实世界用户验证假设，根据需要使用新版本快速改变方向。

最后，值得注意的是，您可以将一些手动验收和探索性测试集成到持续部署流程中。

您不需要在每次发布之前进行手动检查，而是可以定期将更改部署到暂存环境并每周（或更长时间）执行测试。

同时，通过所有自动检查的更改可以继续发布到生产中。如果您在暂存中发现问题，自动化流水线可以确保您能够快速将修正部署到生产中。

CI/CD 代表构建、测试和发布软件的流程中的两个阶段。

CI/CD 流水线是一种可以逐步增强您对代码信心的工具。

每个成功的阶段都会增强您的信心，直到您愿意向用户发布代码。不过，如果有阶段失败，您将停止构建流程，并且必须修正 bug 或还原更改。问题解决后，流程将从头重新开始。

作为构建、测试和发布流程的第一阶段，CI 注重通过检查获取快速反馈。对代码更改的快速反馈可以减少上下文切换的需求，帮助您更高效地工作。您不必等待数小时或数天才能得到手动测试结果，而是在几分钟内就可以收到有关更改引起的任何问题的通知。

如果包含更改的构建通过了 CI 测试，则可以将其部署到预生产环境。此时，您可以执行运行时间更长且资源密集度更高的测试。

尽可能多地自动执行 CD 步骤可以进一步缩短反馈循环并实现更高效的工作流。例如，除了自动执行测试之外，您还可以刷新预生产环境并自动将构建部署到其中。

如果您刚接触 CI/CD，与其专注于在持续集成和持续交付或部署之间进行选择，我们建议您先决定从哪里开始以及要走多远。

CI 和 CD 都涉及多个步骤，这意味着您可以逐步制定流程。

寻找起点

如果您已经自动执行构建或发布流程的某些部分，或者您已经编写自动化测试，那么这些可以提供一个自然的起点。如果没有，请首先考虑构建、测试和发布流程中的哪些部分最耗时，或者由于测试不足而容易在生产中出现问题。

许多团队选择从 CI 开始，因为它需要与组织其他部分进行的协调较少，并且自动化单元和集成测试的快速反馈有助于提高代码质量。

此外，认识到 CI 的好处还有助于培养自动化测试文化（这对于有效的 CI/CD 至关重要），以及鼓励进一步扩展自动化测试覆盖范围。

另一方面，如果您当前同时管理发布协调和代码开发，长远来看，首先自动执行 CD 的最后阶段（发布到生产）可以为您节省时间。

虽然 CI 为 CD 提供了坚实的基础，但在持续交付和持续部署之间如何选择取决于您的要求。即使您的长期目标是持续部署，典型的策略也是从持续交付开始。在对自己的工作流建立信心后，您就可以自动执行最后的发布到生产阶段。

改进 CI/CD 流程

当您将开发任务分解为更小的可交付成果并定期提交更改时，CI 和 CD 会发挥最佳效果。

如果您的目标是持续部署，那么您需要考虑如何管理那些尚未准备好发布的功能，即使已经为其提交更改。您可以使用功能标志或分支策略来做到这一点，将正在进行的工作与发布分支隔离，同时确保您自动构建和测试每个代码更改。

总结：

• 持续集成 (CI) 涉及运行自动化测试和检查每次提交更改时解决方案是否构建。
• 持续交付和持续部署 (CD) 都涉及将构建工件自动部署到测试和暂存环境以运行进一步测试。您通常在持续集成之后执行这些步骤。
  • 在持续交付中，您可以决定何时将特定构建工件发布到生产中并手动启动发布。
  • 在持续部署中，每个成功通过先前阶段的代码更改都会自动发布到生产中。
• CI 和 CD 是互补的做法，用于快速发现问题并让您在发布更改之前树立信心。
• 如果您将任何 bug 发布到生产中，则具有自动化测试的稳健 CI/CD 流程可让您更快、更自信地部署修正。
• 完全自动化的构建、测试和发布流程由 CI 和 CD 组成，但您可以从其中之一开始并逐步构建流程。
  • 许多团队都从持续集成开始，因为自动化测试通常是开发者的责任。
  • 不过，如果您同时也负责处理发布，那么首先自动执行发布有助于节省时间，让您可以专注于构建 CI 流程。