一、CI/CD 概念与价值：持续集成、持续交付、持续部署
聊到 CI/CD，很多前端同学第一反应是：「这不就是运维的事吗？」
说实话，我早年也这么想。直到有一次，我负责的项目上线前合并代码，结果把别人的样式全冲乱了。那天晚上十一点，我还在盯着冲突文件发呆。嗯，从那以后，我再也不敢小看 CI/CD 了。
1.1 三个核心概念，一次讲清楚
我们先拆开来看。CI 和 CD 其实是两件事，但经常被放在一起说。
持续集成（Continuous Integration）
说白了，就是让团队成员频繁地把代码合并到主干。每次合并，都自动触发构建和测试。
我个人习惯是：每天至少合并一次。别攒一周的代码再合，那简直是给自己挖坑。
核心要点： 持续集成 = 频繁合并 + 自动构建 + 自动测试
持续交付（Continuous Delivery）
持续交付是在持续集成的基础上，再加一步：确保代码随时可以部署到生产环境。
注意，是「可以部署」，不是「自动部署」。这中间有个审批流程，需要人来拍板。
持续部署（Continuous Deployment）
这个就更彻底了。代码通过测试后，自动部署到生产环境。没有人工干预。
你想想看，这得多大的信心才敢这么干？我在项目中遇到过，只有自动化测试覆盖率达到 90% 以上的团队，才敢玩持续部署。
| 概念 | 核心动作 | 人工介入 | 典型场景 |
|---|---|---|---|
| 持续集成 | 合并代码 + 自动构建测试 | 需要 | 每次 Push 触发 |
| 持续交付 | 自动部署到预发布环境 | 需要审批 | 提测、预发布 |
| 持续部署 | 自动部署到生产环境 | 不需要 | 全自动上线 |
1.2 为什么前端需要 CI/CD？
我经常听到这样的问题：「前端不就是写写页面吗？搞那么复杂干嘛？」
嗯，这话放在五年前可能还行。但现在的前端项目，动辄几十个页面、上百个组件、依赖几十个 npm 包。你手动打包、手动上传、手动部署？
我曾经见过一个团队，上线前靠人工核对文件列表。结果漏传了一个 CSS 文件，线上样式全崩了。你说冤不冤？
我的建议： 前端项目只要超过 3 个人协作，就应该上 CI/CD。这不是锦上添花，是刚需。
1.3 核心收益，我帮你数数
- 问题早发现： 代码合并后立刻跑测试，有问题当场暴露。不用等到上线前才发现。
- 减少重复劳动： 打包、压缩、上传、部署，这些事让机器干。人只做决策。
- 版本可追溯： 每次构建都有记录，出问题了能快速回滚。我记得有一次线上出了 bug，三分钟就回滚到了上一个稳定版本。
- 团队协作更顺畅： 不用再喊「谁又覆盖了我的代码？」。CI 会帮你拦住冲突。
1.4 挑战，也得实话实说
CI/CD 不是银弹。我踩过的坑，说出来给你提个醒。
避坑指南：
- 我曾经因为测试用例写得太少，导致 CI 形同虚设。代码合并了，测试也跑了，但什么都没测出来。
- 还有一次，构建时间太长，每次 CI 跑 40 分钟。团队成员干脆不合并代码了，等下班前才提交。这完全违背了持续集成的初衷。
- 另外，环境一致性也是个坑。本地能跑，CI 上跑不过，多半是环境差异导致的。
1.5 前端 CI/CD 的典型流程
我习惯把流程画成一条线，你感受一下：
代码提交 → 自动安装依赖 → 代码检查（ESLint） →
单元测试 → 构建打包 → 部署到测试环境 →
集成测试 → 审批 → 部署到生产环境每一步都是自动触发的。只有审批那一步，需要人来点一下。
1.6 小结
CI/CD 不是什么高深的技术，它是一套流程规范。说白了，就是让机器帮你做那些重复、容易出错的事。
我个人觉得，前端团队引入 CI/CD 的最佳时机，不是等项目做大了再补，而是从第一个项目就开始。哪怕只是加一个自动 lint 检查，也比没有强。
下一章，我会带你从零搭建一个前端 CI/CD 流水线。到时候咱们手把手过一遍，你就知道这东西到底有多香了。