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

持续集成之“分支策略”?现代版本控制系统（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所示）。这种分支策略是应该尽量避免的，它的复杂性和维护成本都很高，因为：每次都要把缺陷修复代码合并到后续的多个发布?分支上，尤其是当该缺陷发生在较老的版本，而当前已有多个活跃版本需