持续集成技术：为什么我那天天熬夜改bug的队友现在准点下班了

上个月9月23号，在南京河西江边排档吃龙虾，碰到原来一起做项目的老周。印象里他以前是团队里熬夜最多的那个，每次版本上线前三天，他的咖啡杯就没空过，眼睛红得像兔子。那天他六点半就坐下来，点完单还掏出手机给我看刚接儿子放学拍的视频，蹦蹦跳跳举着棉花糖。 我调侃他，现在转管理不用写代码了？他摇摇头，说还是写，只是现在不用天天加班改破冲突了——全靠持续集成救了命。

别扯百科定义，说点普通人能懂的

做过开发的都懂那种绝望。几个人挤在同一个项目里改代码，你改用户模块，我改支付模块，各自在本地改了一周，最后要上线了往一起合并，一拉提交记录，二十多个冲突，变量重名、接口参数对不上、甚至有人把别人已经改好的代码又覆盖回去了。 改完冲突跑一遍，出来七八个新bug，找了半天才发现是合并的时候漏了半行逻辑。你说窝火不窝火。 持续集成技术说白了，就是解决这个破事的。不是什么高大上的黑科技，核心逻辑很简单：你改完一小块代码，就往公共仓库合并一次，每次合并都自动帮你做一遍检查验证，有问题当场告诉你，当场改，不用把所有问题攒到上线前一起爆。 传统软件项目多人开发代码合并冲突场景图 很多人刚听会说，不就是天天提交代码吗？我也天天提交啊，怎么还加班？ 差远了。核心不是提交，是自动验证。你提交完，系统一秒钟就能帮你查出语法错不对、代码格式符不符合规范、核心功能能不能跑通，要是合进去会炸掉现有代码，直接给你打回来，不让你合。 老周他们团队原来出过一个事：一个新人改了登录页的一个样式，不小心动了公共依赖里的一个参数，本地跑没问题，合并完所有人的项目都跑不起来，全团队停了一上午找问题。现在呢？刚提交就被持续集成拦下来了，提示参数改动影响了三个核心模块，新人当场就改回去了，没人知道这件事，更别说耽误时间了。

大部分团队都用错了，白白浪费了功夫

说实话，我见过不下十个团队，吭哧吭哧搭完持续集成，不到半个月就没人用了，落灰落得比年会奖品还厚。 为什么？大部分都是踩了同一个坑：贪大求全。把什么代码检查、单元测试、集成测试、端到端测试全塞进去，跑一次快的要半小时，慢的要两个多小时。开发改完两行代码，想合并，等结果等得花都谢了，谁愿意等？慢慢大家就开始绕开流程，直接合并，最后工具就成了摆设。 还有人觉得，持续集成就是大项目才用的，我们三五个人的小项目犯不着折腾。 我上个月帮朋友调一个两个人做的小项目，两个人改同一个配置文件，差了三行，合并冲突改了一下午，本来约好晚上看电影都错过了。你说，花半小时搭个基础的持续集成，省出来的时间喝奶茶看电影不好吗？ 软件项目持续集成自动化执行步骤图 还有一个误区特别普遍：觉得持续集成能包治百病，用了之后就没bug了。 拉倒吧。它就是帮你挡低级问题的，帮你把合并冲突、语法错误、低级逻辑错这些问题提前拦下来，不会让你攒到最后一起踩坑。它帮你解决的是"我本地好好的怎么合完就炸了"这种傻逼问题，产品逻辑错了、需求理解错了这种问题，它帮不了你，别期望值太高。 不过话说回来，就光是解决合并冲突这一件事，就已经能帮团队省出大把时间了，不是吗？

真正改变的从来不是工具，是习惯

真正改变的从来不是工具，是习惯 很多人聊持续集成，上来就聊Jenkins、聊GitLab CI、聊各种云原生工具，说来说去都是工具，其实工具是最不重要的。 持续集成真正改变的，是开发的习惯。原来大家做开发，习惯把一整个大功能全部写完，测通了再提交合并，半个月动一次大的，风险全堆在最后。现在用持续集成，要求你改完一个小功能就提交一次，验证一次，风险永远拆得很小，就算出问题，也就几行代码的事，五分钟就能改好，不用对着几千行的改动找bug。 我见过换了三四套工具，流程还是老一套的团队，大家还是习惯把代码放本地攒半个月，那你工具搭得再完美，有啥用？持续集成，核心是"持续"两个字，不是搞一次形式主义就完事了，是天天用，次次用，把拆分风险变成习惯。 当然我也不是说它就是银弹，什么场景都适合。比如你做的是一次性的外包项目，写完交付就再也不用管了，那确实没必要花那功夫搭。再比如团队就你一个人开发，所有改动你自己都门清，那也没必要折腾。还有，它确实需要一点前期成本，你得写自动化测试用例啊，得配置规则啊，刚开始肯定要花时间踩坑，没有自动化测试的持续集成，说白了就是个空架子，也就帮你检查个代码格式，用处真的不大。 那天吃完饭，老周七点十分就赶去地铁站了，说要赶在儿子上兴趣班之前送过去，书包上还晃着那个奥特曼的钥匙扣。我记得半年前他还在我们老群里凌晨两点发红包，求着人帮忙看合并完的bug。 技术哪有那么多玄乎的噱头啊。很多时候，一个小小的流程改进，就能帮你把原来浪费在破事上的时间，省下来还给生活。这不就是技术最实在的用处吗。