二、CI/CD基础概念：持续集成、持续交付、持续部署的区别与联系
在进入Jenkins与GitLab CI/CD的实操之前，必须先厘清CI/CD领域最核心的三个概念：持续集成（Continuous Integration）、持续交付（Continuous Delivery）和持续部署（Continuous Deployment）。很多团队在落地DevOps时，往往将三者混为一谈，导致流水线设计目标模糊、自动化程度失衡。本章将从定义、流程、工具链三个维度，系统拆解三者的本质区别与内在联系，并深入剖析一条标准CI/CD流水线的组成要素，最后对主流工具链进行横向对比，帮助你在实际项目中做出合理的技术选型与架构设计。
2.1 核心原理：从手动到自动化的演进逻辑
持续集成、持续交付、持续部署并非三个独立的技术，而是软件发布自动化程度逐步提升的三个阶段。理解它们的关键在于把握“自动化边界”和“人工介入点”这两个维度。
持续集成（CI）关注的是代码合并后的自动化验证。开发人员频繁地将代码变更合并到主干分支（通常每天至少一次），每次合并都触发自动化的构建和测试流程。其核心价值在于“尽早发现集成问题”，避免“集成地狱”——即多个开发者在各自分支上开发数周后合并时产生大量冲突和错误。CI的反馈周期通常控制在10-30分钟内，让开发者能在上下文切换成本最低时修复问题。
持续交付（CD）在CI的基础上，进一步将自动化部署扩展到预生产环境（如 staging、UAT）。每次通过CI验证的代码，都会自动部署到与生产环境高度相似的预生产环境，并进行更全面的验证（如冒烟测试、性能测试、安全扫描）。此时，软件已经处于“随时可发布”的状态，但最终是否发布到生产环境，仍由人工决策。这适合对发布时机有严格管控要求的团队（如金融、政务），可以在保证质量的同时保留“最后一公里”的人工审批。
持续部署（CD）则是自动化的极致——所有通过自动化测试的代码变更，都会自动部署到生产环境。这要求团队具备极高的自动化测试覆盖率和强大的监控告警能力，因为一旦测试有遗漏，缺陷会直接暴露给最终用户。持续部署适合互联网产品、SaaS服务等追求快速迭代、能够通过灰度发布和快速回滚来降低风险的场景。
核心记忆点：CI是“自动验证”，持续交付是“自动准备好发布”，持续部署是“自动发布”。三者是递进关系，而非并列关系。没有CI的CD是无源之水，没有CD的CI则价值有限。
2.2 判断方法：如何确定团队当前需要哪个阶段
并非所有团队都适合直接实施持续部署。判断标准应基于团队的技术成熟度、业务风险承受能力和基础设施完善程度。以下是一个实用的评估清单：
| 评估维度 | 适合持续集成 | 适合持续交付 | 适合持续部署 |
|---|---|---|---|
| 自动化测试覆盖率 | > 30%（核心路径） | > 60%（含集成测试） | > 80%（含E2E测试） |
| 发布频率需求 | 每日多次合并 | 每周1-2次发布 | 每日多次发布 |
| 回滚能力 | 手动回滚代码 | 一键回滚到上一版本 | 自动回滚 + 灰度发布 |
| 监控告警体系 | 基础日志查看 | 核心指标监控 | 全链路监控 + 告警 |
| 团队协作模式 | 开发+测试 | 开发+测试+运维 | DevOps全栈团队 |
操作流程建议：对于传统企业或刚起步的团队，建议分三步走。第一步，先落地CI，确保每次代码合并都有自动化构建和单元测试。第二步，引入持续交付，搭建预生产环境，实现自动部署到staging。第三步，当测试覆盖率和监控体系成熟后，再逐步放开生产环境的自动部署，初期可采用“自动部署+人工确认”的过渡模式，最终实现全自动。
2.3 CI/CD流水线的基本组成：构建、测试、部署
一条标准的CI/CD流水线，无论使用何种工具，其核心阶段都围绕“构建-测试-部署”展开。但实际落地时，每个阶段内部还有更细分的步骤。
构建阶段（Build）：将源代码转换为可运行制品的过程。对于Java是编译打包成JAR/WAR，对于Node.js是执行npm install和构建脚本，对于容器化项目则是生成Docker镜像。构建阶段的关键产出物是制品（Artifact），它应当被版本化并存储到制品库（如Nexus、Harbor）中，以便后续阶段使用和追溯。
测试阶段（Test）：质量保障的核心环节。通常按金字塔模型分层执行：单元测试（测试单个函数/类）、集成测试（测试模块间交互）、端到端测试（模拟用户真实操作）。测试阶段还应包含代码静态扫描（SonarQube）、安全漏洞扫描（Trivy）等质量门禁。任何一层失败，流水线都应立即中断，防止劣质代码流向下一环节。
部署阶段（Deploy）：将制品发布到目标环境的过程。部署策略包括：蓝绿部署（两套环境切换）、金丝雀发布（先让少量用户使用新版本）、滚动更新（逐步替换旧实例）。部署阶段应包含环境配置管理（如Kubernetes的ConfigMap）、数据库迁移脚本执行等。部署完成后，通常还会自动执行一轮冒烟测试，确认服务正常启动。
实战经验：流水线设计应遵循“左移测试”原则——越早发现缺陷，修复成本越低。建议在构建阶段就并行执行静态代码分析和单元测试，而不是等构建完成后再串行执行。同时，每个阶段都应设置超时时间（如构建10分钟、测试15分钟），避免流水线卡死。
2.4 常见工具链对比：Jenkins、GitLab CI、GitHub Actions
工具选型是团队落地CI/CD时最纠结的问题。下表从多个维度对三大主流工具进行对比：
| 对比维度 | Jenkins | GitLab CI | GitHub Actions |
|---|---|---|---|
| 架构模式 | Master/Slave 分布式 | Runner 分布式（共享/特定） | Runner 托管/自托管 |
| 配置方式 | Web界面 + Jenkinsfile（Groovy） | .gitlab-ci.yml（YAML） | .github/workflows/*.yml（YAML） |
| 学习曲线 | 较陡（插件生态复杂） | 中等（YAML简洁） | 较平缓（市场模板丰富） |
| 插件/市场 | 超过1800个插件 | 内置功能丰富，少用插件 | Marketplace + 社区Action |
| 托管环境 | 自建服务器 | GitLab.com / 自托管 | GitHub.com / 企业版 |
| 适合场景 | 复杂流水线、已有Jenkins生态 | 代码托管在GitLab的团队 | 开源项目、GitHub重度用户 |
| 并发能力 | 依赖Slave节点数 | 按Runner并发数计费 | 按套餐限制并发 |
选型建议：如果团队已经深度使用GitLab进行代码管理，优先选择GitLab CI，因为其一体化体验最佳，无需额外维护Jenkins服务器。如果项目托管在GitHub且希望利用丰富的社区Action，GitHub Actions是首选。而Jenkins则更适合需要高度定制化、已有大量历史插件投资或运行在纯内网环境的大型企业。
2.5 案例拆解：一个中型Web应用的CI/CD落地过程
为了将上述概念串联起来，我们以一个典型的Spring Boot + Vue.js前后端分离项目为例，展示从零搭建CI/CD流水线的完整决策过程。
背景与约束：某互联网公司产品团队共12人（8后端、4前端），代码托管在自建GitLab，生产环境为Kubernetes集群。当前痛点：手动部署频繁出错，每次发版需要2小时，且经常出现“在我机器上是好的”问题。目标：将发版时间缩短到30分钟内，并实现自动化回滚。
初始现象与目标：团队最初只有简单的构建脚本，没有统一流水线。每次发布由运维手动执行kubectl命令，一旦配置错误，需要回滚并重新构建，平均每周发生1-2次发布事故。
关键输入数据：代码仓库约5000次提交/年，平均每天20次push；测试用例约800个（单元测试600，集成测试150，E2E测试50）；生产环境为3节点K8s集群。
分析判断过程：团队评估后决定分两个阶段实施。第一阶段先实现CI+持续交付（自动部署到staging），第二阶段再逐步放开生产环境的自动部署。工具选型上，由于代码已在GitLab，直接采用GitLab CI，避免额外维护Jenkins。
实际操作步骤：
- 定义流水线阶段：在项目根目录创建
.gitlab-ci.yml，定义build、test、deploy-staging、deploy-production四个阶段。 - 构建阶段：使用Maven构建后端生成JAR包，使用npm构建前端生成静态文件，然后分别构建Docker镜像并推送到Harbor仓库。
- 测试阶段：并行执行单元测试和集成测试，使用SonarQube进行代码质量检查，设置质量阈值（如代码覆盖率不低于70%）。
- 部署到staging：通过Kubernetes的Deployment更新staging命名空间，部署后自动执行冒烟测试（检查/health接口返回200）。
- 生产部署（人工审批）：在GitLab CI中设置
when: manual，由技术负责人点击触发生产部署。生产部署采用金丝雀策略，先更新1个Pod，观察5分钟日志和错误率，再滚动更新剩余Pod。
结果对比：实施后，发版时间从2小时缩短至25分钟；发布事故率从每周1-2次降至每月不到1次；开发者提交代码后15分钟内即可获得测试反馈。
风险与代价：初期搭建流水线花费了约3人天的工作量；staging环境需要额外一台4核8G的服务器；团队需要学习YAML语法和GitLab CI的规则。
复盘经验：关键成功因素在于测试覆盖率的保障——没有足够的自动化测试，流水线再快也无法保证质量。另外，配置即代码的理念非常重要，所有流水线配置都纳入版本控制，方便审查和回滚。
2.6 常见误区与总结复盘
在辅导多个团队落地CI/CD的过程中，我发现以下误区最为常见：
- 误区一：把CI/CD等同于“用工具跑脚本”。很多团队只是把原来的手动命令写进YAML，没有设计质量门禁和反馈机制，流水线形同虚设。
- 误区二：测试阶段被过度压缩。为了追求“快”，只跑单元测试就部署，导致集成问题在预生产或生产环境才暴露，反而更慢。
- 误区三：忽略环境一致性。开发环境、测试环境、生产环境的依赖版本、配置项不一致，导致“测试通过了，生产却挂了”。应使用容器化或基础设施即代码（IaC）来保证一致性。
- 误区四：没有回滚策略。只关注“如何发布”，不关注“如何快速回滚”。一旦发布出错，手动回滚耗时耗力。应在设计流水线时就定义好回滚步骤（如K8s的
kubectl rollout undo）。 - 误区五：工具选型盲目跟风。看到别人用GitHub Actions就迁移，不考虑自身代码托管平台和团队技能，造成不必要的迁移成本。
风险提示：持续部署并非银弹。如果业务对合规性要求极高（如医疗、金融核心系统），或团队缺乏有效的监控告警能力，强行实施持续部署可能带来严重生产事故。建议从持续交付开始，逐步积累自动化信心。