什么是持续集成（CI）/持续交付（CD）管道？

发布时间：2025-11-05 10:56:01 来源：创站工坊 作者：IT科技类资讯

【.com快译】持续集成(CI)/持续交付(CD)管道是什持一系列步骤，其中包括从CI/CD流程开始的续集续交所有阶段，并负责创建自动化和无缝的成CI持软件交付。而使用CI/CD管道，什持软件发布工件可以从代码检入阶段到测试、续集续交构建、成CI持部署和生产阶段一直在管道中前进。什持这一概念之所以强大，续集续交是成CI持因为一旦指定了管道，就可以将其部分或全部实现自动化，什持从而加快了流程，续集续交并减少了错误。成CI持换句话说，什持CI/CD管道使组织每天更轻松地自动多次交付软件。续集续交

DevOps工程师往往会因为CI/CD中各个阶段的成CI持自动化而与CI/CD管道混淆。虽然不同的工具可以使CI/CD中的各个复杂阶段实现自动化，但由于人工干预，CI/CD的整个软件供应链仍然可能被中断。以下将探讨持续集成(CI)/持续交付(CD)流程的各个阶段，以及为什么CI/CD管道对于组织以快速和大规模的方式交付代码至关重要的原因。

CI/CD阶段：了解人员、流程和技术

组织应用程序开发团队通常由开发人员、测试人员/质量保证(QA)工程师、高防服务器运营工程师和站点可靠性工程师(SRE)或IT运营团队组成。他们紧密合作，将高质量的软件交付到客户手中。持续集成(CI)/持续交付(CD)是两个独立过程的组合：持续集成和持续交付。以下列出了CI/CD管道中的主要步骤。

持续集成(CI)：代码提交

持续集成(CI)是构建软件并完成初始测试的过程。持续交付(CD)是将代码与基础设施相结合的过程，确保完成所有测试并遵循策略，然后将代码部署到预期的环境中。当然，许多组织都有自己的流程，但主要步骤如下所示：

代码提交阶段也称为版本控制。提交是将开发人员编写的最新更改发送到存储库的操作。免费信息发布网开发人员编写的每一个版本的代码都是无限期存储的。在与合作者讨论和审查更改之后，开发人员将编写代码，并在软件需求、功能增强、错误修复或更改请求完成后提交。管理编辑和提交更改的存储库称为源代码管理(SCM工具)。开发人员在提交代码(代码推送请求)后，代码更改将合并到存储在中心存储库(如GitHub)中的基本代码分支中。

持续集成(CI)：静态代码分析

开发人员编写代码并将其推送到存储库后，系统将自动触发以启动下一个代码分析过程。想象一下这样一个步骤：提交的代码可以直接构建，而在构建或交付期间失败。就机器和人力的资源利用率而言，这都是一个成本昂贵的缓慢过程。亿华云组织必须检查代码中的静态策略，静态应用程序安全测试(SAST)是一种白盒测试方法，可以使用SonarQube、Veracode、Appscan等SAST工具从内部检查代码，以发现软件缺陷、漏洞和弱点(例如SQL注入等)。这是一个快速检查过程，其中检查代码是否存在语法错误。尽管此阶段缺少检查运行时错误的功能，但该功能将在以后的阶段中执行。

将其他策略检查放入自动管道中可以显著地减少在该过程中发现的错误数量。

持续集成(CI)：构建

构建验证测试(BVT)/烟雾测试和单元测试：

创建构建后立即执行烟雾测试。构建验证测试(BVT)检查所有模块是否正确集成，以及程序的关键功能是否正常运行。测试的目的是放弃严重损坏的应用程序，以使质量保证团队不会浪费时间安装和测试软件应用程序。

在这些检查之后，将单元测试(UT)添加到管道中，以进一步减少生产中的故障。单元测试测试开发人员编写的代码的各个单元或组件，以验证它们是否按预期执行。

工件存储：

一旦准备好构建，数据包就存储在一个称为工件或存储库工具的集中位置或数据库中。每天可能会生成很多构建，并且跟踪所有构建可能会很困难。因此，一旦生成并验证构建，它就被发送到存储库进行存储。存储库工具(如Jfrog Artifactory)用于存储二进制文件，如.rar、.war、.exe、Msi等。在此，测试人员可以通过人工选择，并在测试环境中部署工件以进行测试。

持续集成(CI)：测试阶段

这些自动化测试由测试人员(或质量保证工程师)设置，他们根据用户案例设置了测试用例和场景。他们执行回归分析和压力测试以检查与预期输出的偏差。测试涉及的活动包括健全性测试、集成测试、压力测试。这是一种非常高级的测试。在这里，可以发现开发人员可能未知的问题。

集成测试：

集成测试是使用诸如Cucumber、Selenium等工具执行的，其中将单个应用程序模块组合并作为一组进行测试，同时评估是否符合指定的功能需求。在集成测试之后，需要有人批准该组中的更新集应该移动到下一阶段，这通常是性能测试。这种核查过程可能很繁琐，但它是整个过程的重要组成部分。在测试过程中出现了一些新的解决办法。

负载平衡和压力测试：

负载平衡和压力测试也使用自动化测试工具(如Selenium、JMeter等)执行，以检查应用程序运行是否稳定，并且在高流量环境下是否良好。由于全面的压力测试是长期运行的，因此通常不会在每次更新上运行这一测试。当要发布主要的新功能时，将对多个更新进行分组，并完成完整性能测试。如果将单个更新移动到下一阶段，则管道可能包括金丝雀测试作为替代。

持续交付(CD)：Bake

Bake是指从源代码中创建一个不可变的映像实例，该实例在生产环境中具有当前配置。这些配置可能是数据库更改和其他基础设施更新之类的内容。Spinnaker可以触发Jenkins来执行这个任务，而有些组织更喜欢使用Packer。

持续交付(CD)：Deploy

Spinnaker自动将Bake的映像传递到Deploy阶段。这是将服务器组设置为部署到集群的位置。与上述测试过程类似，在Deploy阶段执行功能相同的过程，首先转移到测试阶段，然后转移到产品环境，最后进行批准和检查。其整个过程由Spinnaker之类的工具处理。

持续交付(CD)：验证

这也是组织的团队优化整个CI/CD流程的关键位置。因为现在已经进行了大量的测试，所以失败很少见。但是，此时必须尽快解决所有故障，以最大程度地减少对最终客户的影响。团队也应该考虑使流程的这一部分自动化。

使用蓝绿部署、金丝雀分析、滚动更新等策略部署到产品。在部署阶段，将监视正在运行的应用程序以验证当前部署是否正确或是否需要回滚。

持续交付(CD)：监控

持续交付(CD)：反馈和协作工具

结语

组织必须评估一个整体的持续交付解决方案，该解决方案可以自动化或促进上述这些阶段的自动化。

原文标题：What Is a CI/CD Pipeline?，作者：Jyoti Sahoo

【译稿，合作站点转载请注明原文译者和出处为.com】

相关文章