【51CTO.com快译】持续集成(CI)/持续交付(CD)管道是一系列步骤，其中包括从CI/CD流程开始的所有阶段，并负责创建自动化和无缝的软件交付。而使用CI/CD管道，软件发布工件可以从代码检入阶段到测试、构建、部署和生产阶段一直在管道中前进。这一概念之所以强大，是因为一旦指定了管道，就可以将其部分或全部实现自动化，从而加快了流程，并减少了错误。换句话说，CI/CD管道使组织每天更轻松地自动多次交付软件。
DevOps工程师往往会因为CI/CD中各个阶段的自动化而与CI/CD管道混淆。虽然不同的工具可以使CI/CD中的各个复杂阶段实现自动化，但由于人工干预，CI/CD的整个软件供应链仍然可能被中断。以下将探讨持续集成(CI)/持续交付(CD)流程的各个阶段，以及为什么CI/CD管道对于组织以快速和大规模的方式交付代码至关重要的原因。
CI/CD阶段：了解人员、流程和技术
组织应用程序开发团队通常由开发人员、测试人员/质量保证(QA)工程师、运营工程师和站点可靠性工程师(SRE)或IT运营团队组成。他们紧密合作，将高质量的软件交付到客户手中。持续集成(CI)/持续交付(CD)是两个独立过程的组合：持续集成和持续交付。以下列出了CI/CD管道中的主要步骤。
持续集成(CI)：代码提交
持续集成(CI)是构建软件并完成初始测试的过程。持续交付(CD)是将代码与基础设施相结合的过程，确保完成所有测试并遵循策略，然后将代码部署到预期的环境中。当然，许多组织都有自己的流程，但主要步骤如下所示：
- 人员：开发人员和工程师、数据库管理员(DBA)、基础设施团队。
- 技术：GitHub、Gitlab、SVM、BitBucket。
- 过程：
代码提交阶段也称为版本控制。提交是将开发人员编写的最新更改发送到存储库的操作。开发人员编写的每一个版本的代码都是无限期存储的。在与合作者讨论和审查更改之后，开发人员将编写代码，并在软件需求、功能增强、错误修复或更改请求完成后提交。管理编辑和提交更改的存储库称为源代码管理(SCM工具)。开发人员在提交代码(代码推送请求)后，代码更改将合并到存储在中心存储库(如GitHub)中的基本代码分支中。
持续集成(CI)：静态代码分析
- 人员：开发人员和工程师、数据库管理员(DBA)、基础设施团队、测试人员。
- 技术：GitHub、Gitlab、SVM、BitBucket。
- 过程：
开发人员编写代码并将其推送到存储库后，系统将自动触发以启动下一个代码分析过程。想象一下这样一个步骤：提交的代码可以直接构建，而在构建或交付期间失败。就机器和人力的资源利用率而言，这都是一个成本昂贵的缓慢过程。组织必须检查代码中的静态策略，静态应用程序安全测试(SAST)是一种白盒测试方法，可以使用SonarQube、Veracode、Appscan等SAST工具从内部检查代码，以发现软件缺陷、漏洞和弱点(例如SQL注入等)。这是一个快速检查过程，其中检查代码是否存在语法错误。尽管此阶段缺少检查运行时错误的功能，但该功能将在以后的阶段中执行。
将其他策略检查放入自动管道中可以显著地减少在该过程中发现的错误数量。
持续集成(CI)：构建
- 人员：开发人员和工程师。
- 技术：Jenkins、Bamboo CI、Circle CI、Travis CI、Maven、Azure DevOps。
- 过程：持续集成(CI)过程的目标是进行常规代码提交并不断构建二进制工件。持续集成过程通过检查添加的新模块是否与现有模块配合良好，有助于更快地发现错误。这有助于减少验证新代码更改的时间。生成工具根据用于编写源代码的编程语言来帮助编译和创建可执行文件或程序包(.exe、.dll、.jar等)。在交付期间，还将生成SQL脚本，然后与基础设施配置文件一起对其进行测试。总之，构建阶段就是编译应用程序的阶段。作为构建过程一部分的其他子活动是工件存储、构建验证和单元测试。
构建验证测试(BVT)/烟雾测试和单元测试：
创建构建后立即执行烟雾测试。构建验证测试(BVT)检查所有模块是否正确集成，以及程序的关键功能是否正常运行。测试的目的是放弃严重损坏的应用程序，以使质量保证团队不会浪费时间安装和测试软件应用程序。
在这些检查之后，将单元测试(UT)添加到管道中，以进一步减少生产中的故障。单元测试测试开发人员编写的代码的各个单元或组件，以验证它们是否按预期执行。
工件存储：
一旦准备好构建，数据包就存储在一个称为工件或存储库工具的集中位置或数据库中。每天可能会生成很多构建，并且跟踪所有构建可能会很困难。因此，一旦生成并验证构建，它就被发送到存储库进行存储。存储库工具(如Jfrog Artifactory)用于存储二进制文件，如.rar、.war、.exe、Msi等。在此，测试人员可以通过人工选择，并在测试环境中部署工件以进行测试。
持续集成(CI)：测试阶段
- 人员：测试人员、质量检查工程师。
- 技术：Selenium、Appium、Jmeter、SOAP UI，、Tarantula。
- 过程：发布构建过程后，通过一系列自动测试将验证代码的准确性。这一阶段可帮助避免生产中的错误。根据构建的规模，这种检查可能持续数秒至数小时。对于由多个团队提交和构建代码的大型组织来说，这些检查在并行环境中运行的，以节省宝贵的时间，并尽早将错误通知开发人员。
这些自动化测试由测试人员(或质量保证工程师)设置，他们根据用户案例设置了测试用例和场景。他们执行回归分析和压力测试以检查与预期输出的偏差。测试涉及的活动包括健全性测试、集成测试、压力测试。这是一种非常高级的测试。在这里，可以发现开发人员可能未知的问题。
集成测试：
集成测试是使用诸如Cucumber、Selenium等工具执行的，其中将单个应用程序模块组合并作为一组进行测试，同时评估是否符合指定的功能需求。在集成测试之后，需要有人批准该组中的更新集应该移动到下一阶段，这通常是性能测试。这种核查过程可能很繁琐，但它是整个过程的重要组成部分。在测试过程中出现了一些新的解决办法。
负载平衡和压力测试：
负载平衡和压力测试也使用自动化测试工具(如Selenium、JMeter等)执行，以检查应用程序运行是否稳定，并且在高流量环境下是否良好。由于全面的压力测试是长期运行的，因此通常不会在每次更新上运行这一测试。当要发布主要的新功能时，将对多个更新进行分组，并完成完整性能测试。如果将单个更新移动到下一阶段，则管道可能包括金丝雀测试作为替代。
- 人员：基础设施工程师、站点可靠性工程师(SRE)、运营工程师。
- 技术：Spinnaker、Argo CD、Tekton CD。
- 过程：在测试阶段完成之后，标准的代码准备部署到服务器中，这些代码将与主要应用程序集成。在部署到生产中之前，他们将被部署到测试/暂存或产品团队内部使用的测试环境中。在将构建移动到这些环境之前，构建必须经过两个子库，其名称为Bake和Deploy。这两个阶段都是Spinnaker所固有的。
持续交付(CD)：Bake
Bake是指从源代码中创建一个不可变的映像实例，该实例在生产环境中具有当前配置。这些配置可能是数据库更改和其他基础设施更新之类的内容。Spinnaker可以触发Jenkins来执行这个任务，而有些组织更喜欢使用Packer。
持续交付(CD)：Deploy
Spinnaker自动将Bake的映像传递到Deploy阶段。这是将服务器组设置为部署到集群的位置。与上述测试过程类似，在Deploy阶段执行功能相同的过程，首先转移到测试阶段，然后转移到产品环境，最后进行批准和检查。其整个过程由Spinnaker之类的工具处理。
持续交付(CD)：验证
这也是组织的团队优化整个CI/CD流程的关键位置。因为现在已经进行了大量的测试，所以失败很少见。但是，此时必须尽快解决所有故障，以最大程度地减少对最终客户的影响。团队也应该考虑使流程的这一部分自动化。
使用蓝绿部署、金丝雀分析、滚动更新等策略部署到产品。在部署阶段，将监视正在运行的应用程序以验证当前部署是否正确或是否需要回滚。
持续交付(CD)：监控
- 人员：站点可靠性工程师(SRE)、运营团队。
- 技术：Zabbix、Nagios、Prometheus、Elastic Search、Splunk、Appdynamics、Tivoli。
- 过程：为了使软件发行版具有故障安全性和健壮性，在生产环境中跟踪发行版的运行状况至关重要。应用程序监视工具将跟踪性能指标，例如CPU利用率和发行版延迟。日志分析器将扫描由底层中间件和操作系统产生的大量日志，以识别行为并跟踪问题的根源。如果生产中出现任何问题，将通知利益相关者以确保生产环境的安全性和可靠性。此外，监视阶段可帮助组织收集有关其新软件更改如何为收入贡献的情报，帮助基础设施团队跟踪系统行为趋势并进行容量规划。
持续交付(CD)：反馈和协作工具
- 人员：站点可靠性工程师(SRE)、运营和维护团队。
- 技术：JIRA、ServiceNow、Slack、电子邮件、Hipchat。
- 过程：DevOps团队的目标是更快地持续发布，然后不断减少错误和性能问题。这是通过不时地通过发送电子邮件向开发人员、项目经理提供有关新版本的质量和性能的反馈。通常情况下，反馈系统是整个软件交付过程的一部分。因此，交付中的任何更改都会频繁地登录到系统中，以便交付团队可以对它采取行动。
结语
组织必须评估一个整体的持续交付解决方案，该解决方案可以自动化或促进上述这些阶段的自动化。
原文标题：What Is a CI/CD Pipeline?，作者：Jyoti Sahoo
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
