DevOps流水线中的质量门禁别把闸门装成路障

上个月去一家做企业服务的公司蹲研发流程，刚进门就撞见个开发对着流水线屏幕拍桌子。屏幕上弹着一行红字：单测覆盖率未达阈值，合入被拦截。他盯着那行字看了半分钟，手指点过跳过门禁的按钮，填了个“紧急bug修复”的理由，直接把代码合进了主干。全程不到十秒。

我跑过几十家公司的研发部，十家有八家的质量门禁是这个状态：装的时候轰轰烈烈，用的时候形同虚设，最后变成了大家心照不宣的“摆设”。

门禁不是用来卡人的

很多团队一开始上质量门禁，就是把之前所有能找到的代码规范、测试要求、安全规则全堆进去，恨不得把lint错误数、单测覆盖率、依赖包漏洞、镜像大小、甚至代码注释的行数全卡个遍，阈值还都定得特别高，比如单测覆盖率要90%，lint错误数为0，差一点都不让过。

那个拍桌子的开发跟我吐槽，他改的是个支付回调的边界bug，总共就加了三行代码，之前的单测覆盖率是89.8%，就因为他这三行没写测试，直接卡了。他说他要是补个测试，还要等十分钟跑全量单测，不如直接跳过，反正那三行是边界判断，根本出不了问题。

说白了，门禁的阈值不是越高越好，是要刚好落在“大家跳一跳能够到”的位置。之前有个做电商的团队，一开始把单测覆盖率定到90%，跑了三个月，团队里一半的人都在想办法凑mock用例，根本没人真的去测核心逻辑，后来降到70%，反而没人绕了。因为70%的要求，只要把核心业务模块的用例写了就能达到，不用花额外的功夫凑数。

别把所有规则堆在同个节点

麻烦在于，很多团队的所有门禁规则，全堆在“合入主干”这一个节点上。开发刚提了代码，要等十几分钟，跑完所有的检查，才能知道自己哪里错了。有时候只是少写了个分号，也要等二十分钟才能收到报错，改完再提，又要等二十分钟，一天的时间全耗在等门禁上了。

我之前碰到个后端开发，说他一天提了八次代码，每次卡在同一个lint检查的门禁上，改个标点符号都要等二十分钟，最后他直接把流水线里的门禁超时时间设成了1秒，点一下就过。

质量门禁的第一原则，是让问题在最早的阶段被发现，而不是在流水线的最后一道关卡等着收网。比如lint检查，应该放在开发提交代码的pre-commit钩子上，最多几秒钟出结果，有问题当场改，根本不用等到流水线跑起来。刚提交的代码，门禁只需要卡最基础的语法错误、核心模块的快速单测，等代码合到主干，要打包镜像了，再跑全量单测、覆盖率检查、依赖包漏洞扫描，等要部署到预发环境了，再跑全量的安全扫描、性能测试门禁。这样分层下来，每个节点的检查时间都很短，开发也不用等很久，有问题也能第一时间改。

绕开门禁的代价得够高

很多团队的门禁是“软”的，跳过只要填个理由就行，甚至连理由都不用填，那大家肯定愿意绕。毕竟谁也不想等二十分钟的流水线，就为了一个无关紧要的覆盖率指标。

之前有个做金融科技的团队，一开始跳过门禁只要在研发群里说一声就行，后来改了规则：只要跳过门禁合入主干，导致线上出问题的，直接算进季度的研发质量考核，而且所有跳过的记录，会自动同步到每周的团队周报里，所有人都能看到。过了两个月，他们的门禁跳过率降到了原来的二十分之一都不到。

这事没那么玄。不是说要把绕开门禁的人怎么样，而是要让大家知道，门禁不是摆设，你绕开的话，是要承担对应的责任的。而且规则也不是一成不变的，每个季度要复盘一次，哪些门禁的规则是没用的。比如之前有团队要求代码注释覆盖率要到80%，后来发现大家都是随便凑的注释，根本没人看，就把这个规则从门禁里去掉了，换成了“代码评审评论未处理完成不得合入”的规则，反而更实用。

我见过太多团队花了几十万买DevOps平台，装了一堆质量门禁的插件，最后用不起来，不是门禁的问题，是一开始就把门禁当成了“给开发找麻烦的工具”，而不是帮开发挡问题的工具。你想啊，要是门禁能帮开发把低级错误拦下来，不用等到测试提bug，不用等到线上出问题，那他为什么要绕开？对吧？