共计 3843 个字符，预计需要花费 10 分钟才能阅读完成。
CICD 流水线是指一系列自动化的构建、测试和部署步骤，用于将应用程序从开发到生产环境的过程。在 CICD 流水线中，每个步骤都是自动化的，并且在实现后会触发下一个步骤的执行。
CICD 的价值
CICD 流水线能够帮忙团队更快地交付产品，缩小手动谬误，并进步软件品质。通过自动化构建、测试和部署过程，团队能够更快地检测和修复谬误，并更快地将新性能推向市场。
CICD 工具链
通常由 8 个局部组成
源代码治理：用于存储和管理应用程序代码的工具，代码治理是 CICD 工具链的根底，提供了代码的版本控制、合作和治理性能，例如 GitLab、GitHub、Bitbucket 等。
构建工具：将源代码编译成可执行文件或软件包的工具，例如 Maven、Gradle、Webpack 等。
测试工具：自动化执行测试用例并生成测试报告的工具，例如 JUnit、Selenium 等。
镜像构建：构建和治理容器镜像的工具，例如 Docker、Kaniko 等。
制品治理：寄存业务镜像的仓库，在利用部署时须要拉取。例如：Harbor、Registry、云厂商公有仓库等。
监控工具：用于监控流水线运行过程中的状态，如资源占用、负载状况，为流水线性能优化提供数据根底。例如：Prometheus、Grafana、EFK。
部署工具：用于将代码构建实现的制品公布到指标环境中，例如 Jenkins、GitLab CI、Travis CI 等。
自动化工具：用于代替扩散脚本执行各种自动化类操作，使执行流程更加清晰有序。例如：Ansible、Puppet 等。
CICD 的演进历史
从 CI/CD 倒退历史来说能够大抵分为以下几个阶段：
1、人工公布阶段：开发或运维人员通常须要手动构建和部署应用程序。这种办法十分耗时且容易出错，因为它须要手动执行多个步骤，并且容易脱漏某些步骤。
2、脚本公布阶段：咱们称之为“半自动化”阶段，人工手动操作的步骤重大困扰了开发和运维人员，过于耗时耗力以及手动执行具备肯定的不可靠性存在。于是开始寻求用脚本来代替一部分人工操作，如 shell、python 脚本，但长此以往仍然耗费开发运维人员大量工夫老本，公布不够标准仍然在继续
3、自动化公布阶段： 为了进一步标准公布流程，躲避人为操作所带来的危险，进步公布效率，少数公司开始构建本人的 CI/CD 公布零碎，这样的益处是无需人工染指，脚本内容不易被篡改。
4、智能化公布阶段：人工智能大数据时代，一些优良的公司曾经开启智能化 CI/CD 零碎，通过引入数据分析、智能预测伎俩，进一步优化公布流程、进步公布效率。
在这四个阶段中，每个阶段都是在前一个阶段的根底上倒退而来的，并且每个阶段都能够提供更高效、更牢靠和更平安的软件交付过程。
进入自动化时代当前，CI/CD 效率虽失去了大幅晋升，但架构的保护过程中仍然会遇到各种各样的问题须要解决，上面我将介绍大多数企业在整个保护过程中可能会遇到的流水线问题以及优化计划。
企业 CICD 流水线可能会遇到的问题
Jenkins 当属业内继续集成老大哥，有着丰盛的插件，实用于大型流水线计划的建设以及大多数场景，受到不少企业用户的追捧，所以本文次要基于 Jenkins 建设的流水线计划为外围从运维角度来讲述可能存在的瓶颈及优化点。
1、Jenkins Master 与 Worker 共用宿主机带来的失联问题
有些企业为了不便部署以及尽可能的节俭服务器资源抉择 Jenkins Master 与 Worker 共用宿主机，当流水线数量较少或 stage 消耗资源较少时无显著感知。随着我的项目越来越多，流水线数量的也随之增多，这种架构开始呈现瓶颈，多个 Job 并行构建占用资源较多导致系统负载增高，Master 与 Worker 之间的通信也会受到烦扰，重连超时导致 Job 最终失败。
倡议优化计划：
Jenkins Master 与 Worker 拆散部署，能够容许 Worker 有短暂的高负载稳定，不至于拖垮所有流水线
Jenkins Master 优化连接时间相干参数
Worker 主机负载高优化
kubelet 配置系统资源预留，保障系统过程的稳定性
kubelet 限度 maxPods 来硬性管制并行构建数，超出限度会进入队列期待
Jenkinsfile 中 PodTemplate 局部容器减少 resourceLimitCpu 参数限度最大应用 CPU 额度
这一点是避免某个 Pod 无限度应用资源导致卡死
2、代码依赖缓存拉取的问题
默认走官网源拉取依赖多多少少会遇到网络稳定性问题，导致 Job 的构建成功率升高，影响产品交付效率。
举荐优化计划：
maven
举荐 nexus 私服
npm
应用淘宝源
应用阿里云公有仓库，能够无效解决公有包的权限问题
缓存目录映射宿主机实现长久化，缩小每次拉取的网络耗费
3、Docker 构建业务镜像体积大，耗时长
对于小型我的项目优化的必要性不大，大型项目的弊病较显著。
倡议优化计划：
养成良好编写 Dockerfile 的习惯，合并多 RUN 步骤，缩小 layer 层级
留神 ADD/COPY 的用法，禁止应用先 COPY 后解压操作，对于大型碎文件目录倡议归档为 tar 包后应用 ADD 上传（大量碎文件会影响性能）
Dockerfile 应用多阶段构建，最终镜像打包只援用构建产物
应用 .dockerignore 来疏忽 docker build 时不须要加载的文件或目录，节俭构建工夫
根底镜像的选型很重要，依据所属我的项目依赖来确定满足需要最小根底镜像
4、镜像推送拉取慢
蕴含运行时镜像、打包根底镜像、业务镜像等
倡议优化计划：
无论是公共镜像还是公有镜像尽量都应用公有仓库走内网传输，防止应用官网仓库。
常见公有仓库：
阿里云云效公有仓库
AWS ECR
Harbor
Registry
等…
流水线宿主机本地长期保留罕用镜像
5、代码打 Tag 后 Jenkins 拉取版本有误
开发打 Tag 后触发 Jenkins 流水线，流水线拜访仓储获取 Tag 代码，但偶然会遇到流水线获取到的 Tag 与预期不符，引发网站拜访报错
倡议优化计划：
这可能是一个 bug，偶尔呈现
能够应用独立部署 webhook 服务来被动触发 Jenkins 的形式彻底解决
6、Jenkinsfile 文件多，治理难
个别 Jenkinsfile、Dockerfile 等文件都会存在在业务仓储内，如果企业仓储较多，而 Jenkinsfile 又不能共用的状况下就会面临对立治理的问题。
倡议优化计划：
简化版
只须要将各仓储相干文件转移至对立仓储，Jenkins 先拉取治理仓储，再在 stage 中拉取业务代码来实现，不用合并所有 Jenkins 的内容
劣势：
不依赖额定插件，属于轻量型
与业务解耦
劣势：
对立批改较耗时
简单版（举荐，但不倡议代码逻辑过于复杂化）
基于 Global Pipeline Libraries 插件做代码整合，通用局部提取到独自文件复用
官网文档：https://www.jenkins.io/doc/book/pipeline/shared-libraries/
劣势：
复用局部一处批改失效全局，缩小代码量
节俭肯定的工夫老本
劣势：
复用局部的批改须要谨慎，尽量应用判断
须要肯定的 Groovy 代码根底
7、多条流水线并行构建的问题
当 Worker 节点为固定时，资源少会导致流水线排队，整体效率低，资源多能够满足高峰期的并行构建需要，但闲暇工夫又会节约老本。
倡议优化计划：
应用云厂商的 Serverless 产品按需付费，只对 Pod 资源限度
应用云厂商的 Autoscheduling 性能来实现主机级别的扩缩容（须要依赖云厂商 K8S 产品）
编写工具依据业务理论场景实现动静调整 Worker 节点的配置大小
8、流水线拥挤问题，与第 7 条不抵触
上一条提到的并行构建指的是失常的构建需要，是建设在流水线拥挤优化之后的论断之上，如：单个 CD Job 的并行构建显然是不合理的，却须要多消耗几倍的资源。
倡议优化计划：
CD 流水线开启「不容许并行构建」以及「Abort previous builds」，每个 Job 只保留最新的构建过程
CI 流水线须要测试每个 PR 的代码，所以能够开启「不容许并行构建」，无需开启「Abort previous builds」
当系统资源较短缺时，CI 能够敞开「不容许并行构建」，但须要留神的是共用缓存映射所带来的潜在抵触问题
主机负载高可能导致 Job Pod 运行状态失联，未及时被 K8S 回收，倡议设置定时检测脚本来按需清理
9、Jenkins Master 磁盘占用率高、运行迟缓卡顿
大略有几方面起因：构建日志保留过多、服务日志未定时清理、主机资源匮乏、JVM 限度参数不合理等。
倡议优化计划：
按构建天数或个数进行日志保留
服务日志设置定时清理或调整日志级别
依据监控判断资源正当需要
JVM 参数配置调整测试，得出正当值
对于分支构建的 Job 敞开 Tag 拉取，以及开启浅克隆
10、Jenkins 批量新增、批改 Job 信息麻烦
大量的流水线间接通过界面编辑即可，几十上百条甚至更多当前批改配置会很麻烦。
倡议优化计划：
应用 Python、Go 等语言编写对立管理工具
合并可能通用的流水线，如：单条流水线公布多个我的项目，是一对多的关系
总结：
以上分享的是较常见可能影响流水线交付效率的因素以及倡议解决方案，PingCode DevOps 团队充沛借鉴了以上局部计划进行专项优化，流水线交付效率失去了质的晋升。CICD 流水线优化是一个经久不衰的话题，我置信流水线的高效稳固和便于管理是每个企业独特谋求的指标，实现模式能够是多种多样，适宜本身场景的计划就是好的计划，现阶段咱们仍然在为进一步优化流水线做致力，谋求极致，没有最好，只有更好！
