📚 课程目录第2章持续集成与持续部署（CI/CD）基础

持续集成与持续部署（CI/CD）基础：流水线原理与工具选型归纳总结

聊到 CI/CD，我觉得很多团队其实只搭了个「自动打包机」。我见过不少项目，Jenkins 配了一堆 Job，但每次提交代码还是人工点“构建”，测试报告丢到邮件里没人看——这充其量算半自动化。真正的 CI/CD 流水线，应该是从代码提交到生产部署的完整链条，中间每一步都能自动验证、自动反馈。

这一节我会把流水线的核心原理拆开来讲，再结合我个人的踩坑经验，聊聊怎么选工具。

流水线（Pipeline）的核心逻辑

说白了，流水线就是把「手动操作」变成「自动步骤」。每个步骤有输入、有输出、有成功或失败的结果。一套标准的 CI/CD 流水线，通常包含下面这几个阶段：

触发——代码推送、合并请求、定时任务等事件启动流水线。
检出/初始化——拉取代码、设置环境变量、安装依赖。
构建——编译、打包、生成制品（Jar、Docker 镜像等）。
测试——单元测试、集成测试、代码扫描。
部署——将制品发布到测试环境、预发布环境或生产环境。
验证与监控——健康检查、冒烟测试、回滚判断。

我曾经接手过一个项目，流水线跑完构建就直接部署生产，测试环节被跳过了。结果上线后发现数据库迁移脚本有问题，数据全乱套。那次事故之后，我强制要求在流水线里加上自动化测试和回滚步骤。你想想看，没有测试的流水线，跟手动部署有什么区别？

  核心原则：每个阶段都应当输出明确的“通过/失败”信号，并且失败后立即停止后续步骤，不给错误继续传播的机会。

工具选型：从经典到云原生

现在市面上 CI/CD 工具多得让人眼花。我个人习惯根据团队规模和基础设施类型来做选择。下面这张表是我对比过的几款主流工具，列出核心差异：

工具	部署方式	配置语言	流水线能力	适合场景
Jenkins	自托管，需维护	Jenkinsfile (Groovy)	插件生态丰富，可定制极强	大型企业、复杂构建流程
GitLab CI	内置在 GitLab	.gitlab-ci.yml	原生 MR 集成，Docker/ K8s 支持好	使用 GitLab 的中小团队
GitHub Actions	云服务（也可自托管 Runner）	YAML	市场大量 Action，矩阵构建方便	开源项目、GitHub 重度用户
CircleCI	云服务 + 自托管	.circleci/config.yml	并行度优秀，缓存智能	追求速度的 SaaS 型团队
Tekton	Kubernetes 原生	YAML (CRD)	Serverless，可观测性强	云原生、K8s 基础设施团队

我的建议：对于 5-10 人的小团队，GitLab CI 或 GitHub Actions 已经足够，别上来就搭 Jenkins 集群——维护成本比你想象的高得多。

流水线设计的常见误区

我见过很多团队把整个流水线写成一个超长脚本，几十个步骤塞在一个 Stage 里。一旦失败，根本不知道哪个环节出了问题。其实应该把职责拆开，每个 Stage 只做一件事。

举个例子，一个典型的 CI 流水线配置（以 GitLab CI 为例）：

stages:
  - build
  - test
  - deploy

compile:
  stage: build
  script:
    - mvn clean compile
  artifacts:
    paths:
      - target/*.jar

unit-test:
  stage: test
  script:
    - mvn test
  dependencies:
    - compile

deploy-staging:
  stage: deploy
  script:
    - scp target/*.jar user@staging:/app/
  only:
    - main

注意这里的 artifacts 和 dependencies。我在项目中遇到过好几次因为没传制品，导致测试阶段重新编译一遍，白白浪费几分钟。记住：构建产物要显式传递，不然流水线就变成了重复劳动。

避坑指南：我曾经踩过的三个坑

坑一：测试环境不一致。Jenkins 跑的构建环境和开发本地的 JDK 版本不一样，导致编译通过但运行报错。后来我统一用 Docker 镜像构建，保证环境一致。
坑二：并发冲突。多个 MR 同时触发流水线，同时去写同一个 S3 路径，互相覆盖。我改成每个流水线用唯一的 Build ID 作为目录。
坑三：没有超时控制。有个步骤因为网络问题 hanging 了 20 分钟，流水线一直卡着。我加了 timeout: 10 minutes，超时自动失败。

注意：CI/CD 工具本身也会成为瓶颈。Jenkins Master 如果负载过高，调度会变慢。我曾经踩过这个坑，后来加了外部队列和多个 Agent，才把并发量拉起来。

流水线核心结构图解

下面这张 SVG 图把 CI/CD 流水线的阶段性关系画出来了。从代码提交到最终部署，每个阶段都带有“通过/失败”的判断，失败后会有反馈通知。嗯，这里要特别留意“部署验证”这个节点——很多人漏掉它，结果部署成功了但服务不可用。

选型决策流程

到底选哪个工具？我个人的决策树是这样的：

如果你已经用 GitLab 管理代码 → 无脑 GitLab CI，零额外维护成本。
如果你在 GitHub 上做开源项目 → GitHub Actions，社区 Action 多，写起来快。
如果你需要跑大量并行任务（比如矩阵测试） → CircleCI 或 GitHub Actions 的矩阵策略。
如果你们团队有 K8s 运维能力且要极致弹性 → Tekton。
如果你们公司有合规要求，必须自托管且高度定制 → Jenkins（但要配好 Master 高可用和 Agent 自动扩缩）。

我曾经帮一个金融客户迁移流水线。他们原本用 Jenkins，但每年因为插件兼容性问题出好几次故障。我建议他们改用 GitLab CI 搭配 K8s Runner，配置简化了很多，而且每条流水线都是一个独立 Pod，环境隔离做得更好。迁移之后，流水线故障率下降了 70%。

  关键点：选工具不是选“最强大的”，而是选“最适合你们团队维护的”。有时候，看着简单的 YAML 反而比一个复杂的 Jenkins Pipeline 更可靠。

关于流水线原则的最后提醒

我见过太多流水线“跑成功了但没人知道部署了什么”。所以一定要给每个版本打标签，并且在流水线末尾自动生成发布说明。另一个容易被忽略的是——给流水线加上“人工审批门”。我在部署生产环境前设置了一个审批步骤，得主管确认才能放行。这个操作看起来简单，但能拦住很多因为手滑误触触发的部署事故。

嗯，到这里你应该对 CI/CD 流水线的原理和选型有了一个清晰的认知。记住一句话：流水线不是写出来的，而是在实践中迭代出来的。保持简单，保持可见，每次失败都是改进的机会。