共计 3381 个字符，预计需要花费 9 分钟才能阅读完成。
从 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 继续集成
继续集成 (CI) 是构建软件并实现初始测试的过程。继续部署 (CD) 是将代码与基础设施联合起来的过程，确保实现所有测试并遵循策略，而后将代码部署到预期的环境中。当然，许多公司都有本人的流程，但次要步骤如下。
CI：代码提交
人员：开发人员和工程师、数据库管理员（DBA）、基础架构团队
技术：GitHub、Gitlab、BitBucket
过程：代码提交阶段也称为版本控制。提交是将开发人员编写的最新更改发送到存储库的操作。开发人员编写的代码的每个版本都被无限期地存储。在与合作者探讨和审查变更之后，开发人员将编写代码，并在软件需要、性能加强、bug 修复或变更申请实现后提交。治理编辑和提交变更的存储库被称为源代码治理（SCM 工具）。在开发人员提交代码（代码推送申请）后，代码更改被合并到存储在地方存储库（如 GitHub）中的根本代码分支中。
CI：动态代码剖析
人员：开发人员和工程师、数据库管理员（DBA）、基础设施团队、测试人员
技术：GitHub、Gitlab、BitBucket
过程：一旦开发人员编写了代码并将其推送到存储库，零碎就会主动触发，开始下一个代码剖析过程。设想一下这样一个步骤：提交的代码间接进行构建，但在构建或部署过程中失败了。就资源利用率而言，无论是机器还是人力，这都是一个迟缓而低廉的过程。必须查看代码的动态策略。SAST（Static Application Security Test）：SAST 是一种白盒测试方法，应用 SonarQube、Veracode、Appscan 等 SAST 工具从外部查看代码，以发现软件缺陷、破绽和弱点（如 SQL 注入等）。这是一个疾速查看过程，查看代码是否有语法错误。尽管此阶段短少查看运行时谬误的性能，但这将在稍后的阶段执行。
将附加的策略查看放到自动化管道中能够显著缩小稍后在该过程中发现的谬误数。
CI：build
人员：开发人员和工程师
技术：Jenkins,、Bamboo CI、Circle CI、Travis CI、Maven、Azure DevOps
过程：继续集成流程的指标是承受惯例的代码提交，并继续构建二进制工件。继续集成过程通过查看增加的新模块是否与现有模块配合良好，有助于更快地发现 bug。这有助于缩小验证新代码更改的工夫。构建工具有助于编译和创立可执行文件或包（.exe、。dll，.jar 等）取决于用于编写源代码的编程语言。在构建过程中，还会生成 SQL 脚本，而后与基础设施配置文件一起测试。简而言之，构建阶段是编译应用程序的阶段。构建过程的其余子流动包含工件存储、构建验证和单元测试。
CI：测试阶段
人员：测试人员和 QA 工程师
技术：Selenium、Appium、Jmeter、SOAP UI、Tarantula
过程：公布一个构建过程一系列自动化测试来验证代码的准确性。这一阶段有助于避免谬误达到产品。依据构建的大小，此查看能够继续数秒到数小时。对于由多个团队提交和构建代码的大型组织，这些查看将在并行环境中运行，以节俭贵重的工夫并尽早将 Bug 告诉给开发人员。
这些自动化测试是由测试人员（或者称为 QA 工程师）建设的，他们曾经依据用户故事建设了测试用例和场景。他们进行回归剖析，压力测试，以查看与预期产出的偏差。测试中波及的流动有健全性测试、集成测试和压力测试。这是一个十分先进的测试程度。在这里会发现开发代码的开发人员可能不晓得的问题。
集成测试：
集成测试是应用 Cucumber、Selenium 等工具来执行的，其中各个利用程序模块作为一个组进行组合和测试，同时评估是否合乎指定的性能需要。在集成测试之后，须要有人批准将该组中的更新集挪动到下一阶段，这通常是性能测试。这个验证过程可能很麻烦，但它是整个过程的重要组成部分。核查过程中呈现了一些新的解决办法。
负载和压力测试：
负载平衡和压力测试也应用自动化测试工具（如 Selenium、JMeter 等）来执行，以查看应用程序在高流量环境下是否稳固和性能良好。此测试通常不会在每个更新上运行，因为残缺的压力测试是长期运行的。在公布次要的新性能时，将对多个更新进行分组，并实现残缺的性能测试。在单个更新被转移到下一个阶段的状况下，管道可能包含金丝雀测试作为代替计划。
继续部署：bake 和部署
人员：基础设施工程师、现场可靠性工程师（SRE）、运维工程师
技术：Spinnaker、Argo CD、Tekton CD
过程：测试阶段实现后，革除了规范的代码就能够部署到服务器中，在那里它们将与主应用程序集成。在部署到生产环境之前，它们将被部署到产品团队外部应用的测试 / 暂存或 beta 环境中。在将构建挪动到这些环境之前，构建必须通过两个子阶段 Bake 和 Deploy。这两个阶段都是 Spinnaker 固有的。
CD：Bake
Bake 是指从源代码中创立一个不可变的映像实例，该实例在生产环境中具备以后配置。这些配置可能是数据库更改和其余基础设施更新之类的内容。Spinnaker 能够触发 Jenkins 来执行这个工作，有些组织更喜爱应用 Packer。
CD：部署
Spinnaker 将主动将烘焙的映像传递到部署阶段。这是将服务器组设置为部署到集群的地位。与上述测试过程相似，在部署阶段执行性能雷同的过程。部署首先转移到测试、阶段，最初转移到生产环境，而后进行批准和查看。整个过程由 Spinnaker 之类的工具解决。
CD：验证
这也是团队优化整个 CI/CD 流程的关键所在。因为当初曾经进行了很多测试，所以失败应该很少。但此时的任何故障都须要尽快解决，以便将对最终客户的影响降到最低。团队也应该思考自动化这部分流程。
部署到生产环境是应用部署策略（如蓝绿部署、金丝雀剖析、滚动更新等）执行的。在部署阶段，将监督正在运行的应用程序，以验证以后部署是否正确或是否须要回滚。
CD：监控
人员：SRE，运维团队
技术：Zabbix、Nagios、Prometheus、Elastic Search、Splunk、Appdynamics、Tivoli
过程：要使一个软件发行版具备故障安全性和健壮性，在生产环境中跟踪发行版的运行状况是至关重要的。应用程序监控工具将跟踪 CPU 利用率和公布提早等性能指标。日志分析器将扫描底层中间件和操作系统产生的日志流，以辨认行为并跟踪问题的起源。在生产过程中呈现任何问题时，都会告诉相干人员，以确保生产环境的安全性和可靠性。此外，监督阶段帮忙企业收集无关新软件更改如何为支出做出奉献的信息，并帮忙基础架构团队跟踪零碎行为趋势和进行容量布局。
继续部署：反馈和合作工具
人员：SRE、Ops 和保护团队
技术：禅道、ServiceNow、Slack、Email、Hipchat
DevOps 团队的指标是更迅速、继续地公布，而后一直缩小谬误和性能问题。这是通过 slack 或电子邮件频繁地向开发人员和项目经理反馈新版本的品质和性能，并在 ITSM 工具中及时进步票价来实现的。通常，反馈系统是整个软件交付过程的一部分；因而交付过程中的任何更改都会频繁地记录到零碎中，以便交付团队能够对其采取行动。
企业必须评估一个整体的继续交付解决方案，它能够自动化或促成上述阶段的自动化。