持续集成之“分支策略”
转自：
http://www.infoq.com/cn/news/2011/03/ci-branch-strategy
http://www.infoq.com/cn/news/2011/04/ci-branch-strategy-2
http://kb.cnblogs.com/page/96915/
http://kb.cnblogs.com/page/96916/
持续集成之“分支策略”
现代版本控制系统（SCM）的作用已不仅仅是保存历史版本，它还是各软件开发组织利用其分支功能实现多人并行开发，提高生产效率的一种工具。对于稍有历史的软件产品来说，一般都会有代码分支的出现，也常常见到一些历史悠久的产品其错综复杂的分支版本树甚至将产品交付团队拖入“无尽维护”的泥潭。分支的目的是希望“分而治之”，而持续集成的目的是“频繁集成”，这二者之间又有哪些联系呢？
在《测试三角形与分段构建策略原则》一文中，咱们说到：由于自动化测试时间较长，Joe的团队实施了分阶段的持续集成。虽然这么做引入了一些风险（比如因提交阶段构建中的测试覆盖面小而不能尽早发现代码中问题），但提高了整个团队的开发效率。而且，Joe会根据实际运行情况，在提交构建和次级构建之间不断调整自动化测试用例集来缓解分阶段构建带来的风险。
现在，这个软件游戏平台的第一个版本已经接近完成，马上就要进行内测了。团队面临的问题是：“如何做分支管理？持续集成该怎么做？”
一、短周期发布分支策略
今天是星期五。下班后，Joe和Alice等主要开发人员并没有马上回家，而是在一个小酒吧里聊天呢。
Alice说道：“现在我们一直使用主干开发方式，团队所有人都工作在Trunk上，与之对应的只有一个持续集成环境。下星期就要做内测了，我们是不是应该拉一个测试分支，用于修复测试中发现的缺陷，在主干继续开发新功能呢？一旦修复完内测缺陷的话，我们就可以在这个分支上进行发布，再把这个测试分支的代码变更合并回主干。就像这样。”她拿了一张纸画了出来（如图1所示）。
“好啊，好啊。我们分成两个团队，一个在测试分支上工作，修复内测过程中发现的缺陷；另一个在主干上工作，开发新的功能。”Bob回应道。
“对于拉分支做测试这件事，我没有疑问。但是，我不同意最后再把代码合并到主干上。”Joe说道。“我们一直在使用持续集成实践，目的就是尽早集成。为什么要等到发布以后再将测试分支的代码合并回主干，而不是每次修复一个缺陷就合并回来呢？每次缺陷修复的代码变更不会太多，所以合并起来很容易。等到最后再合并，首先是容易漏掉一些代码，其次是一次合并代码太多，容易出错。所以，我建议下星期拉分支时，为测试分支也建立一个持续集成环境。每次发现缺陷时，都为它写一个测试，加到测试套件中。修复代码提交后，就会触发测试分支对应的持续集成构建。一旦构建成功，就将其合并回主干。”说完之后，他在Alice画的那张图上修改了一下（如图2所示）。
- 拉分支之后，开发团队可以继续开发新的功能。而测试团队可以单独对分支进行测试、部署，不受开发团队的影响。
- 一旦测试中发现问题，载发人员要在该分支上修复。
- 在分支发布之后，一旦发现了严重问题，仅在该发布分支上修复后即可发布补丁版本。
- 在分支上做修改后，就要根据实际情况进行分析，是否要合并回主干。如果需要合并，应该立即进行。
“那由谁来负责把发布分支中的Bugfix合并回主干呢？”
“当然是由Bugfix的人来负责了，他是确保合并正确性的关键。如果Trunk上的代码已被修改，无法合并，Bug负责人就要与主干开发人员交流，这个Bug在主干的有效性，然后再决定是否修改，在哪里修改的问题。”
“我们要对发布分支上的Bug定义修复标准，尽量在Trunk上修复Bug，除非这个Bug严重影响发布质量。这样可以避免无休止地在发布分支上做代码修改。这样，Bug数才会收敛，发布分支的活跃期才会缩短。”
“嗯，相对于我们一直使用的主干开发方式来说，这种短发布分支策略的成本是：
- 需要多套独立的持续集成环境。即每个分支在处于活跃期时，要有与之对应的一套持续集成环境，以便不受影响。
- 每次发布分支上修复缺陷后，只要分支对应的持续集成构建成功，就要将其合并回主干。
- 由于主干开发的代码可能因架构改进使原有缺陷不复存在，所以每次合并时都需要人为判断一下合并的必要性。”
二、长周期发布分支策略?
“哦，我之前工作的一家公司，就是用这种分支策略。”Bob说道，“但情况变得非常复杂。版本满天飞，想做合并都不容易。”
Joe说道：“我想，可能是因为他们的客户不想升级版本，所以必须在已发布的版本上再发小版本吧？”
“的确是这样的。”Bob回答道，“他们的发布周期大约是半年。由于已发布的版本质量不佳，所以总是有紧急修复的版本上线。另外，客户比较担心新版本的稳定性，所以只要满足自己的当前需求，就会一直使用旧版本。有些大客户还会要求公司开发针对其自身的特别需求，并快速上线，结果可想而知。”
Alice说道：“其实，这已经是短周期发布分支的变形，即有多个活跃分支的长周期发布分支策略（如图3所示）。这种分支策略是应该尽量避免的，它的复杂性和维护成本都很高，因为：
- 每次都要把缺陷修复代码合并到后续的多个发布?分支上，尤其是当该缺陷发生在较老的版本，而当前已有多个活跃版本需要维护时。
- 随着时间的推移，每个分支上的自动化测试用例增多，更多的分支会对持续集成环境中的测试机数量的需求快速增加。
- 发布周期长诱使团队在已有的发布分支上再做子分支(如图3中的R1.1)，这会让集成和验证工作变得更加复杂（如图3中从R1.1到R2.0的Cherry Picking操作表明：需要向多个分支上合并部分代码）。
- 由于每个活跃分支都要对应一个持续集成环境，因此，分支越多，对持续集成环境的维护成本也就越高。
Bob问道：“有什么办法避免这种糟糕的多活跃分支开发策略吗？”
“办法当然有，但不能解决所有问题。”Joe回答道，“比方说，首先，要确保每个版本的开发质量，让客户放心升级。其次，软件产品要支持自动升级。在通常情况下，只要满足需求，用户就不会轻易升级软件。所以，要让软件具有自动发现新版本并在后台自动升级的能力。当然，在升级后要通知用户。这样，只要将新版本发布到互联网上的某个服务器上就行了。最后，也是最重要的一点，新版本发布周期要短一些，不断快速地推出新特性，这样就可以让用户对产品及研发团队有信心，让客户感觉他们的需求很快就会被满足。”
“对于那些企业用户来说，这种方法可能不管用。因为，企业内网很少可以连通外网。”Alice说道。
“如果是这种情况的话，除了软件本身质量好且能自动无缝升级以外，在销售时可以与客户签订协议，告知所售软件版本的生命周期（比如18个月）以及升级条款，促使企业升级该软件，比如免费的大版本升级，或者因缺陷原因可免费升级等等。”Joe回答道。
“嗯，我们开发的是游戏软件平台，部署在互联网上，所以不会遇到这个问题。”Alice说道。
Joe微笑着说道：“我们将会面临另外一种问题，即多个小团队开发不同的游戏组件问题。”
“哦，对了！现在我们的游戏平台中虽然仅有几个游戏，目前还一起在主干上开发。但在下一版本中，我们会增加大量的游戏组件，那应该如何应对？我们的持续集成环境应该是什么样的呢？”Alice大声地问道。
“嗯，是个好问题！”Joe回答道。“我已经有了一些想法。我们内测结束后，再详细讨论吧！时间也不早啦，大家回去休息吧，周末愉快！”
持续集成之“分支策略”(续)
在前文中，咱们谈到生命周期长短不同的两种分支策略。对于不超过二十人的小团队来说，推荐使用短生命周期的分支策略。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的团队使用这种持续集成方案以后，还会遇到什么情况呢？比如，基础平台的构建时间变长，会怎么样呢？
需要注意的是，无论采用哪种方法，我建议都不要让同一组人一直工作在一个模块上（虽然这是在各组织中经常见到的），而是让一组人工作在一组模块或功能上，并让小组成员在各组间流动。这样有利于组间的知道共享，对保持架构的一致性也会起到积极作用。
完！
