研发团队 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）按需配置 ...