去年在徐庄软件园蹲的那个20人小团队，说出来没人信。
每次版本迭代发版，全组人都要熬到凌晨一两点。
太痛了。
谁干谁知道。
后端把代码提交完，运维要手动拉包、改配置、传服务器、重启服务，测试要挨个对着测试用例点一遍，但凡中间哪个环节漏了个步骤，或者配置文件里的数据库地址写错了，第二天线上崩了全组都要爬起来修。有次大促前发版，运维抱着笔记本蹲在机房走廊啃着凉汉堡，改了三次配置才把服务跑起来，整个办公室连空调都开得比平时低两度，就怕谁急得出汗把键盘泼了。
那次之后我们痛定思痛。
拉着后端、测试、运维三个人凑了个下班之后的小会，就盯着一件事：以后再也不能有人抱着笔记本手动敲命令部署了，哪怕慢一点，也要把流程先跑顺。
别把CI/CD当成大公司的专属玩具
最开始我对这玩意儿的印象就是大厂玩的花活，什么几百人的团队搞复杂的流水线，跟我们这种小团队有什么关系？
真的是坐井观天。
别被缩写吓住，CI就是每次有人往主分支推代码，系统自动跑单元测试、代码扫描，有问题直接打回去，不让烂代码混进仓库；CD就是测试通过之后自动打包成镜像，按规则部署到对应环境，不用人手动敲那一堆敲错一个字符就崩的命令。
之前我们总觉得，就几个人的团队，代码都是大家互相看着写的，哪有那么多问题？直到某次开发小哥赶进度，把本地调试的硬编码接口直接提交到了主分支，测试过了半天才发现环境里的用户列表全是乱码，浪费了整整一下午的测试时间。
CI/CD的核心根本不是“自动跑”，是把不可控的人为环节全部钉死在流程里，哪怕你团队只有三个人，也总有赶进度脑子发懵的时候，系统可不会犯这种错。
踩过的坑能写满半本便签
说实话，最开始配流水线的时候我真的想砸键盘。
光把测试环境的镜像源配错就折腾了整整一下午，最后发现是公司内网的DNS把私有仓库的地址解析到了公网的测试服，等于我们每次拉镜像都在从公网下别人的测试包，跑出来的结果全是错的。
还有最开始的规则设得太死，哪怕开发改了个README的文件，系统也要把所有测试跑一遍，等二十多分钟才给反馈，大家都嫌麻烦，干脆直接把流水线关了，回到手动部署的老路上去。
哦对，还有个更蠢的坑，我们最开始把生产环境的部署规则设成了“主分支有提交就自动发”，结果某次开发改了个小bug提交，直接把还没灰度验证的版本推到了生产，幸亏那天流量不大，回滚只花了五分钟，现在想起来还后背发凉。
后来我们慢慢摸出了门道，规则都是一点点加上去的，不是一开始就搞成铁板一块。
改文档不触发测试，只有代码目录有变动才跑流水线；主分支合并之后先自动部署到测试环境，等测试点完确认，再手动点一下按钮发预发，灰度跑满两小时没报错，才允许推生产。
就这么个破流程，我们改了快一个月才顺。
小团队落地别上来就搞全套
见过不少团队一上来就抄大厂的配置，什么代码扫描、安全检测、性能测试、灰度发布、自动回滚全给加上，光搭流水线就花了两周，最后大家用起来嫌麻烦，直接闲置了。
小团队的CI/CD，先解决最痛的那个问题就行。
你要是最烦手动部署，就先把“提交代码之后自动部署到测试环境”这一步跑通，别的什么扫描啊测试啊，后面慢慢加。
你要是总漏了跑单元测试导致线上出bug，就先把“提交代码自动跑单元测试，过不了不让合并”这一条配上，别的都不用管。
等你用了半个月觉得顺了，再慢慢加别的环节，总比一开始搞个大而全的摆设强吧？
上个月我们组发版，下午三点提交的代码，四点就全部部署完了，大家还准时赶上了下班的点去吃了附近的龙虾。
谁懂啊。
之前熬的那些夜，真的全是自找的。