mybatis-plus 3.4 集成p6spy_持续集成的精髓

(全文字数: 2300, 阅读时间: 5分钟)

在之前的文章《两阶段持续集成》，我讲到持续集成(CI)可以分为两个相辅相成，协同工作的阶段：Pre-merge CI和Post-merge CI。前者是在代码改动正式合入主干之前执行的CI，而后者是代码改动正式合入主干之后执行的CI。

如何处理Pre-merge CI和Post-merge CI的关系是持续集成中的一个重大问题。一般认为，Pre-merge CI和Post-merge CI都有其存在的独特价值，无法彼此取代，都是缺一不可的。

但是，如果要进一步问，Pre-merge CI和Post-merge CI哪一个更重要？我们更依赖于哪一个呢？答案众说纷纭。这里，我想旗帜鲜明地说：Pre-merge CI更重要。Pre-merge CI是持续集成的精髓所在。

要论证这个观点，需要回到《持续集成的初心》上来。持续集成的初心，或者说持续集成存在的根本意义，在于发现开发者提交的代码改动潜在的问题，并阻止有问题的代码改动泄露到下一阶段。

那么，是Pre-merge CI更能实现这一目的，还是Post-merge CI更能实现这一目的呢？答案是显而易见的，Pre-merge CI更能实现这一目的。这是因为，一旦Pre-merge CI失败，有问题的代码改动就无法合入主干了，更无法泄露到下一阶段。

当然，Post-merge CI失败也能够阻止有问题的代码改动泄露到下一阶段。但是，Post-merge CI是串行的，无法像Pre-merge CI一样同时阻止多个有问题的代码改动；更重要的，Post-merge CI失败，会阻止所有没有问题的代码改动发布到下一阶段，而Pre-merge CI就没有这个弱点。

因此，无论从效率方面还是准确率方面，Pre-merge CI都更能承担识别和阻拦问题代码改动的千斤重担。从这一点上说，Pre-merge CI堪称CI中的顶梁柱，其重要性不言而喻。

当然，这里并不是说Post-merge CI不能识别和阻止问题代码改动。正如我在《两阶段持续集成》一文中指出的，由于CI某个原理上的缺陷，Pre-merge CI并不能拦截100%的问题代码改动。在Pre-merge CI失灵的极少数情况下，Post-merge CI作为双保险机制中的第二道关卡，依然能够发挥作用。

Pre-merge CI和Post-merge CI各自能够发现多少比例的问题？这个数据难以准确计算，因为Pre-merge CI发现的许多问题都是在各个开发者自己的分支上被分析和解决的，无法集中统计。不过，根据我们某个项目的经验估计，Pre-merge CI能发现95%左右的问题，而Post-merge CI发现剩下5%的问题。

相信看到这里，大家已经能够对Pre-merge CI的关键作用有所认同。然而，"天下没有免费的午餐"，要实现Pre-merge CI的价值，是要花费相当成本的。

因为，在Pre-merge CI阶段，开发者的代码可能需要修改多次，而往往每次修改都需要触发Pre-merge CI。这意味着Pre-merge CI的执行频率非常高，从而给CI带来沉重负担。

但是，这里的成本主要是机器成本，通过增加机器即可改进。当然，除了增加机器，还有许多技术手段可以用来加速CI，减少开发者等待时间。例如，选择性CI任务，选择性回归测试，并行测试，修改产品配置，Mock外部依赖等。

实现这些技术需要投入人力，可以基于投入产出比来决定采用哪些技术。其实，根据我的个人经验，从长期的时间窗口来看，这部分技术的投入其回报往往是十分可观的。

如果增加了机器资源，并尝试了一些技术手段，持续集成仍然负荷重，运行效率低，那么就可以采取一些特殊手段了。典型的特殊手段是降低Pre-merge CI的执行频率。

降低Pre-merge CI执行频率的具体做法可以有很多。例如：将多个相互依赖的代码改动合并在一起执行Pre-merge CI，按照时分模式将某个时间段内全部的代码改动合并在一起执行Pre-merge CI，随机或者按照某一标准仅仅让某一部分代码改动执行Pre-merge CI，等等。

这里，在我看来，未经充分论证直接让某些代码改动跳过Pre-merge CI合入主干的做法是很不可取的。具体原因参照上面对Post-merge CI的分析。

这里需要补充的是，寄希望于Post-merge CI发现更多软件问题的想法是危险的。因为，Post-merge CI一旦失败，trunk就中断了，研发工作彻底停摆。这个后果有多严重大家可以想象。我是做CI的，在任何时候任何地方接到CI中断这种电话，都需要立即进行处理。这一部分我有切肤之痛的经历。

将多个改动合并在一起执行Pre-merge CI是一种可以降低CI负荷，提升CI执行效率的有效方法。然而，在运用这种方法之前，需要充分考虑到它的风险。它最大的风险在于：当Pre-merge CI失败时，由于存在多个"嫌疑犯"，因此定位造成失败的代码改动往往需要花费更多人力成本。

这里的人力成本主要是开发者成本。开发者成本与机器成本不可同日而语。它们之间的比例关系，相信大家有所耳闻。结论一般都是，能用增加机器解决的问题，通常就用增加机器来解决。

只有当增加机器并且采用各种CI优化手段之后，CI运行效率仍然较低的时候，在认识并承受开发者定位问题成本增加这一风险的情况下，采取的万不得已的手段。

以上三个条件缺一不可。在不满足其中任何一项条件的情况下，贸然做出降低Pre-merge CI执行频率的决定，是不妥的，违背了持续集成的基本原则。

什么是持续集成的基本原则？这要从著名的"集成黑洞"谈起。那是在软件开发"原始时代"存在的梦魇:  大量未经充分测试的代码，突然被捏合在一起，一次性集成，软件问题集中爆发层出不穷，有限的集成时间被吞噬，项目无法前进，交付遥遥无期。

因此，世界上才有了持续集成这个东西，它在软件每次发生改动时就立即集成，从而成功地将"集成黑洞"化整为零，各个击破，从源头上解决问题。

持续集成还有一个比较隐晦的特点: 那就是当开发者提交一大堆代码在Pre-merge CI阶段发生失败自己定位问题头痛时，TA在今后会倾向于提交改动量更小的代码，从而进一步降低持续集成颗粒度。

可以说，降低持续集成颗粒度，提升持续集成频率是一种历史趋势。当然，在这个大趋势背景下的各个阶段或局部，由于主客观条件的约束，我们可能还无法完全做到这一点，甚至有时候背道而驰。这时，慎重决定之际，我们需要承认并概括承受这背后所潜在的不容忽视的风险。

推荐阅读：

两阶段持续集成 持续集成测试再思考