CI/CD 落地没人说的真实细节
上周帮做电商SaaS的朋友排了个跨了三周的烂摊子。
他们团队算上他一共五个人。
之前每次大促前发版，全组人要熬到后半夜。不是写代码慢。是每次打包，总有谁本地的依赖版本不对，打出来的包不是样式错位，就是支付接口调不通，有次甚至把去年的旧优惠券逻辑带上线，直接亏了小两万。
他们去年就买了某知名流水线平台的年费，折腾了俩月，最后用的功能就是把手动敲的打包脚本丢上去。
钱花了。
罪一点没少受。
真的。
很多团队对CI/CD的认知，从一开始就歪了。
觉得这玩意就是把人要干的打包、传服务器的活，交给机器干。
我真的见过太多团队，花了大几万买的企业级流水线，最后只配了个打包节点。开发写完代码，还是要本地先跑一遍测试，手动把包传上去，流水线就挂在页面上当个摆设，跟你买了个最新款的旗舰手机，只用来打电话发短信一样浪费。
问题出在哪？
你把流水线的定位搞成了“代替人做重复操作”，但实际上它的核心作用，是把所有你之前靠人记、靠人盯的规则，全部固化成流水线的强制节点。
之前那个电商团队的流水线，最开始就是运维搭的个空架子。打包完直接把包丢到测试环境服务器上，测试每天打开环境，十次有八次是白屏。查了半天才发现，流水线服务器装的Node版本是14，开发本地写代码用的是16，光依赖版本差，打出来的包就完全是两个东西。
小型电商团队手动发版熬夜现场
没人规定开发必须跟流水线用一样的环境版本。
靠人提醒？
靠人记？
每次发版前挨个查版本？
别闹了。大家都有自己的活要干，谁能天天记着这些杂事。
我给他们改流水线的时候，没一开始就搞什么高大上的自动灰度、全链路压测。
先拆成了三个零成本就能上的节点。
第一关，代码刚push到分支的时候，先跑1分钟的检查。什么ESLint语法检查，核心模块的单元测试，只要有报错，直接给提交代码的人发企业微信提醒，根本等不到合并代码的时候才发现问题。
第二关，代码合并到dev分支之后，自动用固定版本的Node环境打包，打好的镜像直接推到测试环境。测试打开链接就能测，再也不用等开发手动传包传半小时。
第三关，测试通过打正式tag的时候，流水线自动把对应的镜像推到预发环境，留个审批节点，点一下确认就能上生产。
5人小型团队CI/CD流水线节点示意图
最开始我担心大家不适应。
结果用了第一周，团队的反馈好到意外。
之前开发要花半小时核对的环境版本，现在机器自动搞定。之前测试要等开发传包的时间，现在打开dev分支的链接就是最新的。之前发版要所有人盯着服务器敲命令，现在点一下审批就完事。
哦对，我那个之前手滑覆盖过生产配置文件的同事，现在每次看到流水线跳过所有手动部署的步骤，都要给我发个大拇指的表情。毕竟谁也不想因为手滑，再背个线上故障的锅。
说个真事。
我之前接触过一个二十人左右的创业团队，为了上CI/CD，专门招了个有大厂经验的运维。花了三个月，搭了一套从代码提交到生产全链路的流水线，什么蓝绿部署、灰度发布、安全扫描全加上了。
结果呢？
流水线跑一次要20分钟。团队开发提个代码，要等20分钟才能收到检查结果，有时候赶时间，干脆就把流水线的检查跳过，直接手动合并代码。折腾了三个月，最后流水线还是成了个摆设。
说白了。
小团队搞CI/CD，最忌讳的就是一上来就抄大厂的作业。大厂有几百人的团队，有专门的人维护流水线，你一共五个人，把所有能加的节点都加上，最后光等流水线跑完的时间，就够你写半页新代码了。
那个电商团队的流水线，到现在也没加什么复杂的节点。最开始只有两个步骤的时候，就已经把之前每次发版要花的2小时，压缩到了10分钟。后面的生产审批、自动回滚，都是用了大半年之后，遇到了几次小问题，慢慢加上去的。
说实话。
我从来没见过哪个团队的流水线，是一开始就设计好的。今天觉得某个检查跑太慢，就把它挪到后面的节点。明天发现某个安全扫描能挡住80%的线上漏洞，就给加上。后天把流水线的服务器换成配置更高的，把跑一次的时间从10分钟压到3分钟。
都是磨出来的。
哪有什么完美方案。
上周朋友给我发消息。说他们上周六临时改了个大促的优惠券bug，从提交代码到上线，一共花了12分钟。全程没人加班，改完大家直接去楼下吃小龙虾了。
你看。
这玩意从来不是什么高大上的技术概念。
就是帮大家少熬点夜，少出点没必要的故障的工具而已。
他们团队算上他一共五个人。
之前每次大促前发版，全组人要熬到后半夜。不是写代码慢。是每次打包，总有谁本地的依赖版本不对，打出来的包不是样式错位，就是支付接口调不通，有次甚至把去年的旧优惠券逻辑带上线，直接亏了小两万。
他们去年就买了某知名流水线平台的年费，折腾了俩月，最后用的功能就是把手动敲的打包脚本丢上去。
钱花了。
罪一点没少受。
真的。
别把CI/CD当自动打包工具
很多团队对CI/CD的认知，从一开始就歪了。
觉得这玩意就是把人要干的打包、传服务器的活，交给机器干。
我真的见过太多团队，花了大几万买的企业级流水线，最后只配了个打包节点。开发写完代码，还是要本地先跑一遍测试，手动把包传上去，流水线就挂在页面上当个摆设，跟你买了个最新款的旗舰手机，只用来打电话发短信一样浪费。
问题出在哪？
你把流水线的定位搞成了“代替人做重复操作”，但实际上它的核心作用，是把所有你之前靠人记、靠人盯的规则，全部固化成流水线的强制节点。
之前那个电商团队的流水线，最开始就是运维搭的个空架子。打包完直接把包丢到测试环境服务器上，测试每天打开环境，十次有八次是白屏。查了半天才发现，流水线服务器装的Node版本是14，开发本地写代码用的是16，光依赖版本差，打出来的包就完全是两个东西。
没人规定开发必须跟流水线用一样的环境版本。
靠人提醒？
靠人记？
每次发版前挨个查版本？
别闹了。大家都有自己的活要干，谁能天天记着这些杂事。
把流水线拆成能落地的小动作
我给他们改流水线的时候，没一开始就搞什么高大上的自动灰度、全链路压测。
先拆成了三个零成本就能上的节点。
第一关，代码刚push到分支的时候，先跑1分钟的检查。什么ESLint语法检查，核心模块的单元测试，只要有报错，直接给提交代码的人发企业微信提醒，根本等不到合并代码的时候才发现问题。
第二关，代码合并到dev分支之后，自动用固定版本的Node环境打包，打好的镜像直接推到测试环境。测试打开链接就能测，再也不用等开发手动传包传半小时。
第三关，测试通过打正式tag的时候，流水线自动把对应的镜像推到预发环境，留个审批节点，点一下确认就能上生产。
最开始我担心大家不适应。
结果用了第一周，团队的反馈好到意外。
之前开发要花半小时核对的环境版本，现在机器自动搞定。之前测试要等开发传包的时间，现在打开dev分支的链接就是最新的。之前发版要所有人盯着服务器敲命令，现在点一下审批就完事。
哦对，我那个之前手滑覆盖过生产配置文件的同事，现在每次看到流水线跳过所有手动部署的步骤，都要给我发个大拇指的表情。毕竟谁也不想因为手滑，再背个线上故障的锅。
别追求一步到位的完美流水线
说个真事。
我之前接触过一个二十人左右的创业团队，为了上CI/CD，专门招了个有大厂经验的运维。花了三个月，搭了一套从代码提交到生产全链路的流水线，什么蓝绿部署、灰度发布、安全扫描全加上了。
结果呢？
流水线跑一次要20分钟。团队开发提个代码，要等20分钟才能收到检查结果，有时候赶时间，干脆就把流水线的检查跳过，直接手动合并代码。折腾了三个月，最后流水线还是成了个摆设。
说白了。
小团队搞CI/CD，最忌讳的就是一上来就抄大厂的作业。大厂有几百人的团队，有专门的人维护流水线，你一共五个人，把所有能加的节点都加上，最后光等流水线跑完的时间，就够你写半页新代码了。
那个电商团队的流水线，到现在也没加什么复杂的节点。最开始只有两个步骤的时候，就已经把之前每次发版要花的2小时，压缩到了10分钟。后面的生产审批、自动回滚，都是用了大半年之后，遇到了几次小问题，慢慢加上去的。
说实话。
我从来没见过哪个团队的流水线，是一开始就设计好的。今天觉得某个检查跑太慢，就把它挪到后面的节点。明天发现某个安全扫描能挡住80%的线上漏洞，就给加上。后天把流水线的服务器换成配置更高的，把跑一次的时间从10分钟压到3分钟。
都是磨出来的。
哪有什么完美方案。
上周朋友给我发消息。说他们上周六临时改了个大促的优惠券bug，从提交代码到上线，一共花了12分钟。全程没人加班，改完大家直接去楼下吃小龙虾了。
你看。
这玩意从来不是什么高大上的技术概念。
就是帮大家少熬点夜，少出点没必要的故障的工具而已。