群里的消息刷得快到看不清。前端说打出来的包和本地跑的不一样，运维说配置文件漏了改数据库地址，测试说最新的代码根本没部署到测试环境，最后我们三个人对着三台电脑挨个核对版本，折腾到六点才把大促的活动页推上去。
那次之后我们花了整整两周，把团队的CI/CD流程彻底重搭了一遍。
CI/CD从来不是运维一个人的KPI
刚接触CI/CD的团队，十有八九会走这个弯路：把整个流水线的搭建、维护全甩给运维组，开发写完代码直接点合并按钮，根本不管后面的流程跑成什么样。
上次那堆故障的根源就在这——之前的流水线就是运维搭的个空架子，开发合代码的时候甚至都没注意到流水线已经红了三次，以为本地测过就能上。
说实话，这种状态下的CI/CD，和没人用的摆设没区别。
我们一开始调整的时候，也踩过坑。最开始把全量2000多个自动化测试用例全串到了提交环节，只要有人合代码，就得等25分钟才能走完流程。谁忍得了？写代码的老哥手速快，一上午能合四五次，光等流水线就要两个小时，转头就绕过流程手动打包传服务器。
后来我们把流程拆成了两段：提交代码的时候只跑和改动模块相关的增量用例，最多等3分钟；等到凌晨所有人都下班了，再自动跑全量测试。就这一个调整，流水线的周通过率从28%直接涨到了91%。
流水线的速度永远比完备性优先。你搞个半小时才跑完的流程，哪怕设计得再完美，也没人愿意配合，对吧。
那些踩过的流水线反人类设计
我见过太多团队的CI/CD，从设计之初就带着反人类的基因。
比如有个创业团队的流水线，把代码合并和生产发布绑成了同一个触发动作，只要代码推到主干分支，10秒后自动部署到生产环境，连个人工确认的环节都没留。上次运营改活动页的文案，手滑把测试环境的代码推到了主干，直接把正在跑的大促页面换了，半小时算下来损失快二十万。
还有更离谱的，有人为了图方便，把镜像仓库的密钥、数据库的密码全硬编码在流水线脚本里，谁都能点开看。半年前就有个团队因为这个漏洞，被人替换了生产环境的镜像，偷走近十万条用户的手机号数据。
这些设计的核心问题，就是把“自动化”当成了最终目标，忘了CI/CD本来是帮人减少犯错概率的工具。
真正好用的流水线，根本不需要人时刻盯着：你手动打包容易漏改配置，那就把不同环境的参数存在加密库里，打包的时候自动拉取，根本不需要人改文件；你每次上线前要核对版本，那就自动把git的commit hash写到页面的隐藏注释里，出问题一眼就能定位到哪个版本出的错。
小团队别上来就搞全链路DevOps
经常有人问，我们团队就五六个人，要不要花三个月搭一套覆盖代码扫描、安全测试、性能压测、自动发布、监控告警的全链路流水线？
别。
真的别。
我见过最爽的一个小团队，总共7个开发，搭CI/CD只花了两个下午，就三步：第一，代码提交自动跑编译，编译不过直接给提交人发企业微信提醒；第二，编译通过自动跑10个核心冒烟用例，过了自动把包传到测试环境；第三，测试确认没问题，点一下按钮就把包传到预发，过24小时没报错自动推生产。
就这三步，比他们之前手动上线的效率高了不止三倍，关键是没人觉得这是个负担。之前他们手动上线，每次都要三个人配合，打个包传半小时，核对版本花半小时，遇到点小问题还要回滚，一次上线至少耗两个小时。
好的CI/CD从来不是让所有人适应流水线，是流水线适配团队的真实协作节奏。
我们团队之前有个后端老哥，写代码快是快，就是不爱写单元测试。一开始我们想在流水线里卡覆盖率，不到30%不让合代码，结果老哥花了一晚上写了一堆空方法的测试凑数，看得人哭笑不得。后来我们换了个规则，不卡覆盖率了，只要线上出了和他代码相关的故障，就把对应的复现测试加到流水线里，跑过才算完。俩月下来，他负责的模块测试覆盖率居然到了70%，根本没人催。
上次和几个南京做技术的朋友吃饭，有人说CI/CD是成熟技术团队的标配，是要花很多钱、很多精力才能搭起来的高级玩意儿。
其实哪是那么回事。
本质上就是大家都不想再做那些没价值的重复劳动：不想每次上线前熬夜核对包对不对，不想因为一个手滑的操作搞出线上故障，不想每次排查问题都翻半小时聊天记录找对应的上线版本。
你把这些麻烦事兜住了，哪怕你的流水线只有三步，也是好用的。