CI 自动化配到什么程度，这几项就够
我的项目跑到现在，CI 每次提交花的时间不到两分钟，覆盖了六件事。够不够？够。刚配的时候我一度想加更多环节，后来发现多出来的那些从来不帮我拦问题，只是在拖慢每次提交。CI 自动化要配到什么程度，答案不取决于工具有多少能力，取决于哪些错误是你自己不会发现的。
先把价值说清楚：这份清单能让你用最少的环节拦掉最多的低级错误，剩下那些只有人才能判断的事，别硬塞给机器。
一、先配编译和静态检查
第一件事是让代码先能编译过。听起来基础，但它拦掉的错误比你想象的多——改了函数签名忘了改调用方、删了字段忘了删引用，这类问题在本地因为增量编译经常被漏掉。
静态检查放在同一层。我只开那些默认规则里有共识的部分，比如未使用的变量、明显的空指针风险。规则开太多，第一次跑出几百条提示，你只会全部忽略，那还不如不开。
具体动作：把编译和静态检查放在同一个步骤里，任何一条不通过就中断，别让后面的环节浪费时间。
二、跑一遍测试，只跑能跑完的
第二件事是测试。关键不是覆盖率有多高，是这批测试能不能在可接受的时间内跑完。
我的做法是把测试分成两层：核心逻辑的快测每次提交都跑，耗时的集成测试定时跑。分层的理由是，如果每次提交都要等很久，人就会开始绕过 CI 直接提交，那道闸门就废了。
具体动作：先量一次全量测试的耗时，超过你能等的限度就拆层，不要为了完整而牺牲「每次都会跑」这件事。
三、卡住格式和依赖变更
第三件事是格式检查。它不是质量问题，是讨论成本问题——让机器决定缩进和换行，代码审查的时候就不用浪费时间在这些地方。
第四件事是依赖变更提醒。有新依赖进来的时候，让 CI 明确标出来，别让它悄悄混在一次普通提交里。这个提醒不是拦你，是让你知道这次改动多了一个外部变量。
具体动作：格式检查失败时输出可直接执行的修复命令，让人照抄一行就能改好，比让人去读规则文档快得多。
四、构建产物要能重复产出
第五件事是把构建产物跑一遍，哪怕你不部署。
理由是：本地能跑不代表构建得出来。路径大小写、环境变量、构建时的依赖解析，这些问题只在构建阶段暴露。让 CI 每次都构建一次，等于把「发布那天才发现构建失败」提前到了每次提交。
具体动作：构建产物的名字里带上提交标识，出问题时能一眼对上代码版本。
五、最后一步：只做通知，不做自动部署
第六件事是通知。构建失败要能找到你，这一条经常被忽略，结果就是 CI 红了两天没人管。
至于自动部署，我的建议是先别做。自动部署把一次人工确认换成了一次自动执行，风险是单向增加的。 单人项目里，那个确认动作花的时间远小于一次误发布的代价。
六、优先级：先做哪个
按顺序来：编译和静态检查永远排第一，没有它后面全是空跑；测试排第二，因为它防的是逻辑错误；构建排第三；通知排第四；格式和依赖提醒可以随时补上。
不做的清单也要明确：不在 CI 里跑部署，不在 CI 里做代码风格的主观判断，不为一个季度用不到一次的检查环节买单。这些环节留着，属于典型的工具越用越多，我在工具越用越多，我砍到只剩四个里写过怎么收口。
常见问题
Q：CI 自动化要配到什么程度才算够？
A：能拦住编译错误、明显静态问题、核心测试失败和构建失败，这四项就够用了。剩下的环节如果一个月都没帮你拦下过问题，可以考虑砍掉。
Q：一个人开发需要 CI 吗？
A：需要，但目的不是团队协作，是替代那个「另一个人帮你看一眼」的角色。它拦的是你自己注意不到的低级错误。
Q：CI 每次跑太慢怎么办？
A：先测出各环节的耗时，把最慢的那个分层或并行。如果总时长超过你愿意等的限度，人就会绕过它，那这道闸门等于不存在。
相关阅读
本文作者西米，37 岁程序员，一个人加五个 AI 员工在跑一家公司。踩过的坑和真实账本都写在公众号「西米分享」。
完整代码、踩坑清单与最新进展，都在公众号。
📱 关注公众号「西米分享」