什么是 CI/CD 管道？

但究竟什么是持续集成/持续交付管道？ 管道如何制作？

如果您一直在关注持续集成、交付和部署（统称为 CI/CD），您很可能遇到过“自动化管道”这个术语，并对其在实施这些做法中发挥的核心作用有一定了解。

CI/CD 是一种 DevOps 实践，可帮助您在不影响质量的前提下更快地交付软件。CI/CD 包括频繁提交更改、严格测试这些更新并及时处理反馈。拥有自动化的 CI/CD 管道对这种工作方式至关重要。

CI/CD 管道说明

所谓 CI/CD 管道，是指代码从开发机器开始，经过测试和暂存，最终准备就绪到达用户手中而经历的一系列步骤。

由于 CI/CD 的策略是高度规律地定期执行此流程（每天甚至每小时执行多次），因此应尽可能自动化。如果一个步骤成功完成，就会自动触发下一个步骤。如果某个步骤失败了，应迅速传达反馈信息，以便解决问题。

将 CI/CD 管道自动化不仅能加快构建、测试和部署软件的整体流程，还能确保每个步骤都能稳定可靠地执行。

构建管道的阶段

尽管 CI/CD 管道的确切形态取决于构建的产品以及组织，但所有管道都倾向于通用模式：

  1. 流程从提交到主分支（或您指定为 CI 分支的分支）开始，触发构建或初始单元测试集。结果通常可以在仪表盘上看到。可以将管道设计为在构建或测试失败时停止，以便在继续之前解决任何问题。修复提交后，管道会自动从头开始重启，以确保一切按预期运行。或者，您也可以配置管道继续运行，同时标记失败以进行调查。
  2. 下一阶段涉及一系列自动化测试，每轮测试后均提供反馈。 测试通常经过结构化，使最快的测试最先运行，从而尽早提供反馈。资源密集型测试最后运行，但前提是前面的所有步骤都已成功完成。资源密集型测试最后运行，但前提是前面的所有步骤都已成功完成。
  3. 自动化测试完成后，软件通常会部署到一系列暂存环境中。其中部分可用于进一步的手动测试，另一部分可用于培训、支持和客户预览。
  4. CI/CD 管道架构的最后阶段是将更改上线。发布可以手动（持续交付）或自动（如持续部署）触发。

What follows are specific notes about each stage.

CI/CD 最佳做法

构建 CI/CD 管道不是一劳永逸的工作。探索管道的 CI/CD 最佳实践。

标志和分支

采用持续集成的第一步是将整个代码库放入版本控制系统（VCS，又称源控制管理或 SCM），如 Git、Mercurial 或 Perforce，然后让团队中的每个成员都养成频繁提交更改的习惯。每次提交到主分支都会启动持续集成管道，构建和测试代码，以便快速反馈最新更改。

虽然频繁提交是 CI/CD 管道中的一项重要做法，但如果您开发的是较大的功能，需要几天或几周才能完成，那么定期提交可能会稍有反作用。

一方面，通过管道定期推送更改，可以获得快速反馈。与等到完成功能后再进行合并相比，它还能减少复杂的合并冲突。

另一方面，通过管道推送未完成的功能可能并不理想。与用户共享未完成的工作，即使是在暂存环境中，可能也不可取。

功能标志和功能分支为这个问题提供了解决方法。使用功能标志，您可以指定代码在哪些环境下对用户可见。您的更改仍然提交到主分支并且对您的团队可见，但您可以决定功能何时在暂存和生产中可用。

功能分支允许您利用自动构建和测试在单独的分支中开发功能。就像提交到主干一样，只要在每次提交到主分支时触发 CI/CD 管道，即可获得关于构建内容的快速反馈。

构建和测试

通过提交触发管道实例后，接下来的阶段是构建和测试。如果您有自动化单元测试，这些测试通常在构建之前运行，并包含 Lint 分析和静态分析检查。

您使用的构建工具（如 Ant 或 Maven）以及构建步骤的详细信息将取决于您使用的语言和框架。在专用构建服务器上运行自动化构建，可以避免因缺少依赖项而导致的后续问题（经典的“在我的机器上能用”）。

构建步骤会生成应用程序工件，其中可能包括安装程序、二进制文件或容器。然后将这些工件部署到测试环境中，并与其他系统组件集成，以运行更高级别的自动测试：集成测试、组件测试和端到端测试，以及非功能测试，如性能和安全分析。

这些测试可以并行运行以加快管道速度并更快地提供反馈。

CI/CD 的自动化测试

了解为什么测试对 CI/CD 流程如此重要，以及测试有哪些种类。

容器和 VM 比较

为了使自动化测试得出可靠的结果，您需要确保运行的一致性。

理想情况下，您的测试环境应配置为尽可能接近生产环境，并且应在测试运行之间重置，避免环境不一致影响测试结果。

长期以来，虚拟机 (VM) 一直是运行测试环境的热门选择，因为您可以为接受测试的每个新构建编写刷新过程脚本。

但是，拆除和启动新 VM 会耗费时间，您的脚本也需要将每个虚拟环境的配置都纳入其中才能提供软件运行所需的所有依赖项。添加新的依赖项时，环境脚本也应随之更新。这是一个很容易错过的细节，但却关乎您的构建能否运行。

要避免这些问题，您可以将代码打包在容器中作为初始构建步骤的一部分。容器包含软件运行所需的所有依赖项，高度可移植且更易于部署到不同环境。

如果您是在自己的基础架构上托管 CI/CD 管道，您仍然需要 VM 部署容器，但准备测试环境所需的工作较少。如果您在云中运行管道，采用容器意味着您可以利用托管服务并将基础架构管理卸载给云提供商。

预生产环境

管道架构中测试和暂存环境的数量将取决于您正在构建的内容以及组织中不同利益相关群体的需求。例如探索性测试、安全审查、用户研究、销售演示、培训环境和支持人员复制客户问题的沙盒。

向环境自动创建和部署比手动刷新更加高效。您还可以为不同的环境配置不同的管道触发器。

例如，您的测试环境可能会在每次构建时更新，但您决定不再使用最新的成功构建频繁地刷新暂存环境（也许每天一次或每周一次）。

部署

代码更改成功通过前面的各个管道阶段后，即可发布到生产。最后一步可为手动，也可为自动。

在下列情况下，手动发布（持续交付）非常有用：

  • 您希望控制新特性或功能的可用时间。
  • 您的部署过程涉及用户的停机时间。
  • 用户需要安装您的产品，而您希望按定期发布计划批量交付更改。

通过持续部署，发布是自动进行的。在通过之前所有阶段后，更改才会生效。对于频繁提交的大型团队来说，这可能意味着每天要向用户部署几十次更新。如果没有自动化管道，这几乎是不可能完成的任务。

了解 CI/CD 管线：总结

CI/CD 是一种 DevOps 实践，利用自动化对软件开发生命周期的每个阶段提供快速反馈。发现最新代码变更所带来的问题可提高软件开发效率。通过左移方法（更早地进行互动，更快地获得反馈），您就有能力快速失败，而建立自动化管道则有助于将这些技术付诸实践。

在设计您自己的 CI/CD 流程时，应从持续集成开始分阶段构建。管道的确切阶段以及确定何时触发具体阶段的逻辑取决于您的产品和组织。

CI/CD 平台将根据您的独特需求配置灵活易于管理的管道，帮助您建立值得信赖的发布流程，提高软件整体质量。

TeamCity 如何提供帮助

我们的 TeamCity Pipelines 解决方案可以帮助自动执行您现有的 CI/CD 流程。

TeamCity Pipelines 支持所有主流版本控制系统，并与流行的构建、测试和软件包管理工具集成，可以将您的开发工作流转变为高效的自动化管道。

灵活的触发选项和可视化管道编辑器可轻松为任何工作流程配置管道。配置会自动存储为代码，让您可以在 GUI 中构建和管理管道，同时享受配置即代码的好处。

TeamCity 的内部部署和云原生部署选项让您可以灵活地在任何地方运行管道，并按需扩展。像测试并行化和实时反馈这样的功能，可以帮助您快速失败，从而获得更高效的开发者体验。

仍有问题？了解更多信息，请参阅 常见问题部分。