天天说CI，持续集成技术到底解决了谁的掉发问题？

三年前国庆前的那个周三，南京软件大道的地下室咖啡馆，我跟老周盯着满屏红的控制台，烟灰缸堆了半缸烟蒂。那天我们约好改完最后一个bug就放假，结果两个人各自改了二十天的代码，一合到主干，整个项目直接罢工了。

那滋味，谁熬谁知道。从八点弄到凌晨三点，才勉强把所有冲突改完，还漏了三个隐性bug，上线之后第一天就回滚了。从那之后，老周跟我聊起代码合并，脸都绿。

原来持续集成技术，就是治“合代码恐惧症”的药

很多刚入行的开发听这个词觉得玄乎，什么集成，什么持续，听起来就像大厂搞出来骗钱的概念。说白了，就是帮你解决“合代码必翻车”的毛病。

早些年大家做项目，都是一个人一个分支，你改你的，我改我的，等到要上线了才凑到一起合代码。改的时间越长，代码差异越大，翻车概率就越高。赶上好几个动了同一块代码，改冲突改到你怀疑人生，改完了还不知道哪里藏着问题。

持续集成换了个思路：你别攒那么久再合，改一点，就合一点到公共主干，每次合的时候，自动帮你跑检查、跑测试，有问题马上告诉你，你当场就改。

就像你写作文，写一句改一句错字，比你写完一整篇再回头找错，效率高太多了，也不会等到交卷才发现跑题了。

它不是高大上的工具，是一套改代码的习惯

说实话，我见过太多公司，装个Jenkins搭个流水线，就说自己用上持续集成了，其实换汤不换药。还是各改各的，一周才合一次，流水线跑半天没人看，出了问题照样甩锅。这哪叫持续集成，这叫供了个牌位。

真正的持续集成，核心就八个字：小步提交，快速反馈。跟你用什么工具没关系，你哪怕用git命令加个简单的脚本，能做到每次提交自动测，那就是合格的CI。

我现在待的团队，要求每次提交代码最多改三百行，功能再大都拆成小块，今天做一半，藏起来不影响现有功能，明天再做另一半，每天都合代码到主干。哪怕改底层架构，也拆成一周的小任务，每天合一次，从来没出过那种合完整个项目崩了的事儿。

有人说，我改的是大功能，拆不了怎么办？其实就是懒。用个功能开关把没做好的代码关了不就行了？对用户不可见，对团队其他成员没影响，你想怎么改就怎么改，没必要藏在自己分支里一个月不见天日。

不过话说回来，这么简单的道理，很多人就是想不通。总觉得我改完再合才安全，殊不知越攒越不安全。我见过最夸张的，一个开发在自己分支改了三个月，合代码的时候冲突改了整整一周，最后干脆把主干拉到自己分支重写了一遍，把所有人的改动都覆盖了，差点被团队其他人打出去。

持续集成也不是万能的，踩过的坑真不少

吹了半天，这东西也不是包治百病的神药，我踩过的坑，比你上个月点的外卖还多。

第一个坑，就是烂测试撑不起好CI。很多项目的单元测试，都是为了凑覆盖率写的，根本测不到实际逻辑，改了核心逻辑，单测照样全过，那CI跑了有什么用？还有的项目，单测写得乱七八糟，跑一次要四五十分钟，开发改完两行代码，去喝个咖啡遛个弯回来还没跑完，谁愿意等？最后大家都偷偷跳过CI合代码，CI就成了摆设，还浪费一堆服务器资源。

第二个坑，就是过度设计，把简单的事儿搞复杂。我之前见过一个小团队，才五个人，CI流水线搞了七八道审批，什么测试审核、架构师审核、项目经理审核，改个文档都要走三层审批，本来半天能做完的事儿，拖两三天，这哪是提效，这是添堵。

还有人不管改什么，都跑全量流水线，改一行文档，都要把全项目几千个单测跑一遍，跑一次一小时，纯粹浪费电。现在都有增量测试了，只跑跟改动相关的部分，十几分钟就能出结果，不好吗？

第三个坑，就是把CI当成了挡箭牌。出了问题就说CI过了啊，不关我的事。其实CI只是帮你提前发现问题，不是帮你兜底，该做的测试还是要做，该自己验的还是要自己验，别把所有事儿都扔给流水线。

你想啊，CI能帮你找冲突，能帮你跑单测，能帮你打包，但是你需求理解错了，逻辑错了，CI哪能知道？还是要靠人。

最后说句实在话，持续集成技术，本质上就是帮开发省时间，救发量的。它不是什么用来吹牛逼的大厂黑科技，就是从无数次熬夜合代码的坑里，总结出来的笨办法。

老周现在的团队，早就落地了CI，最近半年朋友圈晒的都是接孩子放学、周末钓鱼，再也没见过他凌晨三点发朋友圈吐槽bug了。

能让你准点下班的技术，就是好技术。对吧？