研发团队 CI/CD 工作流建设方案
编制日期： 2026-08-11
版本： V1.1
一、CI/CD是什么？解决什么问题？
1.1 CI/CD是什么？
CI/CD 是软件开发领域一套核心的自动化流程体系，核心目标是通过减少人工干预，大幅提升代码交付的效率与稳定性。
- CI（Continuous Integration，持续集成）：开发人员频繁将代码变更合并到共享主干分支，通过自动化构建、测试流程快速验证代码正确性，尽早发现集成冲突与bug。
- CD 包含两层常见含义：
- Continuous Delivery，持续交付：代码通过自动化测试后，自动进入预发布仓库，确保团队可随时手动将其部署到生产环境。
- Continuous Deployment，持续部署：在持续交付基础上，代码无需人工审核，自动完成全流程校验后直接发布到生产环境，是自动化程度最高的交付模式。
1.2 当前的问题，为什么要使用CI/CD
当前面临如下问题：
| 环节 | 现状问题 |
|---|---|
| 代码集中管理 | 无统一代码托管平台，版本管理不规范，代码散落在各开发人员手里 |
| 构建/测试 | 依赖个人电脑，环境不统一 |
| 制品管理 | 无统一制品仓库，依赖手工拷贝传递 |
| 部署发布 | 人工操作、无记录、回滚困难 |
| 质量保障 | 缺少自动化测试与代码检查，缺陷到测试阶段才暴露 |
使用CI/CD工作流后，可以实现：
- 代码集中管理: 避免代码或分支散落在开发人员手里，长期不合并代码导致的冲突或者代码混乱问题。 并且可以在统一代码平台规范代码分支的管理。
- 标准化构建、测试、部署环境: 彻底解决“本地运行正常、线上出问题”的经典环境不一致问题
- 制品管理： 搭建统一的制品仓库/镜像仓库，将代码构建出的制成品统一放入制品仓库，保障交付的一致性。解决以往制品传递依赖手工拷贝导致的混乱。
- 降低部署风险： 标准化的自动部署流程，完全规避人工操作失误带来的发布故障，大幅提升发布可靠性。
- 质量保障： 通过自动化测试、代码扫描等环节，在上线前拦截绝大多数缺陷，显著降低生产环境的故障概率。
1.3 使用CI/CD的前提：用代码仓库将代码统一管理起来
- 代码资产归属明确：代码作为企业核心技术资产，集中托管可彻底避免代码散落在开发者本地设备，从根源杜绝人员离职、设备损坏导致的代码丢失风险。
- 消除版本混乱痛点：终结传统本地零散存储、多版本拷贝传递的混乱状态，形成唯一可信的代码版本源，彻底解决多分支并行开发时的版本冲突、追溯困难问题。
- 支撑研发流程落地：是后续代码评审、自动化CI/CD流水线、制品全链路溯源等所有标准化研发流程的前置基础，没有集中管理就无法搭建完整的自动化研发体系。
1.4 统一代码库落地举例：Gitlab代码仓库
- 多级仓库管理：支持通过Group/Subgroup构建匹配组织架构的仓库管理体系，实现代码资产的分层归类与集中托管。
- 细颗粒度权限管控：基于Group/Project/User三级维度动态配置权限，精准管控不同角色的代码访问、修改权限，避免非授权访问。
- 并行开发支持：采用主干-开发-功能分支模式，实现版本与功能解耦，多个开发人员可同时推进不同功能开发，互不干扰。
二、CI/CD 工作流总体设计
2.1 核心流程
开发统一将代码（分支）提交到代码库
│
▼
代码评审（Merge Request）──► 合并到主干
│
▼
CI 触发：静态检查 → 单元测试 → 构建制品
│
▼
制品 / 镜像入库（Nexus / Harbor）
│
▼
自动部署到测试环境
│
▼
测试通过后部署预生产 / 生产环境
2.2 平台选型技术参考
| 环节 | 候选方案 | 推荐 | 推荐理由 |
|---|---|---|---|
| 代码托管 | GitLab CE / Gitea / 商业 SaaS | GitLab CE（自建） | 集代码托管与 CI/CD 于一体，权限模型成熟，社区生态好 |
| CI/CD 引擎 | GitLab CI / Jenkins / GitHub Actions | GitLab CI / Jenkins | GitLab CI与代码平台一体，免维护两套系统/Jenkins插件生态成熟 |
| 构建执行器 | 独立虚拟机 / Docker / Kubernetes 动态 | 初期独立 VM（2–3 台），后期按需扩展 | 起步稳定简单、成本可控 |
| 制品仓库 | Nexus / Artifactory | Nexus | 覆盖 Maven / npm / PyPI 等主流依赖与通用制品 |
| 镜像仓库 | Harbor / Docker Registry | Harbor | 带权限隔离、漏洞扫描，企业级标配 |
| 部署环境 | Docker Compose / Kubernetes | 测试环境按项目规模选 | 初期避免过度设计，K8s 视第二阶段需要引入 |
| 代码质量 | SonarQube | 第二阶段引入 | 先跑通流程，再强化质量门禁 |
| 统一认证 | LDAP / AD | 接入统一认证 | 一账号通走各平台，权限集中管控 |
三、基础设施与资源需求
3.1 初期资源清单（按 20–50 人研发团队估算）
| 用途 | 配置建议 | 数量 | 说明 |
|---|---|---|---|
| GitLab代码库 | 8C / 16G 内存，SSD 500G 以上 | 1 | 20-50 人规模单机可承载 |
| CI Runner/Jenkins | 16C / 32G，SSD 1TB 以上 | 2 | 执行流水线，缓存构建依赖 |
| 制品仓库 Nexus | 4C / 8G，存储 2T | 1 | 依赖与制品存储量大，磁盘可扩容 |
| 镜像仓库 Harbor | 4C / 8G，存储 2T | 1 | 镜像占用大，需配定期清理策略 |
| SonarQube/LDAP | 4C / 8G，存储 500G | 2 | 用虚拟机即可 |
| 测试环境 | 视项目规模而定 | 按需 | 可用 Docker 或轻量 K8s，3 节点起步 |
需要注意服务器架构问题： 建议除测试环境外的基础架构采用X86高配服务器做虚拟化，资源使用更加灵活，aarch64架构的服务器不方便做虚拟化 可1台机器配置多磁盘做存储，2台或以上机器配置多核CPU+高内存做计算资源。 也可3台高配服务器做超融合。 剩余测试环境根据生产环境所需架构（aarch64或者X86）按需配置
四、实施计划
4.1 三阶段推进
| 阶段 | 时间 | 内容 | 里程碑 / 验收标准 |
|---|---|---|---|
| 一、平台搭建 | 第 1–8 周 | 资源采购；部署 GitLab、Nexus、Harbor、Runner/Jenkins | 平台可用；用一个样例项目完成全流程演练 |
| 二、试点接入 | 第 9–16 周 | 选定 1–2 个试点项目/团队；梳理其开发流程并接入 CI/CD；完成试点培训 | 试点项目日常开发全部走 CI/CD，产出试点总结 |
| 三、全面推广 | 第 16 周起 | 全员培训；存量项目分批迁移； | 全部在研项目纳入平台 |
五 制品管理/工程库管理
制品管理是CI/CD流水线中承上启下的核心枢纽，是实现“一次构建、多次复用”的关键环节，也是保障软件交付全流程可信、可控的核心能力。
5.1 制品管理基础概念
制品定义： 指源码编译打包生成的二进制文件，也包含各类依赖包、配置文件等，是可直接用于部署或作为编译依赖的交付产物。
制品分类： 按场景可分为外部引入的第三方组件、内部公共依赖包/SDK、最终产品交付安装包三类；按格式覆盖jar，Maven、npm、Docker镜像、RPM、DEB等数十种主流类型。
核心定位： 是CI持续集成的终点，同时也是CD持续交付的起点，脱离制品管理无法搭建高效稳定的自动化流水线。
5.2 制品管理的核心价值
终结版本混乱： 统一存储所有类型制品，彻底解决版本追踪困难、跨环境包传递依赖手工拷贝的痛点。
提升研发效率： 统一缓存管理外部依赖，大幅降低第三方组件下载耗时，避免团队重复构建相同产物，减少资源浪费与重复建设。
保障交付一致性： 实现“一次构建，多环境复用”，彻底避免测试环境与生产环境部署包不一致导致的线上故障。
方便后续工程库管理： 在落地代码与程序版本的统一管控机制后，所有生产交付的程序包，均可通过知识库完成发布版本与源码版本的精准关联，依托MD5校验值实现对外发制品的全流程校验与可信管控，彻底规避版本错配、包篡改等交付风险。
5.3 主流落地工具
Sonatype Nexus：支持绝大多数主流制品格式，是行业应用最广泛的通用制品管理平台
六、总结：CI/CD预期收益
- 集中管理 ：代码集中管理，避免重要业务代码散落在开发人员电脑中，解决版本混乱问题
- 交付更快 ：自动化消除"构建等半天、发布靠加班"，交付周期由天级降至小时级
- 质量更高 ：自动化测试与静态检查让缺陷在合入前被发现，返工减少
- 过程可溯 ：每一次变更、构建、发布全程留痕，问题可查、可回滚
- 新人友好 ：模板化流程让新员工快速上手开发交付，降低培养成本
- 为未来打基础 ：统一 CI/CD 是后续自动发布、云原生、DevSecOps 建设的底座