去年11月在南京软件谷的共享办公区，我蹲在朋友的创业团队里蹭咖啡，刚好赶上他们月度上线。
已经凌晨两点了。
三个开发挤在一台服务器前面，屏幕上开着Xshell、文件管理器、还有监控面板的网页，旁边的黄焖鸡米饭外卖盒还堆在脚边，汤都凉透了。
累。真的累。
很多人听过CI/CD，总觉得是大厂工程师才玩得转的复杂工具，说白了就是把原来手动传包、改配置、重启服务这些重复操作，写成自动执行的流水线，省得人在这些破事上浪费时间。但就这么简单的东西，我见过太多团队要么踩坑踩到大半，要么干脆用成了团队的负担。
被手动上线支配的恐惧
我凑过去看了眼他们的上线流程，差点把刚喝的咖啡喷出来。
开发先在本地把项目打包成war包，通过ftp传到测试服务器，解压之后手动改配置文件里的数据库地址，重启服务，喊测试过来点一遍核心流程。等测试说没问题了，再把war包重新传一遍生产服务器，再改一遍生产的配置，再重启，整个过程全靠每个人脑子里记的步骤，连个像样的操作文档都没有。
上次上线的时候，后端小哥手滑把测试环境的配置传到了生产，直接导致支付接口连到了测试库，半小时内收了二十多个用户的投诉，连夜回滚到凌晨四点。
说实话，这种流程我刚工作的时候也经历过。那时候上线前要提前三天发公告，整个部门都要待命，就怕出问题。但现在都快2025年了？哦不对，别纠结年份，反正很多小团队总觉得CI/CD是大厂专属，自己人少业务简单，手动传包就够了。
但你算过没有？每次上线花的时间，还有出问题的风险，加起来其实比搭一套CI/CD的成本高多了。我那个朋友的团队，之前每个月至少要花10个人小时在上线的重复操作上，还不算出事故之后的补救成本。
别把CI/CD搞成团队的新负担
我见过很多团队一上来就搞最复杂的方案，买最贵的商业CI/CD工具，把所有能想到的检查项都塞到流水线里。
比如代码提交之后，先跑代码风格检查，再跑静态安全扫描，再跑全量单元测试，再跑集成测试，再跑性能测试，最后还要自动生成测试报告。跑一次要25分钟。
换你你愿意提交代码吗？
我上次见的那个团队，开发为了少等流水线，干脆把代码堆到一周才提交一次，合代码的时候冲突一大堆，解决冲突的时间比写新功能还久。这哪是CI/CD，这是给开发添堵对吧？
CI/CD的核心是帮人省时间，不是给人加流程。要是搭出来的流水线反而让开发更麻烦，那不如回去手动传包，至少不用等那几十分钟的流水线跑批。
不过话说回来，也不能完全没规则。比如你要是流水线里啥检查都没有，那随便谁提交个代码都能直接上线，那跟手动上线也没区别。我见过最离谱的小团队，流水线就三步：拉代码，打个zip包，直接传到生产服务器。上次有个开发把本地的debug配置传上去，直接把接口的报错信息全暴露给了用户，还有人在里面看到了数据库的账号密码。
小团队怎么用最少的成本跑通闭环
我后来给朋友的团队搭的那套CI/CD，总共花了不到一下午，根本没买任何工具。他们用的是GitHub托管代码，直接用免费的GitHub Actions就够了。
刚搭的时候先搞最基础的：只要往主分支提交代码，就自动跑单元测试。测试过了才允许合并PR，没过的话直接给提交人发邮件提醒。这一步先把最基础的质量关把住，免得有编译错误的代码合进去。
搞定测试这关之后，再配下一步：单元测试过了之后，自动把代码打成Docker镜像，传到阿里云的镜像仓库。小团队尽量用容器化部署，别再折腾直接传包的老路子，容器的一致性比手动传包好太多，根本不会出现测试环境能跑生产跑不起来的问题。
等镜像跑顺了，最后加部署环节：镜像打好之后，自动部署到测试环境，给测试同学发个企业微信消息，直接就能测。等测试没问题了，开发只需要在Actions的页面上点一下”部署到生产”，就自动把最新的镜像拉到生产服务器上重启，整个过程不到3分钟。
就这么简单的三步，他们之前每次上线要花3个人2小时，现在只要一个人点一下按钮就行。上次他们搞大促的临时上线，下午五点改完需求，五点十分就部署上去了，测试完直接上线，整个团队六点就准时下班去吃火锅了。那个后端小哥说，这是他工作三年来第一次大促当天准点走。
上周我又收到他的消息，说他们上周搞了三次紧急上线，全都是10分钟之内搞定，整个团队这周已经连续四天准点下班了。
真的，技术工具好不好，从来不是看有多复杂，是看能不能帮人省点时间，多留点精力干该干的事。