CI/CD 别搭成给老板看的花架子

上周去雨花软件谷蹭客户的免费咖啡，碰到之前认识的后端组长，拉着我吐槽了快半小时。

他说他们团队去年咬咬牙花了十几万，搭了一整套CI/CD系统，什么流水线可视化，什么部署状态大屏，给老板汇报的时候特别好看。结果呢？每次发版还是要全组人熬到半夜。上次因为流水线跑到一半卡了镜像仓库的认证，三个人在测试环境对着日志扒到三点多，眼睛都红了。

你以为的CI/CD 可能只是自动点了个构建按钮

我当时凑过去看了眼他们的流水线配置，差点笑出声。整个流水线就三个步骤：拉代码，跑maven打包，把打好的jar包推到镜像仓库。

没静态检查。

没单元测试。

甚至连部署到测试环境的步骤都没有。

说白了，这就是个帮开发省了“本地敲打包命令”功夫的脚本，离真正的CI/CD差了十万八千里。

很多团队对CI的理解从根上就错了。CI的核心根本不是自动打包，是每次有代码提交，就自动跑一遍所有能跑的检查——代码风格对不对，核心模块的单元测试通不通过，有没有把线上的配置硬编码到代码里——任何一步不通过，代码根本没机会合进主分支。不是等攒了半个月的代码，攒了好几个G的改动，到发版前才开始拉分支合并，那时候冲突能解决到你怀疑人生。

之前那个组长说，他们团队之前因为单元测试写得烂，跑一次要十几分钟还经常随机挂，大家为了图快，直接把测试步骤从流水线里删了。结果上个月有个新来的开发，改订单满减逻辑的时候把判断条件写反了，本地测了个边界值就提交了，镜像正常打出来，发布到生产之后，满屏的计算错误，客服的消息直接炸了锅。要是当时流水线里多一步核心逻辑的单元测试，根本不会出这种破事。

流水线里藏的坑 踩过一次就长记性

我见过太多团队搭CI/CD的时候，追求的就是“流程完整”，恨不得把从代码提交到生产部署的每一步都塞进流水线，跑一次要四十多分钟。

慢。

真的慢。

开发提交完代码，根本不愿意盯着屏幕等流水线跑完，切出去改个别的需求，等半小时收到失败通知，都记不清刚才改了哪几行代码。算下来，比自己本地跑一遍测试还费时间。

还有个更离谱的坑。有个团队为了追求“自动化程度”，把CD的步骤直接配成了主分支一合并，自动部署到生产环境，连个审批环节都没有。上次有个开发手滑，把测试环境的数据库连接地址推到了主分支，流水线自动部署完，整个生产站直接连到了测试库，挂了快二十分钟，才有人反应过来。

说实话，我每次看到这种配置都捏一把汗。流水线不是越自动越好，是要真的顺着开发的日常工作流走，不然就是给团队埋雷。

真把CI/CD用顺 根本不用搞的太复杂

别被那些厂商吹的“全链路DevOps解决方案”忽悠了。工具是死的，人是活的。很多团队花了几十万买的商业平台，最后用起来还不如自己搭的三个简单步骤。

我之前在河西见过一个做本地生活的小团队，总共8个开发，没买任何商业工具，就用开源的GitLab CI搭了套流水线，到现在跑了快两年，发版故障率降了七成，每次发版最多花二十分钟。

他们的配置真的特别简单。

主分支加保护。只要提交的代码没过最快的静态检查和核心模块的单元测试，根本合不进去。这部分检查他们拆成了快检流程，跑一次控制在3分钟以内，开发提交完马上就能拿到结果，不用等半天。

代码合进主分支之后，自动打镜像，部署到预发环境，自动跑一遍核心流程的冒烟测试——比如用户能不能正常登录，下单流程能不能走通。这步跑个十分钟，没问题了，就弹个审批提醒，当天值班的开发点一下确认，就自动推到生产环境。

就这么点东西，没有花里胡哨的可视化大屏，没有复杂的权限配置，反而用的特别顺。

上周再碰到那个软件谷的后端组长，他说已经把之前跳过的核心单元测试补了一半，把原来四十多分钟的流水线拆成了快检和全检两个部分，上次发版大家没熬夜，下午三点就把新功能顺顺利利上了线。

挺好。