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

持续集成之“分支策略”（续） 在前文中，咱们谈到生命周期长短不同的两种分支策略。对于不超过二十人的 小团队来说，推荐使用短生命周期的分支策略。 Joe的团队在首次发布之前，也 一直使用这种方 式。然而，首次发布之后，因市场反响非常好，公司决定加大 开发投入，希望更快地推出升级平台，以及更多基于平台的游戏。 、按特性分支的持续集成策略 现在，Joe的团队中，开发人员快速增加，已接近 30人了。由于首次发布后的 市场压力，大家一直在赶进度，持续集成的失败频率越来越高，修复构建的 时 间也越来越长，排队等待提交的代码也越积越多。“这种状况不能再持续下去了， 需要想个办法解决它。” Joe决定下午召集主要人员开会，分析一下原因和对 策 “现在我们还在使用提交令牌（参见《Checkin Da nee》一文的最后一节），可 我们的开发人数已经翻了一倍。而且，我们自动化测试用例的数量也激增。” Joe 说道，“有时候我想提交代码都要排队等很长时间。” “嗯，每天等待提交的人也挺多的。” Alice说道，“现在看来，虽然持续集成 让我们每次提交的质量都更有保证，但是在同一个主干上开发的人数太多，它就 成了一个提高开发效率的瓶颈了。” “要不这样吧：我们把大家分成小组，每个小组从主干上拉出一个分支， 完成一 组相近特性的开发后，再合并回主干。” Bob边说边在白板上画了出来（如图1 所示）。 “对应的持续集成方案也需要调整。包括: 保留现有主干对应的持续集成平台，但不许在主干上直接开发代码； ?每个分支增加一个相对应的持续集成平台； 每个分支的持续集成平台构建中需要包括该分支对应特性的单元测试、功能测试； *每次向主干合并时，都会触发主干上的持续集成，构建中应包含整个系统的单元测 试、功能测试等。 这样，每个小组的人数不会太多，提交时需要等待他们提交完成的概率应该不会 太大。另外，每个分支的持续集成上只运行自己分支对应特性的单元测试和功能 测试，这样，构建时间也会缩短。” “听上去是个好办法，” Alice答道，“可是，我对这个方案有几个疑问。比如 说，这几个小组在什么时候做同步？每个小组什么时候向主干合并代码？” “嗯，好问题。我还没有想到这么多呢。” Bob皱了皱眉，感到很沮丧。 Joe笑了笑，说道：“的确是不错的方案。只要加一点同步与合并规则，改进一 下。”然后，他拿起白板笔，在图上加了几笔（所图 2所示）。 “规则如下： *每个小功能在尽可能短的时间里开发且测试完成，最好是在一周之内。 *每组做完一个小功能后，一旦该分支上的持续集成构建通过，而且手工验证没有问 题，就可以向主干合并代码。 *合并后，与主干对应的持续集成平台会立即验证这些代码。 *如果主干持续集成平台的构建失败，那么是哪个小组提交导致的，就由哪个小组负 责修复。 ?每天各组在开始工作之前，都要将主干上那个最新且通过主干持续集成构建成功的 代码检出，并与各自分支的代码进行合并。 其实，这就是小组级别的“ Checkin Dance ”。目的还是要持续集成，即尽要将 各小组的工作成果集成在一起。如果每个小组能够做到频繁与主干代码同步的” Alice问道：“由于每个分支上都是多人开发，那么当某个功能完成后，并需要 合并回主干时，该分支上可能已经有一些代码是属于尚未完成功能的代码。 我们 需要把属于该功能的代码修改挑选出来后提交到主干吗？” “你是说Cherry Picking 吧。只要我们能够通过技术手段确保用户无法访问到 未完成的功能，就不需要 Cherry Picki ng 了。比如通过配置项或功能开关的方 式。” Joe说道。 “这样做，听起来挺好的，但还有一个问题需要解决，那就是：现在大家的代码 耦合度太高啦。每增加一个小功能，都要修改很多个位置的代码。”？Bob说道， “如果这么做的话，各组之间的代码冲突会很多，合并可能带来很多问题。” “的确是这样的，目前的持续集成方案只能缓解合并问题， 但无法解决合并中的 代码冲突问题，只有通过对代码的结构进行调整才能够解决。” Job说道。“而 且，对于我们这样的软件系统来说，对架构进行调整带来的益处更大。” 二、模块化应用程序的持续集成 “啊哈！架构调整？” Bob笑道，“架构这个词让人用得太滥了，还是不要提的 好。一提到架构调整，我就想起在前一雇主公司干的活了一一每次架构调整都是 重写代码。” “哦，事实上，我们系统的架构基本上是模块化的， 比如平台与具体游戏之间的 边界还算清晰。” Joe回应道，“现在我们所要做的是强化模块化。因为， 新 加入的开发人员对系统了解不够深入，有些功能的耦合度开始增高了。我希望每 个游戏就作为一个独立模块，进行开发与测试。而它所依赖的游戏平台需要提供 稳定的对外接口。” Alice说道：“那我