持续集成的最高境界

持续集成大家都不陌生，说的是代码check in之后（或之前）自动化做build和执行测试，这件事情为什么如此重要呢，是因为你local的代码直到check in，build和test之后才会发现问题。

那么持续集成的粒度就是一个问题了，如果每次check in都做一全套，那么这样粒度最细，能最快速的定位问题所在的代码，但check in的时间成本就太高了。如果很多次check in之后才trigger一个全套，那么粒度太粗定位问题来自哪个check in的难度就大大提高。所以出于折中考虑才有了daily build这么个持续集成的时间粒度。

那么持续集成到这里就完事了吗？本来我也以为daily build已经是最高境界了，然而并不是，这也是我来到这家单位以后才学到的。在一般的版本控制系统中，都分了好多个branch。比如Git的分支开发模型，每当开发一个feature，就要拉一个feature branch，每当解一个defect或者hotfix，就要拉hotfix branch，每当要release了，就要拉release branch。

用了branch分支模型，看起来流程是清晰了，各种开发都能并行了，但是branch的merge就成了一个大问题。比如一个feature branch开发了2个月开发完了要merge回main branch，这时候就有点头大了，因为改动太多了，而main branch已经merge了其他feature，其他feature的代码又和现在的feature的改过的文件有冲突。即便可以把大feature break down，merge branch一般来说always是一件痛苦的事情。

所以最狠的招就是整个代码库只有一个branch，那如果只用一个branch的话那做到一半的feature能check in吗？因为毕竟不能等到feature全部完工后再一次check in，这样东西就太多了，我们持续集成的目的就是要降低定位问题所在的代码的难度，所以daily build实际上是鼓励每次check in少的东西，尽量每天都能check in的。

所以这个时候就要想其他的办法。可以精心设计代码的架构，使的代码的架构支持一种类似key的东西，如果这个key打开，那么我就enable对应的feature，如果这个key关闭，那么我就disable对应的feature。这样只要我的key不打开，那么即使我check in还没完成的feature也不要紧，因为binary里面这个feature用户是看不到的。

各个key甚至还可以带sub key，或者组合成key set之类的概念来进一步细粒度的控制feature的可见性。对于一个web应用，还可以用这些key来做A/B测试，对于某些特定的用户打开key，对于其他的用户关闭key，这样有一部分用户就能看到最新的feature。等到稳定之后，再把这个feature暴露给所有的用户。

现在我们已经只有一个branch了，我们也有一套机制可以设定对特定用户暴露哪些代码。那么这就是最高境界了吗？然而并不是。我们还可以更进一步。

在一个branch和key机制的情况下，所以的check in其实都在build完生成的binary里。如果我们在持续集成机制中对binary做完整的自动化functional test，那么只要通过了这些test，就可以release给用户。极端点的我们就可以做到per check in，per release。然而release的test毕竟时间成本很大，所以我们折中一下就可以做到daily release。

以前用分支模型为什么做不到daily release？其一是没有这个需求，对于C/S架构的程序即便你daily release用户也不会每天来下载你的新的binary，所以daily release一般只针对web或cloud应用。其二是feature都在各个feature分支上开发呢，每天都merge回main branch那feature分支就没意义了，而且也没有key机制来保证功能代码对用户屏蔽。

每次check in都是唯一的一个branch，daily check in，最大好处是merge工作量小。多次merge，每次merge工作量很小，这样的pattern正好符合了增量迭代的概念，小步快跑，能很大的降低merge时候发生错误的概率。而且由于所有人都在一个branch上工作，你check in的错误马上其他人就能看到，所以不得不在check in的时候万分谨慎。

所以，持续集成的最高境界就是single branch，daily release。

【免责声明：以上内容仅代表作者观点，并不一定正确，如因读者采用以上观点造成的任何后果，作者概不负责】