1. CI/CD 概念与价值
聊到 CI/CD，很多人第一反应就是 Jenkins 或者 GitLab CI 那一堆配置文件。
但说真的，CI/CD 的核心从来不是某个工具。
它是一种理念，一种让软件交付更可靠、更快速的工程实践。
1.1 为什么需要 CI/CD
我先讲个故事。
几年前我负责一个传统项目，团队 10 个人，代码合并靠自觉。每次发布前，要找个晚上所有人线上集合，手动合并、手动编译、手动部署。出了 Bug 就回滚，然后重来。
有次发布花了整整 8 个小时。凌晨 3 点，我盯着屏幕上的编译错误，心想：这活儿不能再这么干了。
其实很多团队都经历过这个阶段。问题出在哪？
| 传统方式的痛点 | 后果 |
|---|---|
| 手动合并代码，容易漏改或冲突 | 集成阶段才发现问题，修复成本高 |
| 手动执行构建和测试 | 效率低，容易出错 |
| 缺乏自动化质控关卡 | 劣质代码流入主干 |
| 发布流程不透明 | 出了问题没人知道谁改的 |
这些痛点说白了就是：反馈太慢。
代码提交后，你可能要等几天才知道它有没有问题。等发现时，上下文早忘了。
1.2 什么是 CI
CI，全称是 Continuous Integration，持续集成。
它强调的是：频繁地将代码变更合并到主干，并且每次合并都自动触发构建和测试。
我个人的习惯是：团队里每个人每天至少合并一次代码。听起来挺激进吧？但你想想看，如果合并频率太低，冲突就像滚雪球，越滚越大。
CI 的核心动作很简单：
- 开发者提交代码到共享仓库
- 自动化流水线被触发
- 拉取最新代码，执行编译
- 运行单元测试、静态分析、代码规范检查
- 报告结果（通过或失败）
举个例子，一段简化的 CI 配置（使用 GitLab CI）：
stages:
- build
- test
- lint
build-job:
stage: build
script:
- make build
test-job:
stage: test
script:
- make test
lint-job:
stage: lint
script:
- make lint看到没，代码提交后，流水线自动跑。如果构建失败，直接阻塞合并请求。
这样就能在几分钟内发现问题，而不是等到发布前。
1.3 什么是 CD
CD 有两个常见的解释：Continuous Delivery（持续交付）和 Continuous Deployment（持续部署）。
持续交付，意思是代码通过所有测试关卡后，自动准备好发布包。但要不要上线，由人决定。点击一个按钮，就能部署到生产环境。
持续部署，更进一步。通过了所有测试，系统自动部署到生产环境。没有人工干预。
嗯，这里要注意：持续部署听起来很酷，但不是所有场景都适合。我经历过一个金融项目，合规要求所有生产变更必须人工审批。所以我们就只做到了持续交付，没再往前推。
打个比方：
- CI 像是自动化的质检流水线
- 持续交付是质检合格后，放进出货区，等签字发货
- 持续部署是质检合格后，快递直接发出
1.4 核心：自动化与流程规范
CI/CD 成功的两个支柱：自动化和流程规范。
自动化好理解。把手动操作变成脚本、配置、流水线。但流程规范这块，很多团队会忽略。
我曾经犯过一个错误：流水线里没加代码规范检查，结果新同事提交的代码缩进混乱，命名随意。虽然编译通过了，但 review 时谁都不想看。后来我强制在流水线里加了 lint 阶段，不通过直接打回。
自动化的典型范围：
- 代码检查：静态分析、风格检查、安全扫描
- 编译构建：环境统一、依赖管理
- 测试：单元测试、集成测试、端到端测试
- 打包：生成制品（Docker 镜像、二进制包、JAR）
- 部署：推送至测试/预发/生产环境
- 通知：结果反馈给团队
核心思想：每一次代码变更，都触发整个质控链条。发现问题，越早越好。
1.5 CI/CD 流水线的核心价值
还回到那个凌晨 3 点的故事。如果我那时有 CI/CD，会是什么样？
| 价值 | 说明 |
|---|---|
| 快速反馈 | 几分钟内知道代码是否正常 |
| 减少风险 | 每次变更都验证，不会积攒问题 |
| 提升信心 | 发布流程可靠，敢于频繁上线 |
| 节省时间 | 自动化替代重复劳动 |
| 团队协作 | 统一的流程和标准 |
我记得有一次，系统突然出现性能退化。过去可能要排查半天。但因为有 CI 流水线，我们通过回滚到上一次通过的构建，几分钟就恢复了。然后慢慢查是哪次提交引入的问题。
你想想看，如果没有流水线，遇到这种情况，只能停线排查，用户都在等，那压力有多大。
个人建议：刚开始引入 CI/CD 时，别贪多。先跑通最基本的编译+单元测试。跑通了，再加代码检查和部署。一步一步来。
1.6 CI/CD 不是什么
最后聊聊一些常见的误区。
- CI/CD 不等于 Jenkins：工具可以换，理念不变。
- CI/CD 不是万能药：如果代码本身质量差，流水线只是让错误暴露得更快。
- CI/CD 不是运维的事：它是整个研发团队的实践。
避坑指南：我曾经见过一个团队，Jenkins 上挂了 30 多个流水线，但谁都不想维护。配置写死了，依赖版本锁死，导致上线前经常手动跳过流水线。这样反而更危险。要定期维护和优化流水线，别让它变成摆设。
这张图展示了 CI/CD 的核心脉络。
从左到右：代码提交 → 自动构建 → 自动测试 → 质控关卡。
通过后才考虑部署。这就是整个体系的逻辑。