什么是 CI/CD 管道？
所谓 CI/CD 管道，是指代码从开发机器开始，经过测试和暂存，最终准备就绪到达用户手中而经历的一系列步骤。
由于 CI/CD 的策略是高度规律地定期执行此流程（通常一天多次），因此应尽可能自动化，让每一个步骤都触发下一个步骤或者在出错时发出标志。
自动化不仅能加快整个流程并促进各个反馈循环，还将确保各个步骤的一致性和可靠性。
构建管道的阶段
尽管 CI/CD 管道的确切形态取决于构建的产品类型以及组织要求，但所有管道都倾向于我们在此概述的通用模式。
流程从提交到主干（或您指定为 CI 分支的分支）开始，触发构建或初始单元测试集。 结果被反馈到仪表板，如果构建或测试失败，则留下标志并自动通知。
您可以配置管道停止流程，在解决问题后以新的提交重新开始，也可以为特定类型的失败创建例外，使流程继续推进。
下一阶段涉及一系列自动化测试，每轮测试后均提供反馈。 测试通常经过结构化，使最快的测试最先运行，从而尽早提供反馈。
端到端测试等更复杂的测试会占用服务器更长时间，只有在先前的测试成功通过后才会运行。 这有助于更高效地利用资源。
自动化测试完成后，软件通常会部署到一系列暂存环境中。其中部分可用于进一步的手动测试，另一部分可用于培训、支持和客户预览。
CI/CD 管道架构在最后阶段使更改生效，并且可以手动（持续交付）或自动（持续部署）触发。
接下来是关于各个阶段的具体注意事项。
标志和分支
采用持续集成的第一步是将整个代码库放入版本控制系统（VCS，又称源控制管理或 SCM），如 Git、Mercurial 或 Perforce，然后让团队中的每个成员都养成频繁提交更改的习惯。 对主干的每次提交都会启动管道，通过构建和测试代码为所写内容提供快速反馈。
虽然频繁提交是 CI/CD 管道中的一项重要做法，但如果您开发的是较大的功能，需要几天或几周才能完成，那么定期提交可能会成为一把双刃剑。
以有规律的增量在管道中推送更改可为您提供快速反馈，同时防止后期出现更复杂的冲突。
但另一方面，您可能不希望向用户发布半成品功能，而且您可能还没有准备好在暂存环境中与内部用户共享正在进行的工作。
功能标志和功能分支为这个问题提供了解决方法。 使用功能标志，您可以指定代码在哪些环境下对用户可见。 您的更改仍然提交到主干并且对您的团队可见，但您可以决定功能何时在暂存和生产中可用。
功能分支允许您利用自动构建和测试在单独的分支中开发功能。 就像提交到主干一样，只要在每次提交到功能分支时触发 CI/CD 管道，即可获得关于构建内容的快速反馈。
构建和测试
通过提交触发管道实例后，接下来的阶段是构建和测试。 如果您有自动化单元测试，这些测试通常在构建之前运行，并包含 Lint 分析和静态分析检查。
您使用的构建工具（如 Ant 或 Maven）以及构建步骤的详细信息将取决于您使用的语言和框架。 在专用构建服务器上运行自动化构建，可以避免因缺少依赖项而导致的后续问题（经典的“在我的机器上能用”）。
安装程序、二进制文件或容器（构建工件）从构建步骤输出后，部署到测试环境并与系统的其他部分结合，以运行更高级别的自动化测试：集成测试、组件测试和端到端测试以及非功能测试，例如性能和安全分析。
这些测试可以并行运行以加快管道速度并更快地提供反馈。
容器和 VM
为了使自动化测试得出可靠的结果，您需要确保运行的一致性。
理想情况下，您的测试环境应配置为尽可能接近生产环境，并且应在测试运行之间重置，避免环境不一致影响测试结果。
长期以来，虚拟机 (VM) 一直是运行测试环境的热门选择，因为您可以为接受测试的每个新构建编写刷新过程脚本。
但是，拆除和启动新 VM 会耗费时间，您的脚本也需要将每个虚拟环境的配置都纳入其中才能提供软件运行所需的所有依赖项。 添加新的依赖项时，环境脚本也应随之更新。这是一个很容易错过的细节，但却关乎您的构建能否运行。
要避免这些问题，您可以将代码打包在容器中作为初始构建步骤的一部分。 容器包含软件运行所需的所有依赖项，高度可移植且更易于部署到不同环境。
如果您是在自己的基础架构上托管 CI/CD，您仍然需要 VM 部署容器，但准备测试环境所需的工作较少，并有助于保持管道高效运行。 如果您是在云中运行管道，采用容器意味着您可以使用托管服务并将基础架构端交给您的云提供商。
预生产环境
管道架构中测试和暂存环境的数量将取决于您正在构建的内容以及组织中不同利益相关群体的需求。 例如探索性测试、安全审查、用户研究、销售演示、培训环境和支持人员复制客户问题的沙盒。
向环境自动创建和部署比手动刷新更加高效，您还可以为不同的环境配置不同的管道触发器。
例如，您的测试环境可能会在每次构建时更新，但您决定不再使用最新的成功构建频繁地刷新暂存环境（也许每天一次或每周一次）。
部署
代码更改成功通过前面的各个管道阶段后，即可发布到生产。 最后一步可为手动，也可为自动。
如果您想控制新特性或功能的提供时间，您的部署过程涉及用户停机，或者您的产品已安装完毕并且您希望按照定期发布时间表批量交付更改，则应选择手动发布（即持续交付）。
借助完全自动化的持续部署流程，更改通过所有先前阶段后即可部署上线。
根据代码库上开发者的数量和提交频率，这可能意味着您每天要向用户部署数十次更新；如果没有自动化管道，这几乎无法实现。
了解 CI/CD 管线：总结
CI/CD 通过尽早突出问题使软件开发更加高效，以更早的交互和更快的反馈（又名左移）帮助您快速失败。 构建自动化管道有助于将这些技术付诸实践。
在设计您自己的 CI/CD 流程时，应从持续集成开始分阶段构建。 管道的确切阶段以及确定何时触发具体阶段的逻辑取决于您的产品和组织。
CI/CD 平台将根据您的需求为您提供配置灵活易于管理的管道，帮助您建立值得信赖的发布流程，提高软件整体质量。