上周去南京软件大道的一家创业公司蹭饭，技术总监拉着我吐槽，说花了三个月搭的CI/CD流水线，现在开发还是每周五晚上蹲在公司改线上配置，合着之前的钱都打了水漂。
我打开他们的GitLab CI配置看了五分钟，就懂问题在哪了。
流水线不是配完就万事大吉
很多团队对CI/CD的理解就是“代码提交自动跑测试，过了就自动发版”，完全忽略了这个工具本来是用来降低团队协作成本的，不是用来给开发添堵的。
他们的流水线里，测试用例还是三个月前产品刚立项时写的，现在业务加了三个新的分支逻辑，测试用例根本没覆盖，就算跑全了也发现不了问题。更离谱的是，所有环境的配置变量都硬编码在CI的加密变量库里，开发要改个测试环境的数据库地址，得提申请找运维审批，等流程走完半小时都过去了，还不如自己直接登服务器改快。
这不是个例。我见过至少二十个团队，把CI/CD当成运维的KPI，开发连看都懒得看一眼。
这里要拎清楚两个最基础的概念：CI的核心从来不是自动跑测试，是让开发每天都把代码合到主干，避免攒到最后出现几小时都解不完的合并冲突。很多团队的开发习惯是攒一周的代码，周五下班前一次性合到主干，光解冲突就能花一晚上，出了问题根本不知道是哪行代码导致的。持续集成就是要把这个大的拆分动作，拆成每天的小提交，就算出了问题，改起来也快。
别让流水线变成新的堵点
不少团队搭流水线的时候，为了追求“万无一失”，把所有能加的检查项全堆上去：代码格式检查、单元测试、集成测试、依赖安全扫描、接口性能压测，一套流程跑下来少说四十分钟。
谁受得了？
我之前接触过一个做电商的团队，之前的流水线就是这么配的，开发提交个修复文案的小改动，要等四十分钟才能知道能不能合，大家干脆绕开流水线，直接往主干上推代码，最后所谓的自动化流程完全成了摆设。后来我们把测试拆成了两级：核心交易链路的测试，每次提交代码都跑，耗时大概3分钟；边缘功能的测试，只有合到主干的时候才跑，总共算下来整个流水线耗时不到8分钟。
真的，别迷信全量检查，没用的。
还有个常见的坑，就是为了过安全扫描，把所有第三方依赖都锁到三年前的旧版本，结果新的业务功能根本跑不起来，最后还是绕开流水线手动发版。流水线的存在是为了给开发提效，不是为了增加审批环节，所有会拖慢提交速度的设计，最后一定会被大家自发绕开。
落地的时候别贪多
说实话，我见过太多团队一开始就想一步到位，从代码提交到生产发布全链路自动化，搞了半年流水线还是跑不通，最后又回到手动发版的老路。
真不用这么急。
刚启动CI/CD落地的团队，先把最基础的一步做好就行：每次开发提交代码，自动跑核心模块的单元测试，过了才能合到主干。等大家习惯了每天提交代码的节奏，再慢慢加自动发测试环境的步骤——反正测试环境本来就没人用，就算发错了也无所谓。等测试环境的发布稳定了，再搞预发环境的自动同步，最后才是生产环境的灰度发布。
也不是所有团队都要追求全自动的持续部署。比如做To G项目的，上线要走层层审批，那做到持续交付就够了：代码随时可以打包出可用的版本，等审批过了直接推到线上，不用临时凑代码、改配置。
还有个容易被忽略的点：要让对应的开发负责自己写的代码的流水线检查。比如某个模块的单元测试跑挂了，就找写这个模块的开发来改，不能全扔给运维排查。不然运维永远在帮开发擦屁股，开发也永远搞不懂自己的代码到底有什么问题。
上周我给那个南京的创业公司改了两个配置：把硬编码的环境配置挪到了Git仓库的配置目录里，开发要改的话直接提MR，审批过了自动同步到流水线；又把跑了四十分钟的测试拆成了两级，现在整个流水线跑十二分钟。
昨天那个技术总监给我发消息，说这周终于不用周五蹲公司了，周六带孩子去玄武湖玩了。