持续集成技术不是点个按钮：我踩过的构建坑
上周三凌晨一点四十，我盯着屏幕上一行红字：ERROR: Job failed: exit code 1。旁边是同事发来的消息：你那个分支能合吗？我回，等等，持续集成技术还在跑。那一刻我特别想把 Jenkins 的图标从浏览器标签里删了——当然没删，第二天还得靠它吃饭。
Git分支合并前持续集成构建状态检查示意图
持续集成流水线从代码提交到构建通知的阶段流程图
再说个容易被忽略的：流水线不是越长越安心。有人觉得把所有测试都塞进 PR 触发里，才叫安全。可如果全量集成测试要跑四十分钟，大家就开始绕路。小提交攒成大提交，或者直接 --no-verify。你赢了覆盖率，输了习惯。更现实的做法是分层：提交时跑快检查，合并后跑中等测试，夜里跑全量回归。不是所有车都要上同一条赛道。
那些把 CI 搞成摆设的坑
测试不稳定，是特别耗人的一种。今天挂，明天过，重跑三次绿了。然后团队学会一句话：重跑一下试试。这句话一出来，持续集成技术的公信力就开始漏水。因为没人知道红色到底代表代码有问题，还是机器心情不好。处理方式也简单也难：把不稳定测试隔离出来，标记，限期修，别让它在主流水线里反复诈尸。
密钥。这个真要命。有次我在一个公开仓库的 CI 日志里看到数据库密码，明文。应该是脚本里 echo 出来的。CI 环境变量不是保险箱，日志会留痕，缓存会留痕，制品也可能带进去。凭据要放 secrets，掩码要开，权限要收。别等出事再删仓库。删了也没用，fork 可能已经飞了。
还有环境漂移。本地跑得好好的，CI 上挂。多数时候不是玄学，是版本不一致。本地 Node 18，CI 上 Node 16；本地装了某个全局包，CI 没有；时区不一样，日期测试挂了。解决办法很土：把环境也当代码，镜像固定版本，依赖锁文件提交，别让“我这儿能跑”成为口头禅。
缓存也是双刃剑。缓存命中时快得飞起，缓存污染时错得离谱。依赖升级了，缓存没更新，构建出来的东西像薛定谔的猫。该失效的 key 要失效，缓存策略要跟锁文件挂钩。别为了省三分钟，搭进去一晚上排查。
CI 不是万能药，它也有边界
持续集成技术解决的是早发现问题。它不负责证明软件没 bug。代码评审、探索性测试、灰度发布、监控告警，各干各的活。你让 CI 把所有这些都包了，它只会变成一头跑不动的骆驼。
有些场景反馈时间天然短不了。嵌入式要烧板子，游戏要打完整包，数据库迁移要起真实集群。这时候别硬追求“每次提交全跑完”。分层，异步，夜间跑重活。能在十分钟内告诉开发者“主干没碎”，已经很值。
小团队呢？一个人，两周一上线，测试也没几个。要不要上持续集成技术？可以，但别一上来搭复杂流水线。先保证每次推送到主干都能编译，跑几个关键测试。哪怕只是一个 lint 加一个冒烟测试。它的意义不是流程好看，是让你在周五下午合并时，心里有点数。
凌晨两点那条红字，我后来修好了。一个时区配置写错。挺蠢的。但如果没有持续集成技术，这个错会漂到预发环境，再被测试同学抓出来，然后群里又是一轮“谁改的”。早发现，哪怕只早十分钟，也够你少掉几根头发。
所以别把持续集成技术当摆设，也别当许愿池。它像刷牙。天天做很烦，不做会疼。疼的时候，别怪牙刷。
先别急着装 Jenkins，先问一句：你多久合一次代码
持续集成技术不是某个工具。真的。它的核心动作很朴素：频繁合并，频繁验证。一天一次也行，一天五次也行，每次 push 都跑也行。关键是“合”这个动作别拖。分支拖一个月，最后不是代码冲突，是人和人之间的冲突。你改的订单逻辑，同事改了支付回调，测试环境一跑，订单状态机直接裂开。然后大家围在会议室里对日志。谁都不想。 我见过一种团队：Jenkins 装了三台，流水线页面很漂亮，红绿指示灯比交通灯还全。但大家还是两周合一次代码。那这套持续集成技术，说白了只是自动跑测试的闹钟。闹钟响了，你按掉，继续睡。问题不在闹钟。Git分支合并前持续集成构建状态检查示意图
一条持续集成技术流水线，到底在跑什么
从你敲下 git push 那一下开始。Webhook 发给 CI 服务器。服务器去拉代码。然后装依赖、编译、跑静态检查、跑单元测试、跑集成测试、打镜像、推制品库、发通知。中间任何一步挂了，反馈就回到你的 PR 或者聊天群里。 听起来很直白，对吧？魔鬼在时间。你装依赖六分钟，单测九分钟，串行跑完十五分钟。开发者点完提交，去倒杯水，水喝完还没完，于是切去干别的。等通知回来，人已经在另一个上下文里了。修 bug 的成本，悄悄涨了一截。 我们以前有个服务就这样。每次构建十五分钟起步。后来干了三件事：依赖缓存，把 node_modules 或者 Maven 本地仓库挂上；单测拆并行，按模块分片；增量编译，别每次都从头来。压到四分半。不是炫技，是体验变了。从“等它跑完再说”变成“顺手看一眼”。持续集成技术真正的产出，不是那个绿色对勾，是短反馈回路。持续集成流水线从代码提交到构建通知的阶段流程图
再说个容易被忽略的：流水线不是越长越安心。有人觉得把所有测试都塞进 PR 触发里，才叫安全。可如果全量集成测试要跑四十分钟，大家就开始绕路。小提交攒成大提交，或者直接 --no-verify。你赢了覆盖率，输了习惯。更现实的做法是分层：提交时跑快检查，合并后跑中等测试，夜里跑全量回归。不是所有车都要上同一条赛道。
那些把 CI 搞成摆设的坑
那些把 CI 搞成摆设的坑
测试不稳定，是特别耗人的一种。今天挂，明天过，重跑三次绿了。然后团队学会一句话：重跑一下试试。这句话一出来，持续集成技术的公信力就开始漏水。因为没人知道红色到底代表代码有问题，还是机器心情不好。处理方式也简单也难：把不稳定测试隔离出来，标记，限期修，别让它在主流水线里反复诈尸。
密钥。这个真要命。有次我在一个公开仓库的 CI 日志里看到数据库密码，明文。应该是脚本里 echo 出来的。CI 环境变量不是保险箱，日志会留痕，缓存会留痕，制品也可能带进去。凭据要放 secrets，掩码要开，权限要收。别等出事再删仓库。删了也没用，fork 可能已经飞了。
还有环境漂移。本地跑得好好的，CI 上挂。多数时候不是玄学，是版本不一致。本地 Node 18，CI 上 Node 16；本地装了某个全局包，CI 没有；时区不一样，日期测试挂了。解决办法很土：把环境也当代码，镜像固定版本，依赖锁文件提交，别让“我这儿能跑”成为口头禅。
缓存也是双刃剑。缓存命中时快得飞起，缓存污染时错得离谱。依赖升级了，缓存没更新，构建出来的东西像薛定谔的猫。该失效的 key 要失效，缓存策略要跟锁文件挂钩。别为了省三分钟，搭进去一晚上排查。
CI 不是万能药，它也有边界
CI 不是万能药，它也有边界
持续集成技术解决的是早发现问题。它不负责证明软件没 bug。代码评审、探索性测试、灰度发布、监控告警，各干各的活。你让 CI 把所有这些都包了，它只会变成一头跑不动的骆驼。
有些场景反馈时间天然短不了。嵌入式要烧板子，游戏要打完整包，数据库迁移要起真实集群。这时候别硬追求“每次提交全跑完”。分层，异步，夜间跑重活。能在十分钟内告诉开发者“主干没碎”，已经很值。
小团队呢？一个人，两周一上线，测试也没几个。要不要上持续集成技术？可以，但别一上来搭复杂流水线。先保证每次推送到主干都能编译，跑几个关键测试。哪怕只是一个 lint 加一个冒烟测试。它的意义不是流程好看，是让你在周五下午合并时，心里有点数。
凌晨两点那条红字，我后来修好了。一个时区配置写错。挺蠢的。但如果没有持续集成技术，这个错会漂到预发环境，再被测试同学抓出来，然后群里又是一轮“谁改的”。早发现，哪怕只早十分钟，也够你少掉几根头发。
所以别把持续集成技术当摆设，也别当许愿池。它像刷牙。天天做很烦，不做会疼。疼的时候，别怪牙刷。