持续集成之“分支策略”(续)

在前文中，咱们谈到生命周期长短不同的两种分支策略。对于不超过二十人的小团队来说，推荐使用短生命周期的分支策略。Joe 的团队在首次发布之前，也一直使用这种方式。然而，首次发布之后，因市场反响非常好，公司决定加大开发投入，希望更快地推出升级平台，以及更多基于平台的游戏。

一、按特性分支的持续集成策略

现在，Joe 的团队中，开发人员快速增加，已接近 30 人了。由于首次发布后的市场压力，大家一直在赶进度，持续集成的失败频率越来越高，修复构建的时间也越来越长，排队等待提交的代码也越积越多。“这种状况不能再持续下去了，需要想个办法解决它。”Joe 决定下午召集主要人员开会，分析一下原因和对策。

“现在我们还在使用提交令牌（参见《Checkin Dance》一文的最后一节），可我们的开发人数已经翻了一倍。而且，我们自动化测试用例的数量也激增。”Joe 说道，“有时候我想提交代码都要排队等很长时间。”

“嗯，每天等待提交的人也挺多的。”Alice 说道，“现在看来，虽然持续集成让我们每次提交的质量都更有保证，但是在同一个主干上开发的人数太多，它就成了一个提高开发效率的瓶颈了。”

“要不这样吧：我们把大家分成小组，每个小组从主干上拉出一个分支，完成一组相近特性的开发后，再合并回主干。”Bob 边说边在白板上画了出来（如图 1 所示）。

“对应的持续集成方案也需要调整。包括：

• 保留现有主干对应的持续集成平台，但不许在主干上直接开发代码；
• 每个分支增加一个相对应的持续集成平台；
• 每个分支的持续集成平台构建中需要包括该分支对应特性的单元测试、功能测试；
• 每次向主干合并时，都会触发主干上的持续集成，构建中应包含整个系统的单元测试、功能测试等。

这样，每个小组的人数不会太多，提交时需要等待他们提交完成的概率应该不会太大。另外，每个分支的持续集成上只运行自己分支对应特性的单元测试和功能测试，这样，构建时间也会缩短。”

“听上去是个好办法，”Alice 答道，“可是，我对这个方案有几个疑问。比如说，这几个小组在什么时候做同步？每个小组什么时候向主干合并代码？”

“嗯，好问题。我还没有想到这么多呢。”Bob 皱了皱眉，感到很沮丧。

Joe 笑了笑，说道：“的确是不错的方案。只要加一点同步与合并规则，改进一下。”然后，他拿起白板笔，在图上加了几笔（所图 2 所示）。

“规则如下：

• 每个小功能在尽可能短的时间里开发且测试完成，最好是在一周之内。
• 每组做完一个小功能后，一旦该分支上的持续集成构建通过，而且手工验证没有问题，就可以向主干合并代码。
• 合并后，与主干对应的持续集成平台会立即验证这些代码。
• 如果主干持续集成平台的构建失败，那么是哪个小组提交导致的，就由哪个小组负责修复。
• 每天各组在开始工作之前，都要将主干上那个最新且通过主干持续集成构建成功的代码检出，并与各自分支的代码进行合并。

其实，这就是小组级别的“ Checkin Dance ”。目的还是要持续集成，即尽要将各小组的工作成果集成在一起。如果每个小组能够做到频繁与主干代码同步的”

Alice 问道：“由于每个分支上都是多人开发，那么当某个功能完成后，并需要合并回主干时，该分支上可能已经有一些代码是属于尚未完成功能的代码。我们需要把属于该功能的代码修改挑选出来后提交到主干吗？”

“你是说 Cherry Picking 吧。只要我们能够通过技术手段确保用户无法访问到未完成的功能，就不需要 Cherry Picking 了。比如通过配置项或功能开关的方式。”Joe 说道。

“这样做，听起来挺好的，但还有一个问题需要解决，那就是：现在大家的代码耦合度太高啦。每增加一个小功能，都要修改很多个位置的代码。”?Bob 说道，“如果这么做的话，各组之间的代码冲突会很多，合并可能带来很多问题。”

“的确是这样的，目前的持续集成方案只能缓解合并问题，但无法解决合并中的代码冲突问题，只有通过对代码的结构进行调整才能够解决。”Job 说道。“而且，对于我们这样的软件系统来说，对架构进行调整带来的益处更大。”

二、模块化应用程序的持续集成

“啊哈！架构调整？”Bob 笑道，“架构这个词让人用得太滥了，还是不要提的好。一提到架构调整，我就想起在前一雇主公司干的活了——每次架构调整都是重写代码。”

“哦，事实上，我们系统的架构基本上是模块化的，比如平台与具体游戏之间的边界还算清晰。”Joe 回应道，“现在我们所要做的是强化模块化。因为，新加入的开发人员对系统了解不够深入，有些功能的耦合度开始增高了。我希望每个游戏就作为一个独立模块，进行开发与测试。而它所依赖的游戏平台需要提供稳定的对外接口。”

Alice 说道：“那我们就可以不用前面提到的特性分支策略了，只要把每个模块做为一个独立的代码库进行开发，将它所依赖的游戏平台作为外部依赖进行集成就行了。”

“的确是这样的。”Joe 肯定的回答道。“如果每个模块对外都有某种形式的接口（比如 API，接口定义文件），而所有外部依赖都通过这些接口与其进行交互的话，就可以这样做。”如图 3 所示。

“如果这么做的话，我们的持续集成方案应该是什么样的呢？”Bob 问道。

“那不是一样嘛，即然都是独立的，各模块做各自的持续集成不就行了嘛。”Alice 说道。

“当然不行，因为这些模块之间仍旧需要通过彼此交互才能正常运行起来，尤其是对于那些有信息交换的游戏模块，集成测试就更加重要。”Joe 回答道，“既然需要集成，就要做持续集成。”

Alice 问：“那我们有这么多个游戏，每个游戏都要与基础游戏平台进行持续集成，到底应该怎么做呢？”

“我们可以这么做。”Bob 拿起笔在白板上画了起来（如图 4 所示）。“为每个模块的代码库建立对应的持续集成环境，包括每个游戏和基础平台。无论哪个模块代码库修改了代码，都会触发对应的持续集成构建，一旦该模块的持续集成构建成功以后，就会触发一个包含所有游戏和平台的集成构建。”

“这样不错，但是现在每个模块都对应独立的代码库了，那么在最后各模块集成构建时，到底用各模块的哪个版本呢？”Alice 问道。

Joe 说道，“Alice 的问题非常好。在最后各模块集成构建时，除了那个主动触发构建的模块使用最新版本外，其它模块都使用最后一次令该集成构建成功的那个对应版本。”Joe 边说边在白板上画了一个例子。

“比如，对于我们目前的系统来说，一共有四个游戏模块和一个基础平台。假如最后一次成功的集成构建中，各模块对应的版本分别是 123,245,212,467 和 12387。当我们对游戏模块 A 进行了一次提交，其版本变为 124，并且通过了它自己的持续集成构建以后，就会触发最后的集成构建。这次集成构建所对应的各模块版本分别为 124,245,212,467 和 12387。如果这次构建成功，则下次最后集成构建就以这些版本为基础；如果这次构建失败了，则标记游戏模块 A 的 124 版本是可疑版本，尽管它通过了其自身模块的构建。同时需要有人对这次集成构建进行分析，进行问题定位并修复。”如图 5 所示。

“那么，我们的基础游戏平台也是由多个模块组成的。我们是否也需要把这些模块独立成库，使用同样的方式进行持续集成呢？”Bob 问道。

Joe 回答道：“我认为现在还不需要。平台内部模块化是应该的，但因为它自身的构建时间并不长，还没有必要独立成库。”

Alice 此时说道：“这样看来，我们的持续集成问题可以按这种方案来解决。让我们试试吧。”

那么，Joe 的团队使用这种持续集成方案以后，还会遇到什么情况呢？比如，基础平台的构建时间变长，会怎么样呢？

需要注意的是，无论采用哪种方法，我建议都不要让同一组人一直工作在一个模块上（虽然这是在各组织中经常见到的），而是让一组人工作在一组模块或功能上，并让小组成员在各组间流动。这样有利于组间的知道共享，对保持架构的一致性也会起到积极作用。