CI/CD全流程体系

CI/CD（持续集成/持续交付）是一种软件开发实践，旨在通过自动化手段频繁、可靠地交付软件。

亿童公司CI/CD体系技术栈

组件	核心职能	关键点
GitLab	源码版本控制	配置保护分支和 Code Review 机制。
Jenkins	流程编排	使用 Pipeline as Code (Jenkinsfile) 进行管理。
Nexus	私服仓库	减少外网带宽消耗，缓存依赖。
ACR + ACK	容器化部署	实现生产环境的高可用、自动扩缩容。
OSS + CDN	动静分离	极大地优化了 Web 应用的响应性能。
钉钉机器人Webhook	构建部署状态同步、结果反馈与运维告警	实时同步构建部署全流程状态（构建部署确认及执行结果），精准推送结果通知与故障告警，实现交付闭环与运维快速响应。

一、核心总述：一个闭环、五个阶段的CI/CD体系

CI/CD是一套完整的研发交付闭环体系，核心是通过全流程自动化，实现代码从提交到线上部署的标准化、可追溯、低风险交付，彻底打通研发、测试、运维的壁垒。将其可拆解为「一个完整交付闭环 + 五个核心执行阶段」，覆盖从代码提交到线上监控反馈的全生命周期，每个阶段都有明确的目标、标准化动作和风险控制机制。

二、CI/CD全流程五阶段详解

第一阶段：代码提交与流水线触发（Trigger）

核心目标：建立代码提交与自动化流程的联动机制，实现流水线启动的标准化、全团队可感知。

1. 规范代码提交：开发者在本地完成编码与自测后，遵循团队分支管理规范，将代码推送到GitLab对应的feature/develop分支；
2. 自动化触发流水线：通过GitLab预设的Webhook，在代码推送事件触发时，自动向Jenkins发送HTTP POST请求，携带分支、提交人、提交ID等核心参数，无需人工干预启动流水线；
3. 流水线状态同步：通过钉钉机器人向研发群推送实时通知，告知「项目A - 分支B 已触发流水线，开始执行」，让全团队即时感知构建状态，避免流程黑盒。

第二阶段：持续集成与质量门禁（CI）

核心目标：完成代码的自动化构建与质量校验，把代码缺陷、安全风险拦截在研发阶段，产出合格的构建产物。

1. 源码拉取：Jenkins根据Webhook传递的参数，从GitLab拉取对应分支、对应提交版本的代码，确保构建环境与提交代码完全一致；
2. 依赖管理与构建：执行Maven/Gradle构建命令，优先从企业私有Nexus仓库拉取内部组件和第三方依赖缓存，既解决了外网依赖不稳定的问题，提升编译速度，也实现了内部私有组件的统一管控；
3. 质量门禁校验：自动化执行JUnit单元测试，同时通过SonarQube完成代码质量扫描（包括代码规范、漏洞、重复率、测试覆盖率等指标），设置硬性门禁规则，不达标则直接中断流水线，避免问题代码进入下一环节；
4. 构建产物打包：完成所有校验后，生成无状态的可执行二进制文件（如app.jar），作为后续容器化的核心产物。

第三阶段：容器化与制品分发（CD-Artifacts）

核心目标：将构建产物封装为标准化、可移植、可追溯的运行镜像，完成交付制品的统一管理与分发。

1. 标准化镜像构建：Jenkins调用宿主机Docker引擎，基于项目内预置的Dockerfile，将上一阶段生成的JAR包封装为Docker镜像，实现运行环境的标准化，解决「本地能跑、线上不能跑」的环境差异问题；
2. 镜像推送与版本管控：将构建完成的镜像推送到阿里云ACR私有容器镜像仓库，镜像Tag采用「时间戳-Git提交短版本号」的规范（例：v20260227-a1b2c3d），既保证每个镜像都可追溯到对应的代码提交记录，也为后续版本回滚提供了支撑；
3. 环境资源清理：流水线执行完成后，Jenkins自动清理本次构建产生的本地虚悬镜像、临时构建文件，避免磁盘空间持续占用，保障构建节点的稳定运行。

第四阶段：自动化部署与流量切换（CD-Deployment）

核心目标：将标准化镜像安全、平滑地部署到生产环境，实现服务无感知更新、零停机部署。

1. 集群配置更新：Jenkins通过加密存储的kubeconfig凭证，执行kubectl/Helm命令，更新阿里云ACK集群中对应项目的Deployment资源，将镜像版本替换为本次构建的最新版本；
2. 镜像拉取与容器启动：ACK集群接收到配置更新指令后，从ACR私有仓库拉取对应版本的镜像，完成容器初始化；
3. 平滑滚动更新：依托K8s的滚动发布策略，先启动新版本Pod，通过就绪探针检测服务正常后，再逐步下线旧版本Pod，全程保证服务可用副本数达标，实现业务无感知、不停服更新；
4. 静态资源加速处理：若本次更新涉及前端资源或后端静态文件，流水线同步将静态资源推送到阿里云OSS，并触发CDN缓存刷新，通过动静分离架构，降低后端服务IO负载，同时提升用户端访问速度。

第五阶段：结果反馈与运维监控（Feedback）

核心目标：形成交付闭环，即时同步流程结果，保障线上服务稳定性，为后续迭代优化提供数据支撑。

1. 全链路结果通知：通过钉钉机器人推送流水线最终结果：
   • 成功场景：推送绿色通知卡片，包含部署环境、镜像版本、代码提交记录、ChangeLog等信息，全团队可追溯；
   • 失败场景：推送红色告警卡片，精准@本次代码提交人，附带Jenkins控制台报错链接，实现问题快速定位、快速响应；
2. 服务健康校验：ACK集群通过Liveness存活探针、Readiness就绪探针，持续检测服务运行状态，若服务异常则自动重启容器、重新调度，避免故障扩散；
3. 闭环优化：基于流水线执行数据、线上监控数据，持续优化流程卡点（如构建速度、门禁规则、部署策略），实现CI/CD体系的持续迭代。

三、问答

Q1：已经有了ACR镜像仓库，为什么还需要搭建Nexus私有仓库？

核心结论：两者的职责边界完全不同，解决的是研发交付不同阶段的问题，互为补充，不可替代。

• Nexus面向编译构建阶段，核心存储研发过程中的中间产物，比如内部私有SDK、二方Jar包、第三方依赖缓存，解决的是多微服务编译时的依赖复用、内网加速、私有组件管控的问题；
• ACR面向部署运行阶段，核心存储最终交付的标准化运行镜像，包含完整的运行环境，解决的是服务部署时的环境一致性、制品分发、版本管控的问题。
• 简单来说，Nexus管「编译时依赖」，ACR管「运行时交付」。

Q2：如何保证Jenkins调用阿里云ACK集群的安全性？

核心原则：最小权限原则，杜绝明文密钥硬编码，从凭证存储、权限管控两个维度保障安全。

1. 杜绝在Jenkins流水线代码、配置文件中硬编码阿里云AK/SK，避免密钥泄露；
2. 凭证加密存储：将ACK集群的kubeconfig文件，以Jenkins Credentials的形式加密存储，流水线运行时仅临时调用，全程不暴露明文内容；
3. 权限最小化：为kubeconfig对应的账号，仅开放特定Namespace的Deployment操作权限，不授予集群管理员全权限，避免账号泄露造成集群整体风险；
4. 可选进阶方案：为Jenkins所在的ECS实例配置阿里云RAM角色，通过RAM角色授权访问ACK集群，彻底消除密钥配置的风险。

Q3：流水线构建失败时，钉钉机器人如何实现精准定位并@对应负责人？

核心是通过GitLab与Jenkins的环境变量联动，实现提交人与钉钉账号的精准映射。

1. 代码提交触发Webhook时，GitLab会将提交人邮箱、提交ID等信息，通过环境变量${env.GIT_COMMITTER_EMAIL}传递给Jenkins流水线；
2. 提前维护GitLab邮箱与钉钉绑定手机号的映射表，流水线执行失败时，通过Shell/Python脚本读取环境变量，匹配到对应提交人的钉钉手机号；
3. 调用钉钉机器人开放接口，在告警通知中通过手机号精准@对应提交人，同时附带报错链接，实现谁提交、谁负责、谁处理，避免责任推诿。

Q4：OSS+CDN在这套CI/CD流程中，解决了什么核心问题？

核心是实现动静分离架构，同时兼顾服务性能与用户访问体验。

1. 降低后端服务负载：将静态图片、上传附件、前端打包产物等静态资源，全量托管到OSS，后端服务仅负责处理业务逻辑与接口请求，彻底消除静态资源带来的IO、带宽压力；
2. 提升用户访问体验：通过CDN将静态资源缓存到全国边缘节点，用户就近获取资源，极大缩短首屏加载时间，解决跨地域访问延迟高的问题；
3. 降低运维成本：依托OSS+CDN的弹性扩容能力，无需为静态资源单独部署服务器、配置带宽，同时流水线自动完成资源推送与缓存刷新，无需人工干预。

四、体系核心优势总结

这套CI/CD体系，实现了研发交付的全流程自动化，核心优势有三点：

1. 提效降本：从代码提交到线上部署全流程无需人工干预，大幅缩短交付周期，同时把研发人员从重复的部署工作中解放出来；
2. 风险可控：通过前置质量门禁、标准化镜像、滚动发布、精准告警等机制，把问题拦截在上线前，即使出现故障也可快速回滚，保障业务稳定性；
3. 全链路可追溯：从代码提交、构建、镜像、部署全流程，都可通过Git提交ID、镜像Tag一一对应，实现问题可追溯、责任可定位。

整个流程强调自动化、快速反馈和可重复性，目标是降低发布风险，缩短交付周期，提升软件质量。