一、短周期发布分支策略 今天是星期五。下班后，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回答道。“我已经有了一些想法。我们内测结束后，再详细讨论吧！时间也不早啦，大家回去休息吧，周末愉快！”
IP卡
狗仔卡
发表于 2012-4-1 17:55:53
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡