CI/CD流程pipeline, 2022-07-27

(2022.07.27 Wed)
在软件工程中，CI/CD或CICD是持续整合(Continuous Integration)和持续交付(Continuous Delivery)或持续部署(Continuous Deployment)的联合实践。CI/CD通过对构建(building)、测试和部署的自动化，在开发和运营(operations)之间的建起了桥梁。CI/CD服务编译开发者提供的增量代码更新，并将其连接和打包成可交付的软件服务。自动化测试验证软件的功能性，而自动化部署将软件送到终端使用者面前。CI/CD的目的是在开发早期发现瑕疵、提升生产力和提供更快的发布循环。在传统的软件开发流程中，软件更新被整合成一个大的批处理(one large batch)，并部署成新版本；而现代DevOps实践中，持续开发、测试、整合、部署和检测贯穿在开发周期的始终。CI/CD流程形成了现代DevOps操作的主要力量。

CI持续集成

传统软件开发流程中，多个开发者产生代码，并在发布前将他们的工作整合在一起。如果代码中出现问题或整合时产生问题，将不得不通过长时间的测试才可解决，之后才能正常发布，常常导致了软件品质问题和更新周期过慢。

持续集成皆在通过敏捷开发流程解决上面问题。持续集成指开发者对代码的每个修改都被迅速整合进软件的主分支(main branch)。CI系统自动运行测试以找出代码的问题，开发者得到了快速反馈并可尽快解决问题。一个新的功能只有在整合进主分支、与其他代码修改整合在一起，才被认为开发完成。

技术上，团队通过部署一个构建服务器(build server)来实现CI，该服务器可以承接代码修改、使用多种整合工具实现自动化测试、整合代码修改到主分支，并创建软件的新版本。

CI戏剧性的提升了软件开发的品质和速度。团队可以迅速的创建新的功能。

CD持续交付continuous delivery

部署新的软件发布曾经是相当有风险和复杂的事情。新的发布被测试之后，运营团队将其部署在生产环境。部署的过程可能会持续数小时，或数周，这取决于软件的规模、checklist和手动步骤以及对操作人员的专业要求。如果部署经常失败，会需要迂回方案(workarounds)或需要开发者的紧急支援。

传统的部署过程有诸多挑战，如团队压力大、组织承担过高风险、在生产环境中引入了bugs等。

持续交付CD旨在用自动化的方式解决这些挑战。在CD方法中，软件被尽可能频繁的打包和部署到生产环境中。CD的核心原则是对代码的每一次修改被部署到生产环境中不会花费太多功夫。

在CI系统整合代码变更并穿件系统的新版本之后，CD系统将新软件版本打包、部署在测试环境、自动化地测试运行效果，并将其推送到生产环境。最后的推送步骤由人工验证，但并不需要过多人工的工作。

实现CD需要整个软件开发周期的自动化，包括构建、测试、环境设置和软件开发。所有的artifacts都在代码仓库中，并应当针对创建和更新环境设置自动化机制。

CD流程带来明显收益 - 允许开发团队立即为客户提供价值并创建真正的敏捷开发流程。

注意持续交付和持续部署都是CD，他们的区别在于开发者可以持续交付，但运营团队可以有选择性的部署或按批次部署。

CI/CD基本流程

CI/CD Pipeline 1 CI/CD pipeline 2

CI/CD流程(CI/CD pipeline)是一个框架，该框架强调敏捷DevOps团队的迭代化的、可靠的代码交付。该框架中的工作流包括持续集成、测试、交付、部署。该流程将这些步骤安排/整合成一个开发高质量软件的标准流程。

测试和构建的自动化是CI/CD pipeline的重要一环，这两个步骤可以帮助开发者在SDLC的早期确定代码问题并解决，之后可以更容易的将代码推送到不同的环境中并将其推送到生产环境。自动化测试包括性能测试(压力测试)、安全测试(静态安全测试)等。

除了测试和品控，自动化也应用于CI/CD全程的各个阶段，可帮助开发者提供稳定的软件，使发布流程更加快捷和安全。
(2022.07.28 Thur)

精简流程

developer提交代码到某branch-->触发Jenkins构建-->构建同时做质量检查-->检查通过则developer提pull request-->对request做检查-->构建，测试成功则生成docker镜像-->部署

CI -
当开发人员将代码提交到其相关branch时，将触发CI流程。与Git repo关联的Git webhook将触发Jenkins集群中的构建过程。Jenkins管道用于驱动构建过程，并且存在与构建过程相关的质量关卡检查。质量门检查应基于对共同开发部门的最低要求。在上下文中，质量门检查可以验证：

• 构建是否成功
• 单元测试已通过
• 没有违反代码风格的行为
• 新代码的代码覆盖率超过80％
• Sonar扫描未报告任何漏洞或代码气味。

CD 持续交付 -
如果质量门已经通过，则开发人员可以提交其拉取请求(pull request)。集成管理器会将代码merge到通用开发分支。这将启动通用开发分支上的构建过程，如果成功，将继续构建docker映像。

理想情况下，所有测试都应作为集成过程的一部分执行，但实际上由于测试执行时间的原因，这效率很低。因此，我们将其设计为一个称为“连续测试”的过夜时段。

CT 持续测试 -

这是一个通宵的过程，其中会在软件的最新成功构建上执行功能测试，安全扫描和性能测试等测试。在执行测试之前，将根据最新的docker镜像将新容器部署在连续测试环境中。连接到Kubernetes集群的永久卷将作为测试的前提条件被还原。请注意，所有这些活动都是计划的并且是完全自动化的。

第二天早上在每日站立会议之前检查测试报告。任何脚本问题将由质量保证团队解决，而任何代码问题将由开发团队解决。CT故障被认为是优先考虑的问题，并将在最早的情况下得到解决。

受控部署 -

由于大多数艰苦的工作已经在前面的三个步骤中完成，因此简化了部署。成功的CT周期是唯一的资格标准，可以在任何时候进行发布。发行脚本将

• 用相关版本号标记Docker映像
• 用版本号标记源存储库

现在，可以将发布版本部署在发布管道中的其他环境中。最终，将发行版推广到生产将是业务决策。docker + kubernetes设置将简化部署过程，并且结果在所有环境中都是可预测的。

具体流程

CI - 代码提交 commit
代码提交阶段也称为版本控制。提交是将开发人员编写的最新代码变更发送到代码存储库的操作。开发人员编写的代码的每个版本都被无限期地存储。在与合作者讨论和审查变更之后，开发人员将编写代码，并在软件需求、特性增强、bug修复或变更请求完成后提交。管理编辑和提交变更的存储库称为源代码管理工具（配置管理工具）。在开发人员提交代码（代码推送请求）后，代码更改被合并到主线代码分支中，这些主线代码分支存储在GitHub这样的中央存储库中。

CI - 代码静态检测 static check
开发人员编写代码并将其推送到存储库后，系统将自动触发以启动下一个代码分析过程。开发过程中存在这种情况：提交的代码可以构建成功，但在部署期间构建失败。无论从机器还是人力资源的利用率而言，这都是一个缓慢而昂贵的过程。因此必须检查代码中的静态策略。SAST（静态应用程序安全性测试）：SAST是一种白盒测试方法，可以使用SonarQube，Veracode，Appscan等SAST工具从内部检查代码，以发现软件缺陷，漏洞和弱点（例如SQL注入等）。这是一个快速检查过程，其中检查代码是否存在语法错误。尽管此阶段缺少检查运行时错误的功能，但该功能将在以后的阶段中执行。

将额外的策略检查加入自动化流水线中可以显著减少流程中稍后发现的错误数量。

CI - 构建 build
由开发工程师完成。
技术：Jenkins，Bamboo CI，Circle CI，Travis CI，Maven，Azure DevOps
流程：持续集成过程的目标是提交的代码持续构建为二进制文件或构建产物。通过持续集成来检查添加的新模块是否与现有模块兼容，不仅有助于更快地发现bug，还有助于减少验证新代码更改的时间。构建工具可以根据几乎所有编程语言的源代码创建可执行文件或包（.exe，.dll，.jar等）。在构建过程中，还可以生成SQL脚本，配合基础设施配置文件一起进行测试。简而言之，构建阶段就是编译应用程序的阶段。Artifactory存储、构建验证测试和单元测试也可以作为构建过程的一部分。
构建验证测试（BVT）/冒烟测试/单元测试：

创建构建后立即执行冒烟测试。BVT将检查所有模块是否正确集成，以及程序的关键功能是否正常运行。这样做的目的是拒绝严重损坏的应用程序，以使QA团队不会在安装和测试软件应用程序步骤浪费时间。

在完成这些检查后，将向流水线中执行UT（单元测试），以进一步减少生产中的故障。单元测试可验证开发人员编写的单个单元或组件是否按预期执行。

构建产物存储：

一旦构建就绪，程序包就会存储在称为Artifactory或Repository工具的中央数据库。随着每天构建量的增加，跟踪所有构建产物也会变得愈加困难。因此，一旦生成并验证了构建产物，就将其发送到存储库进行存储管理。诸如Jfrog Artifactory之类的存储库工具可用于存储诸如.rar，.war，.exe，Msi等之类的二进制文件。测试人员可以从此处手动进行选择，并在测试环境中部署构建产物以进行测试。

CI - 测试

参与者：测试人员、QA
技术：Selenium，Appium，Jmeter，SOAP UI，Tarantula
过程：发布构建过程后的一系列自动测试将验证代码的准确性。此阶段可帮助避免生产中的错误。根据构建的大小，此检查可能持续数秒至数小时。对于由多个团队提交和构建代码的大型组织，这些检查在并行环境中运行，以节省宝贵的时间并尽早将错误通知开发人员。
测试人员（或称为QA工程师）基于用户描述的测试用例和场景设置自动化测试用例。他们执行回归分析、压力测试来检查与预期输出的偏差。测试中涉及的活动有完整性测试、集成测试、压力测试。这是一个高层次测试方法。在这个阶段，可以发现开发人员忽视的某些代码问题。

集成测试：

集成测试是使用Cucumber、Selenium等工具执行的，在这些工具中，单个应用程序模块被组合起来并作为一组进行测试，同时评估其是否符合指定的功能需求。在集成测试之后，需要有人批准该组中的更新集应该移到下一个阶段，这通常是性能测试。这个验证过程可能很麻烦，但它是整个过程的一个重要部分。验证这个过程业界有很多优秀的方案。

性能和压力测试：

Selenium、JMeter等自动化测试工具也可执行性能和压力测试，以检查应用程序在面对高负载时是否稳定和性能良好。该测试流程通常不会在每个更新提交上运行，因为完整的压力测试是长期运行的。当发布主要的新功能时，将对多个更新进行分组，并完成完整的性能测试。在单个更新被转移到下一阶段的情况下，流水线可能将金丝雀测试加入作为可选。

CD - 持续交付
参与者：站点可靠性工程师（SRE）、运营和维护团队。
技术：JIRA、ServiceNow、Slack、电子邮件、Hipchat。
过程：DevOps团队的目标是更快地持续发布，然后不断减少错误和性能问题。这是通过不时地通过发送电子邮件向开发人员、项目经理提供有关新版本的质量和性能的反馈。通常情况下，反馈系统是整个软件交付过程的一部分。因此，交付中的任何更改都会频繁地录入系统，以便交付团队可以对它采取行动。

CD - 持续部署
参与者：基础架构工程师，SRE，运维工程师
技术：Spinnaker，Argo CD，Tekton CD
过程：在测试阶段完成之后，可以部署到服务器的标准代码准备就绪。在部署到生产中之前，它们将被部署到产品团队内部使用的测试环境或beta环境。在将构建移至这些环境之前，构建必须经过Bake和Deploy的子阶段。这两个阶段都是Spinnaker所支持存在的。
CD：Bake

Baking是指在生产时使用当前配置从源代码创建不可变的镜像实例。这些配置可能是数据库更改和其他基础结构更新之类的事情。Spinnaker可以触发Jenkins执行此任务，并且某些组织更喜欢使用Packer。

CD：部署

Spinnaker自动将已bake的镜像发送到部署阶段。这是将服务器组设置为部署到集群的位置。与上述测试过程类似，在部署阶段将执行功能相同的过程。首先将部署移至测试阶段，然后最终移至生产环境，以进行批准和检查。这个处理过程可以由Spinnaker等工具支持。

CD：验证

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

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

CD：监控

参与者：站点可靠性工程师（SRE）、运营团队
技术：Zabbix、Nagios、Prometheus、Elastic Search、Splunk、Appdynamics、Tivoli
过程：为了使软件发行版具有故障安全性和健壮性，在生产环境中跟踪发行版的运行状况至关重要。应用程序监视工具将跟踪性能指标，例如CPU利用率和发行版延迟。日志分析器将扫描由底层中间件和操作系统产生的大量日志，以识别行为并跟踪问题的根源。如果生产中出现任何问题，将通知利益相关者以确保生产环境的安全性和可靠性。此外，监视阶段可帮助组织收集有关其新软件更改如何为收入贡献的情报，帮助基础设施团队跟踪系统行为趋势并进行容量规划。

CI/CD常用工具

• Jenkins以主从模式作为构建服务器
• Jenkins Pipelines推动CI流程
• Git Hooks通过代码提交触发构建
• SonarQube作为代码质量工具，或静态检测
• 用于自动化功能测试的机器人框架，Selenium等
• JMeter性能测试
• OWASP ZAP用于安全扫描
• docker和k8s用于部署

(2022.07.28 Thur)

CI/CD流程有哪些挑战

环境限制

开发和测试团队往往只能接入非常优先的资源，或者共享环境用于测试代码。共享环境对CD工作流来说是个挑战。在大型项目中，多个团队可能同时向同一个环境/代码库提交代码的情况。同样的，多个测试也可能并行进行，而不同的提交和测试可能需要不同的环境配置。如果他们恰好基于同一个基础架构(infrastructure)，情况就会更糟，配置不恰当的环境可能导致测试和部署失败，并拖慢CI/CD的进程。

版本控制问题

一般的CI/CD流程性需要多个源、分量(component)和进程。一旦一条pipeline启动运行，必须提供稳定的版本运行进程。运行期间的版本变动会拖累(derail)整个pipeline并放缓部署进程。

DevOps团队通常花很久维护版本控制，甚至有的团队会分配版本控制管理给特定的部门和职位。一个最糟糕的场景是自动化的更新开启并迫使更新作用于一个关键进程。除了打断进程，新版本还会导致当前CI/CD流程的兼容性问题。面对这类问题，团队不得不重构整个CI/CD部署流程来支持新版。

以现有工作流的整合

将新的CI/CD pipeline与已经存在的工作流整合相当困难。大型的遗产项目问题尤其严重因为对其中一个工作流的简单修改可能迫使其他工作都做出修改，更可能导致整体重构。

在当前项目中实现CI/CD需要精密计划，广泛专业知识，和恰当的工具。计划不充分的实现可能导致严重延时并降低服务品质。

跨团队沟通

CI/CD pipeline一般来说需要投入大量劳动力，常涉及多个团队。跨团队沟通往往是CI/CD流程的最大障碍。

案例记录

类CI/CD案例1

在线交易平台上有大量的rule用于预测和阻止欺诈交易或潜在的欺诈交易，通过不同的rule来实现。一旦交易的特征满足rule规定的条件，相应的rule就会工作，对交易做出各类预设的动作。rule由风险分析师提交，保存在IBM Decision Center系统上，DC是生产环境，交易都要经由DC处理，以决定是否完成交易。DC上的rule代码来自业务代码的git repo(gr)的main branch。

rule需要根据业务需求创建、更新或删除。当风险分析师需要对rule做调整，到gr的main branch上提pull request。运行团队检查pull request中要修改的内容是否符合rule的规范，也就是static check。检测通过，则在pull request页面生成一个临时repo。临时repo被clone到本地之后，经由Eclipse的定制版打开，再由Eclipse连接到DC的测试环境，并上传。到DC的测试环境查看修改是否成功上传，如果成功，则rule的测试已经通过。

此时可以对pull request做merge操作，使其成为main branch的一部分。main branch的内容定期从DC的生产环境pull，保持生产环境的代码为最新。

公司A的CI/CD流程

(2022.12.03 Sat)
某后端服务A用于部署到生产环境，对前端提供服务。开发者向A添加新feature的流程如下：

• 从服务A的main branch创建新branch，称之为feature-a
• 将feature-a clone到local
• 在local的feature-a中进行开发
• 在local的feature-a中完成unit test
• 将local的feature-a push到remote feature-a
• remote线上运行提前构建的build, test等流程
• build, test等流程完成，开发者向main branch提出pull request(PR)
• 相关开发者收到PR申请，review即将添加到main branch的代码
• 相关开发者approve/reject新代码到main branch中

在该过程中有如下环节需要注意

1. 在开发者创建feature-a之后和提PR之前，main branch可能已经被其他开发者修改，如图所示
   code conflicts

如果双方同时修改同一个地方，会造成code conflicts。这种情况下，在执行PR之前需要对feature-a的代码进行修改，即PR从main到feature-a，执行修改，重新提PR。具体流程参考本文所在文集的代码冲突修改一文。
或考虑使用pre-commit工具。

2. 在push代码到remote之后执行的build和test，可通过Jenkins或Azure pipeline实现。

Refenrece

1 wikipedia - CI/CD pipeline
2 codefresh点io - what is a CI/CD pipeline a complete guide
3 知乎 - 6张图带你搞懂CI/CD
4 51CTO - 实施有效有价值的CI / CD流水线实践分享