CI/CD 基础概念
聊到 CI/CD，很多朋友第一反应就是「哦，自动编译部署的工具」。嗯，这话不算错，但说实话，它远不止这么简单。我见过太多团队把 CI/CD 当成一个黑盒子——代码推进去，结果出来就行。可一旦构建失败，完全不知道从哪下手。
我个人习惯是，在搭流水线之前，先把 CI 和 CD 各自干什么搞清楚。你想想看，如果连基础概念都模糊，排起错来就像没头苍蝇一样乱撞。这一章咱们就把地基打牢。
1.1 什么是持续集成（CI）
持续集成，说白了就是让开发人员频繁地把代码合并到主干，然后自动触发构建和测试。我建议一天至少合并一次，而不是憋一周才推一次。为什么？合并得越频繁，冲突越小，问题暴露得越早。
我在项目中遇到过这样的团队：一个月才合并一次代码，结果合并那天所有人都放下手头工作，花一整天解决冲突。嗯，这其实已经背离了「持续」的初衷。
CI 的核心实践包括：
- 频繁提交代码——每天至少一次，小批量提交
- 自动化构建——提交后自动编译、打包
- 自动化测试——单元测试、集成测试自动运行
- 快速反馈——构建结果在 10 分钟内通知到开发者
一句话记住 CI：代码一提交，机器就帮我跑构建和测试，有问题立马知道。
1.2 什么是持续部署（CD）
持续部署是在 CI 的基础上，把通过测试的代码自动部署到目标环境。注意，持续部署和持续交付是两码事。持续交付是把代码部署到类生产环境，但还需要人工点击确认才能上线。而持续部署是连那个确认按钮都省了，全自动。
我曾经在一个金融项目里推行持续部署，刚开始运维同学很慌：「代码直接上生产？出事了谁负责？」后来我们设置了灰度发布和金丝雀机制，才让大家放心。说白了，CD 不是莽撞地「直接上线」，而是用自动化手段控制风险。
CD 通常包含这几个环节：
- 自动化部署到测试环境
- 集成测试通过后，部署到预发布环境
- 预发布验证通过，灰度发布到生产环境
- 全量上线并监控
注意：没有充分的自动化测试覆盖，不要轻易上 CD。否则你只是把「手动搞挂」变成了「自动搞挂」，速度更快，破坏力也更大。
1.3 CI/CD 的核心价值
很多朋友问：花那么多精力搭 CI/CD，到底图什么？我总结了几点：
- 快速发现集成问题——代码合并后几分钟就能知道是否冲突、是否编译通过。我见过一个团队，没上 CI 之前，集成问题要拖到上线前才发现，一查就是好几天。
- 降低手动操作失误——人总会有手滑的时候。部署脚本写错了参数、漏了配置文件……这些用自动化流水线可以完全规避。
- 加速交付周期——从代码提交到上线，以前可能要一两天，现在十几分钟搞定。我经历过的最快记录是从提交到上线只用了 8 分钟。
- 质量保障——每次提交都跑一遍完整的测试套件，相当于给代码上了个「安」。
| 维度 | 没有 CI/CD | 有 CI/CD |
|---|---|---|
| 发现问题时机 | 上线前或上线后 | 代码提交后几分钟 |
| 部署方式 | 手动操作，易出错 | 自动化，可重复 |
| 交付周期 | 天~周级别 | 分钟~小时级别 |
| 团队协作效率 | 低，经常等别人 | 高，并行开发 |
1.4 常见工具链
工欲善其事，必先利其器。CI/CD 的工具生态已经很成熟了，我列几个常见的：
| 工具 | 类型 | 特点 | 适用场景 |
|---|---|---|---|
| Jenkins | CI/CD 平台 | 开源，插件丰富，灵活度高 | 复杂流水线，企业级项目 |
| GitLab CI | 集成 CI/CD | 与 GitLab 深度集成，配置简单 | GitLab 用户，中小团队 |
| GitHub Actions | 集成 CI/CD | 生态好，社区模板多 | 开源项目，GitHub 用户 |
| CircleCI | 云端 CI/CD | 速度快，缓存机制优秀 | 中小团队，追求速度 |
| ArgoCD | CD 工具 | GitOps 风格，Kubernetes 原生 | K8s 集群部署 |
这里贴一段我用得最多的 GitLab CI 配置片段，简单直观：
stages:
- build
- test
- deploy
build-job:
stage: build
script:
- echo "编译代码..."
- mvn clean package
test-job:
stage: test
script:
- echo "运行测试..."
- mvn test
deploy-job:
stage: deploy
script:
- echo "部署到服务器..."
- scp target/app.jar user@server:/app/你看，三个 stage 对应 CI/CD 的三大环节，清晰明了。实际项目里还会加更多细节，但这个骨架已经够用了。
1.5 避坑指南
讲几个我踩过的坑，希望对你有帮助：
- 别把密码写死在配置里——我曾经在 GitLab CI 配置文件里直接写了数据库密码，结果代码开源后两小时就被薅了。用 CI/CD 的变量功能或者密钥管理服务。
- 构建环境要保持一致——遇到过本地能编译通过，CI 上却失败的情况，排查了半天发现是 JDK 版本不一致。用容器化构建能彻底解决这个问题。
- 测试别只跑单元测试——单元测试过了不代表集成没问题。我见过 CI 全绿，结果上线后接口调用失败，因为依赖的服务没启动。至少要加一层集成测试。
小建议：刚开始推行 CI/CD 时，别追求一步到位。先搭 CI，跑起来再说。等团队适应了，再上 CD。一步到位往往被抵触，最后不了了之。
好了，这一章的概念就说到这儿。理解 CI 和 CD 的本质区别，知道它们解决什么问题，熟悉常用工具——这些东西搞清楚了，后续排查构建失败才能有的放矢。