第1章 常见误区
第1章 常见误区
1.1 "流水线=自动化"？别把脚本当流水线
你有没有见过那种"CI/CD流水线"？一堆 shell 脚本串起来，npm run build 后 scp 到服务器，再 ssh 执行 pm2 restart。项目里人一多，这玩意儿就变成"谁改了就跑一遍"的野路子。
我上一个项目就栽在这儿。当时老板说："搞个自动化部署，别手动发版。" 我二话不说，写了 300 行 bash，把构建、测试、打包、上传全串了。一开始看着挺爽，跑得快，日志也清楚。结果呢？第二天 QA 打电话来："你们刚发的版本，登录页面白屏。" 一查，发现是构建时忘了加 --mode production，因为脚本里写死了 --mode dev。
问题在哪？ 不是脚本不够多，是没把"流水线"当成一个有状态、可验证、可回溯的系统。你只是把"手动流程"搬到了自动化，本质没变。
流水线的核心是 控制流程的确定性。你要能说清楚：哪个步骤失败了？失败后要不要继续？是否需要人工干预？能不能回滚？这些脚本都给不了你。
我后来改了，用 GitLab CI 写 YAML，每个 job 明确声明输入输出，加了 artifacts 保存构建产物，用 allow_failure 区分关键步骤和非关键步骤。现在跑一次，我都能画出一张执行图------不是为了炫技，是真能定位问题。
别把"能跑"当成"好用"。你写的不是脚本，是生产级的发布流水线。
1.2 一个流水线跑所有环境？别把生产当沙盒
我们团队有个"经典操作"：一个流水线，dev、staging、prod 三个环境全走一遍，靠 if 判断环境变量来控制行为。听起来很"优雅"？我当初也这么干，结果酿了大祸。
那会儿 staging 环境改了个数据库配置，把 enable_ssl: false 误写成 true。流水线跑 staging 时正常，但 prod 一跑，数据库连不上，直接把线上服务干崩了。
为什么出问题？ 因为环境隔离缺失。你在一个流水线里混合了测试、预发、生产，等于把"测试车"和"出租车"混在一起开。
我后来学乖了：每个环境独立流水线，prod 流水线只允许从 main 分支触发，且必须有审批（merge request + 人工 review）。staging 用 staging 分支，自动部署，但只允许 24 小时内自动清理。
关键不是"能不能跑"，是"能不能跑得安全"。生产环境的流水线，必须是"只读"的------你只能触发，不能改配置，不能跳步骤。
别拿线上当实验场。流水线不是万能药，它只是你控制风险的杠杆。
1.3 测试全靠自动化？别让"通过"骗了你
我们有次上线，CI 流水线所有测试都绿了，结果用户一用就崩溃。查了 logs，发现是内存泄漏。测试用例跑完就结束，没监控内存。
问题出在哪？ 测试通过 ≠ 系统稳定。自动化测试只验证"功能对不对"，不验证"系统能不能扛住"。
我去年在一个金融系统里，CI 流水线里加了 100 个单元测试，全绿。结果上线后，高并发下 API 响应延迟飙升，CPU 100%。查了才发现，有个循环没加 break，测试用例只跑了 10 次请求，根本没暴露问题。
后来我改了：测试要分层，且要带负载 。 - 单元测试：快速，只测逻辑 - 集成测试：跑完整链路，但用 mock 数据 - 压力测试：用 k6 模拟 1000 并发，跑 5 分钟，看内存、CPU、响应时间是否稳定
流水线里加个 stress-test job，失败就阻断发布。不是为了"好看"，是真怕线上崩。
别让自动化测试成了"自我安慰"。它不是保险，是第一道防线。
1.4 流水线越长越靠谱？别把"复杂"当"严谨"
我见过一个项目，CI/CD 流水线写了 120 行 YAML，有 23 个 job，分成 build、test、lint、security-scan、docker-build、deploy-dev、deploy-staging、notify-ops...... 看着像极了"高级架构"。
但没人知道哪个 job 是关键，哪个是冗余。有一次 notify-ops 脚本因为网络问题失败，整个流水线就卡住，一查发现是 curl 超时。可这个通知根本不影响发布，它只是"顺便发个邮件"。
流水线不是越复杂越安全，而是越清晰越可靠。 你得问自己：这个步骤，真的必要吗？如果它失败，后果是什么？能不能合并或取消？
我后来把流水线拆了： - build + test 合并为一个 job，失败直接中断 - security-scan 放在 pre-merge 阶段，不是发布时才跑 - notify-ops 放到独立 cron job，不阻断发布流程
现在流水线从"巨型黑盒"变成"可读的流程图"。关键路径清晰，失败能快速定位。
别把"花哨"当"专业"。真正靠谱的流水线，是别人一看就懂，你一改就怕的。
1.5 人工审批=万能药？别用"人"补机器的坑
有个项目，prod 流水线必须人工审批，老板说："安全第一，不能自动发。" 我当时觉得挺对，加了审批环节，结果发现： - 审批人不是开发，是产品经理，根本看不懂代码 - 审批流程卡在"等人"，上线延迟三天 - 有次改了个小 bug，审批人手滑点了"通过"，结果把线上数据删了
人工审批不是万能药，它是"兜底"，不是"主控"。 你不能指望一个人去理解一个复杂流水线的所有风险。而且人会疲劳、会误操作。
我后来改了： - 审批只用于高危操作（如数据库变更、重大配置修改） - 所有变更必须带 changelog 和 risk-level 标记 - 审批人必须是当天值班的 SRE，且必须在 1 小时内响应
现在，流水线能自动识别"高风险变更"，自动触发审批，而不是"所有都等人工"。
别用"人"来弥补流水线的设计缺陷。如果你的流水线必须靠人来"把关"，那说明它本身就不够健壮。
王工的个人感悟
写这章时，我翻了自己十年前的 CI 配置，那玩意儿现在看简直像"代码遗物"------混乱、冗余、靠人肉兜底。 现在的流水线，不是为了"跑得快"，而是为了"跑得稳"。 你得像看自己的孩子一样，知道它每个步骤在想什么，哪里会卡，哪里会哭。
别追求"全自动"，要追求"可控制"。 真正的 CI/CD，不是机器替代人，而是让人从重复劳动里解脱，去关注真正重要的事：系统稳定性、发布节奏、风险防控。
别怕改，流水线就是活的。 你踩过的坑，都该变成你流水线的"防错点"。