持续集成之“分支策略”

　　现代版本控制系统(SCM)的作用已不仅仅是保存历史版本，它还是各软件开发组织利用其分支功能实现多人并行开发，提高生产效率的一种工具。对于稍有历史的软件产品来说，一般都会有代码分支的出现，也常常见到一些历史悠久的产品其错综复杂的分支版本树甚至将产品交付团队拖入“无尽维护”的泥潭。分支的目的是希望“分而治之”，而持续集成的目的是“频繁集成”，这二者之间又有哪些联系呢？

　　在《测试三角形与分段构建策略原则》一文中，咱们说到：由于自动化测试时间较长，Joe的团队实施了分阶段的持续集成。虽然这么做引入了一些风险（比如因提交阶段构建中的测试覆盖面小而不能尽早发现代码中问题），但提高了整个团队的开发效率。而且，Joe会根据实际运行情况，在提交构建和次级构建之间不断调整自动化测试用例集来缓解分阶段构建带来的风险。

　　现在，这个软件游戏平台的第一个版本已经接近完成，马上就要进行内测了。团队面临的问题是：“如何做分支管理？持续集成该怎么做？”

　　一、短周期发布分支策略

　　今天是星期五。下班后，Joe和Alice等主要开发人员并没有马上回家，而是在一个小酒吧里聊天呢。

　　Alice说道：“现在我们一直使用主干开发方式，团队所有人都工作在Trunk上，与之对应的只有一个持续集成环境。下星期就要做内测了，我们是不是应该拉一个测试分支，用于修复测试中发现的缺陷，在主干继续开发新功能呢？一旦修复完内测缺陷的话，我们就可以在这个分支上进行发布，再把这个测试分支的代码变更合并回主干。就像这样。”她拿了一张纸画了出来（如图1所示）。

　　“好啊，好啊。我们分成两个团队，一个在测试分支上工作，修复内测过程中发现的缺陷；另一个在主干上工作，开发新的功能。”Bob回应道。

　　“对于拉分支做测试这件事，我没有疑问。但是，我不同意最后再把代码合并到主干上。”Joe说道。“我们一直在使用持续集成实践，目的就是尽早集成。为什么要等到发布以后再将测试分支的代码合并回主干，而不是每次修复一个缺陷就合并回来呢？每次缺陷修复的代码变更不会太多，所以合并起来很容易。等到最后再合并，首先是容易漏掉一些代码，其次是一次合并代码太多，容易出错。所以，我建议下星期拉分支时，为测试分支也建立一个持续集成环境。每次发现缺陷时，都为它写一个测试，加到测试套件中。修复代码提交后，就会触发测试分支对应的持续集成构建。一旦构建成功，就将其合并回主干。”说完之后，他在Alice画的那张图上修改了一下（如图2所示）。

1. 拉分支之后，开发团队可以继续开发新的功能。而测试团队可以单独对分支进行测试、部署，不受开发团队的影响。
2. 一旦测试中发现问题，开发人员要在该分支上修复。
3. 在分支发布之后，一旦发现了严重问题，仅在该发布分支上修复后即可发布补丁版本。
4. 在分支上做修改后，就要根据实际情况进行分析，是否要合并回主干。如果需要合并，应该立即进行。

　　“那由谁来负责把发布分支中的Bugfix合并回主干呢？”

　　“当然是由Bugfix的人来负责了，他是确保合并正确性的关键。如果Trunk上的代码已被修改，无法合并，Bug负责人就要与主干开发人员交流，这个Bug在主干的有效性，然后再决定是否修改，在哪里修改的问题。”

　　“我们要对发布分支上的Bug定义修复标准，尽量在Trunk上修复Bug，除非这个Bug严重影响发布质量。这样可以避免无休止地在发布分支上做代码修改。这样，Bug数才会收敛，发布分支的活跃期才会缩短。”

　　“嗯，相对于我们一直使用的主干开发方式来说，这种短发布分支策略的成本是：

1. 需要多套独立的持续集成环境。即每个分支在处于活跃期时，要有与之对应的一套持续集成环境，以便不受影响。
2. 每次发布分支上修复缺陷后，只要分支对应的持续集成构建成功，就要将其合并回主干。
3. 由于主干开发的代码可能因架构改进使原有缺陷不复存在，所以每次合并时都需要人为判断一下合并的必要性。”

　　二、长周期发布分支策略?

　　“哦，我之前工作的一家公司，就是用这种分支策略。”Bob说道，“但情况变得非常复杂。版本满天飞，想做合并都不容易。”

　　Joe说道：“我想，可能是因为他们的客户不想升级版本，所以必须在已发布的版本上再发小版本吧？”

　　“的确是这样的。”Bob回答道，“他们的发布周期大约是半年。由于已发布的版本质量不佳，所以总是有紧急修复的版本上线。另外，客户比较担心新版本的稳定性，所以只要满足自己的当前需求，就会一直使用旧版本。有些大客户还会要求公司开发针对其自身的特别需求，并快速上线，结果可想而知。”

　　Alice说道：“其实，这已经是短周期发布分支的变形，即有多个活跃分支的长周期发布分支策略（如图3所示）。这种分支策略是应该尽量避免的，它的复杂性和维护成本都很高，因为：

1. 每次都要把缺陷修复代码合并到后续的多个发布分支上，尤其是当该缺陷发生在较老的版本，而当前已有多个活跃版本需要维护时。
2. 随着时间的推移，每个分支上的自动化测试用例增多，更多的分支会对持续集成环境中的测试机数量的需求快速增加。
3. 发布周期长诱使团队在已有的发布分支上再做子分支（如图3中的R1.1），这会让集成和验证工作变得更加复杂（如图3中从R1.1到R2.0的Cherry Picking操作表明：需要向多个分支上合并部分代码）。
4. 由于每个活跃分支都要对应一个持续集成环境，因此，分支越多，对持续集成环境的维护成本也就越高。

　　Bob问道：“有什么办法避免这种糟糕的多活跃分支开发策略吗？”

　　“办法当然有，但不能解决所有问题。”Joe回答道，“比方说，首先，要确保每个版本的开发质量，让客户放心升级。其次，软件产品要支持自动升级。在通常情况下，只要满足需求，用户就不会轻易升级软件。所以，要让软件具有自动发现新版本并在后台自动升级的能力。当然，在升级后要通知用户。这样，只要将新版本发布到互联网上的某个服务器上就行了。最后，也是最重要的一点，新版本发布周期要短一些，不断快速地推出新特性，这样就可以让用户对产品及研发团队有信心，让客户感觉他们的需求很快就会被满足。”

　　“对于那些企业用户来说，这种方法可能不管用。因为，企业内网很少可以连通外网。”Alice说道。

　　“如果是这种情况的话，除了软件本身质量好且能自动无缝升级以外，在销售时可以与客户签订协议，告知所售软件版本的生命周期（比如18个月）以及升级条款，促使企业升级该软件，比如免费的大版本升级，或者因缺陷原因可免费升级等等。”Joe回答道。

　　“嗯，我们开发的是游戏软件平台，部署在互联网上，所以不会遇到这个问题。”Alice说道。

　　Joe微笑着说道：“我们将会面临另外一种问题，即多个小团队开发不同的游戏组件问题。”

　　“哦，对了！现在我们的游戏平台中虽然仅有几个游戏，目前还一起在主干上开发。但在下一版本中，我们会增加大量的游戏组件，那应该如何应对？我们的持续集成环境应该是什么样的呢？”Alice大声地问道。

　　“嗯，是个好问题！”Joe回答道。“我已经有了一些想法。我们内测结束后，再详细讨论吧！时间也不早啦，大家回去休息吧，周末愉快！”