上个月去杭州见个做SaaS的朋友，吐槽说他们团队半年前咬咬牙上了CI/CD，花了小两万买的商业工具，现在全组人都绕着走。
为啥？
搭的流水线太烂了。
每次提交代码，要跑全量单元测试、全量接口测试、代码扫描、镜像构建、部署测试环境，整套流程跑下来要27分钟。开发小哥改个页面的按钮颜色，都要等半天才知道有没有提交成功。谁受得了？最后大家干脆本地测完就手动推生产，上个月漏了个客户权限的判断逻辑，给对方赔了两万多的服务费。
你搭的流水线为啥没人用
说实话，这不是CI/CD本身的问题，是很多人从一开始就把这东西理解错了。
总觉得要照着大厂的公开文档抄，把所有流程都自动化才叫专业。人家几百人的研发团队，跨好几个业务线协作，流程严点、慢点是应该的，你们十个人的小团队，凑什么热闹？
我见过太多团队，把流水线搞成了提交代码的拦路虎。本来大家写代码的节奏是顺的，改完提交，等个几十秒看到没问题，就可以接着写下一个需求，结果你整个二十多分钟的等待，换谁都想绕开。
真的，工具是给人用的，不是给人添堵的。
之前有个做电商的小团队，一开始搭流水线也是抄大厂的配置，提交就跑全量，最后全组人都烦了。我去帮他们调整的时候，第一个要求就是，开发日常提交dev分支的阶段，整个流程必须压在1分钟以内。只跑静态代码检查，还有和改动文件相关的单元测试，其他的全删掉。调整完第一次跑，32秒就出了结果，开发小哥当场说，这才像个能用的工具。
别把流水线搞成大杂烩
很多人搭流水线的时候，总想着一劳永逸，所有步骤全绑在一个触发条件上。完全忘了不同阶段的校验需求，本来就是不一样的。
日常提交代码的时候，你要的是快速反馈，告诉开发者有没有语法错误、有没有单元测试跑挂，没必要跑那么多耗时的集成测试。等代码合并到公共测试分支了，这时候再跑全量的接口测试，构建镜像部署到测试环境，让测试同学能直接拿到最新的版本，这个阶段慢一点没关系，5分钟以内大家都能接受。真到了要发生产版本的时候，再手动触发流水线，跑全量的回归测试，依次部署到预发、生产环境，这时候就算跑十几分钟也没人有意见，毕竟发版本来就是要谨慎的事。
还有个特别容易被忽略的细节：流水线失败的通知。
之前有个团队，只要流水线挂了，就往100多人群的企业微信里发消息，@所有人，附带上失败的日志链接。结果大家群消息多了，直接把那个群设成了免打扰，最后生产环境部署失败了，过了两个小时才有人发现。改完特别简单，失败了就直接@提交代码的那个人，把失败的具体步骤标出来，日志直接定位到报错的那一行，别让人家翻几百行的输出找错。
那些省下来的时间才是真收益
很多人算CI/CD的投入产出，总觉得是省了多少手动部署的时间。其实真不是。
我接触过的团队，调整完流水线之后，最直观的变化根本不是部署快了多少，是大家敢频繁提交代码了。
搁以前，大家总攒个三五天的代码，凑到发版日一起提交，万一出了问题，根本不知道是哪段代码搞出来的，排查都要半天。现在改完一点就提交，几十秒就知道有没有问题，出了bug一眼就能定位到是哪次改动，排查效率高了不知道多少。
上次那个电商团队，调整完流水线之后，618大促前一天，发现库存校验的逻辑有问题，从产品提bug、开发改代码、提交、跑流水线、部署到生产，总共花了18分钟。搁以前，至少要等3个小时的发版窗口，搞不好那几个小时的订单就要少几十万。
当然也别把CI/CD吹成银弹。
要是团队连基本的单元测试都写不全，代码耦合的一塌糊涂，你搭个再漂亮的流水线也没用。跑出来的结果都是错的，反而更耽误事。我见过太多团队，花了大价钱买最贵的CI/CD工具，结果测试用例都没写全，最后流水线成了个摆设，钱全打水漂了。
别总想着一步到位搞个完美的流水线。
先从最痛的点开始改。比如原来手动部署经常出错，那就先把部署这一步自动化，跑顺了再加静态检查，再加单元测试，慢慢迭代。比你照着教程抄一套看起来完美的配置，有用多了。