持续集成、交付与部署

开发者通常将持续集成 (CI) 和持续交付或部署 (CD) 称为 CI/CD。 了解这些 DevOps 做法之间的差异可以帮助您分解设置 CI/CD 流程所涉及的工作，更轻松地利用改进的质量和稳定性。

持续集成、交付与部署

持续集成和持续交付或部署是构建、测试和部署软件工作流中的关键阶段。 目标是向用户提供更小、更频繁的更改，使您正在构建的内容能够获得定期反馈。 CI 和 CD 都依靠自动化来提高效率和可靠性。

在开发 CI/CD 流程之前，有必要了解持续交付、持续部署和持续集成之间的区别。

CI 和 CD 的主要区别

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

持续集成 (CI)

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

持续交付和持续部署 (CD)

持续交付和持续部署 (CD) 从 CI 结束的地方开始。 两者都涉及将构建工件部署到一个或多个测试环境以进行进一步自动化测试，例如端到端、GUI、性能和安全测试。 构建必须成功通过所有测试才能被视为可以发布。

与 CI 一样，如果测试在某一 CD 阶段失败，流程将停止并报告详细信息，供您调查和修正问题。 在新构建准备就绪后，流程将从头开始，经过所有 CI 步骤，然后进入 CD 阶段。

持续交付和持续部署

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

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

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

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

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

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

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

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

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

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

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

持续集成、交付与部署

持续集成、交付和部署如何协同工作

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

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

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

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

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

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

从 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 流程。