CI/CD 基础回顾：持续集成与持续部署核心概念
讲实战之前，咱先把基础夯实。CI/CD 这三个字母，但凡搞过 DevOps 的人天天挂嘴边。但你真让我解释清楚，很多人其实也就懂个大概。我最早接触这个概念是在一家创业公司，那时连 Jenkins 都没听过，每次上线都是手动打包、手动上传、手动重启，出事概率高得离谱。后来踩了不少坑，才慢慢把 CI/CD 这套东西理顺。
说白了，CI/CD 就两件事：持续集成和持续部署（或持续交付）。它们不是同一个东西，但合在一起才管用。
持续集成：让代码一直“健康”
持续集成（Continuous Integration，CI）的核心理念很简单：频繁地把代码合并到主干，每次合并都自动构建、自动测试。我见过太多团队，开发一个月，最后一天合代码，合出一堆冲突和 bug，然后通宵修。你想想看，这种节奏能快吗？
为什么需要频繁合并？因为问题越早发现，修复成本越低。如果你的代码每两小时合一次，就算出问题，也只影响最近两小时的改动，定位起来快得多。
CI 的基本流程：
- 开发者推代码到版本仓库（GitLab / GitHub / Gitee）
- 仓库触发 Webhook 通知 CI 服务器
- CI 服务器拉取代码，执行构建脚本
- 运行单元测试、代码扫描、集成测试
- 反馈结果（绿色通过 / 红色失败）
一个小技巧： 我习惯在 CI 里加一个“代码规范检查”步骤。别小看这个，有一次团队里有人把密码硬编码进了配置文件，幸好规范检查直接拦截了，否则后果不堪设想。
持续部署：让发布变成“点一下”
持续部署（Continuous Deployment，CD）是在 CI 的基础上，把通过测试的代码自动部署到生产环境。注意，这里说的“自动”是指不需要人工干预——代码合并到主干，测试全绿，直接上线。还有一种叫“持续交付”，它和持续部署的唯一区别是：持续交付要求上线前有一个手动确认的门槛，而持续部署是完全自动。
我个人更推荐在创业期或者低频变更项目里用持续交付，留一个人工判断的环节。高频迭代的产品，比如互联网 App，持续部署反而更合适。
| 维度 | 持续集成 (CI) | 持续交付 (CD) | 持续部署 (CD) |
|---|---|---|---|
| 目标 | 保证代码合入后质量 | 保证代码随时可发布 | 保证代码自动上线 |
| 部署触发 | 无（仅构建测试） | 手动确认后部署 | 自动部署 |
| 适用范围 | 所有项目 | 需要审批流程的团队 | DevOps 成熟度高的团队 |
| 风险等级 | 低（不发布） | 中（有人把控） | 高（完全自动化） |
你可能会问：那我该选哪个？嗯，这取决于你们团队对生产的敬畏程度。我曾在一次快速迭代中直接上了持续部署，结果一个数据库迁移脚本写错了，导致线上服务中断 20 分钟。那次教训让我明白——持续部署的底气来自充分的测试覆盖率，不然就是在玩火。
Pipeline：CI/CD 的“骨架”
Pipeline（流水线）是 CI/CD 的具体实现。你可以把它想象成一条工厂流水线：代码进去，经过一道道工序，最后变成可部署的产物。每一道工序就是一个 Stage（阶段），每个 Stage 里可以跑多个 Job（任务）。
常见的 Pipeline 阶段包括：
- Checkout —— 从仓库拉取代码
- Build —— 编译、打包、构建镜像
- Test —— 单元测试、集成测试、安全扫描
- Package —— 生成可交付产物（如 tar、jar、Docker 镜像）
- Deploy —— 部署到测试/预发/生产环境
避坑提醒： 我曾经在 Pipeline 里把所有测试放在同一个 Stage，结果测试跑了 40 分钟才失败，浪费大量时间。后来改成并行 + 分阶段：单元测试最快，先跑；集成测试慢，后跑。一旦单元测试失败，直接停止整个 Pipeline，节省等待时间。
下面这张图展示了一个典型的 CI/CD 流水线，从代码提交到生产部署的全流程：
CI/CD 的核心收益
讲完了概念，咱们看看这玩意儿到底给我们带来什么好处。我总结了三句话：
- 反馈快 —— 提交代码几分钟后就知道有没有问题
- 错误少 —— 自动化测试覆盖了大部分人工容易漏的场景
- 发布稳 —— 每次部署的流程、脚本、环境完全一致，不会出现“本地可以，线上不行”的尴尬
我个人的习惯： 每接入一个 CI/CD 系统，我都会先跑一轮“空跑” —— 不修改任何代码，让 Pipeline 走一遍，确保所有步骤在正常状态下能通过。这能提前暴露很多环境配置问题，比如缺少某个依赖包、环境变量没设对等等。磨刀不误砍柴工。
你需要注意的几件事
就算你把 CI/CD 配置得再漂亮，如果下面这几点没做好，依然可能翻车：
- 测试覆盖率不是万能的，但没覆盖率是万万不能的。 我见过一个团队 CI 跑得飞快，但测试全是空壳，等于没跑。
- Pipeline 要保持“快速反馈”。 如果一次 CI 跑半个小时，开发者会不愿意等，甚至偷偷跳过。
- 环境的差异会咬人。 开发环境、测试环境、生产环境要尽量保持一致，最好用容器化来解决。
- 失败时要能快速定位。 日志要清晰，错误码要有意义，别丢出一堆看不懂的堆栈就完事。
我给新手的建议： 别一上来就搞花里胡哨的插件和脚本。先把最简单的 CI/CD 跑通 —— 比如只做编译 + 跑一个单元测试。等流程稳定了，再逐步加安全扫描、性能测试、自动回滚这些高级功能。否则你连基础 Pipeline 都建不牢，后面全是坑。
好了，CI/CD 的基础咱们就温习到这。记住：持续集成是“让你代码始终保持可用的状态”，持续部署是“让可用的代码自动跑到生产上”。这两个概念贯穿整门课程，后面所有密码改造的实践，都建立在这套流水线之上。我建议你把今天的内容记牢，尤其那张流程图，往后咱们会反复用到。