现代版本控制系统&＃xff08;SCM&＃xff09;的作用已不仅仅是保存历史版本&＃xff0c;它还是各软件开发组织利用其分支功能实现多人并行开发&＃xff0c;提高生产效率的一种工具。对于稍有历史的软件产品来说&＃xff0c;一般都会有代码分支的出现&＃xff0c;也常常见到一些历史悠久的产品其错综复杂的分支版本树甚至将产品交付团队拖入“无尽维护”的泥潭。分支的目的是希望“分而治之”&＃xff0c;而持续集成的目的是“频繁集成”&＃xff0c;这二者之间又有哪些联系呢&＃xff1f;
\u0026#xD;\n在《测试三角形与分段构建策略原则》一文中&＃xff0c;咱们说到&＃xff1a;由于自动化测试时间较长&＃xff0c;Joe的团队实施了分阶段的持续集成。虽然这么做引入了一些风险&＃xff08;比如因提交阶段构建中的测试覆盖面小而不能尽早发现代码中问题&＃xff09;&＃xff0c;但提高了整个团队的开发效率。而且&＃xff0c;Joe会根据实际运行情况&＃xff0c;在提交构建和次级构建之间不断调整自动化测试用例集来缓解分阶段构建带来的风险。
\u0026#xD;\n现在&＃xff0c;这个软件游戏平台的第一个版本已经接近完成&＃xff0c;马上就要进行内测了。团队面临的问题是&＃xff1a;“如何做分支管理&＃xff1f;持续集成该怎么做&＃xff1f;”
\u0026#xD;\n今天是星期五。下班后&＃xff0c;Joe和Alice等主要开发人员并没有马上回家&＃xff0c;而是在一个小酒吧里聊天呢。
\u0026#xD;\nAlice说道&＃xff1a;“现在我们一直使用主干开发方式&＃xff0c;团队所有人都工作在Trunk上&＃xff0c;与之对应的只有一个持续集成环境。下星期就要做内测了&＃xff0c;我们是不是应该拉一个测试分支&＃xff0c;用于修复测试中发现的缺陷&＃xff0c;在主干继续开发新功能呢&＃xff1f;一旦修复完内测缺陷的话&＃xff0c;我们就可以在这个分支上进行发布&＃xff0c;再把这个测试分支的代码变更合并回主干。就像这样。”她拿了一张纸画了出来&＃xff08;如图1所示&＃xff09;。
\u0026#xD;\n“好啊&＃xff0c;好啊。我们分成两个团队&＃xff0c;一个在测试分支上工作&＃xff0c;修复内测过程中发现的缺陷&＃xff1b;另一个在主干上工作&＃xff0c;开发新的功能。”Bob回应道。
\u0026#xD;\n“对于拉分支做测试这件事&＃xff0c;我没有疑问。但是&＃xff0c;我不同意最后再把代码合并到主干上。”Joe说道。“我们一直在使用持续集成实践&＃xff0c;目的就是尽早集成。为什么要等到发布以后再将测试分支的代码合并回主干&＃xff0c;而不是每次修复一个缺陷就合并回来呢&＃xff1f;每次缺陷修复的代码变更不会太多&＃xff0c;所以合并起来很容易。等到最后再合并&＃xff0c;首先是容易漏掉一些代码&＃xff0c;其次是一次合并代码太多&＃xff0c;容易出错。所以&＃xff0c;我建议下星期拉分支时&＃xff0c;为测试分支也建立一个持续集成环境。每次发现缺陷时&＃xff0c;都为它写一个测试&＃xff0c;加到测试套件中。修复代码提交后&＃xff0c;就会触发测试分支对应的持续集成构建。一旦构建成功&＃xff0c;就将其合并回主干。”说完之后&＃xff0c;他在Alice画的那张图上修改了一下&＃xff08;如图2所示&＃xff09;。
\u0026#xD;\n“那由谁来负责把发布分支中的Bugfix合并回主干呢&＃xff1f;”
\u0026#xD;\n“当然是由Bugfix的人来负责了&＃xff0c;他是确保合并正确性的关键。如果Trunk上的代码已被修改&＃xff0c;无法合并&＃xff0c;Bug负责人就要与主干开发人员交流&＃xff0c;这个Bug在主干的有效性&＃xff0c;然后再决定是否修改&＃xff0c;在哪里修改的问题。”
\u0026#xD;\n“我们要对发布分支上的Bug定义修复标准&＃xff0c;尽量在Trunk上修复Bug&＃xff0c;除非这个Bug严重影响发布质量。这样可以避免无休止地在发布分支上做代码修改。这样&＃xff0c;Bug数才会收敛&＃xff0c;发布分支的活跃期才会缩短。”
\u0026#xD;\n“嗯&＃xff0c;相对于我们一直使用的主干开发方式来说&＃xff0c;这种短发布分支策略的成本是&＃xff1a;
\u0026#xD;\n“哦&＃xff0c;我之前工作的一家公司&＃xff0c;就是用这种分支策略。”Bob说道&＃xff0c;“但情况变得非常复杂。版本满天飞&＃xff0c;想做合并都不容易。”
\u0026#xD;\nJoe说道&＃xff1a;“我想&＃xff0c;可能是因为他们的客户不想升级版本&＃xff0c;所以必须在已发布的版本上再发小版本吧&＃xff1f;”
\u0026#xD;\n“的确是这样的。”Bob回答道&＃xff0c;“他们的发布周期大约是半年。由于已发布的版本质量不佳&＃xff0c;所以总是有紧急修复的版本上线。另外&＃xff0c;客户比较担心新版本的稳定性&＃xff0c;所以只要满足自己的当前需求&＃xff0c;就会一直使用旧版本。有些大客户还会要求公司开发针对其自身的特别需求&＃xff0c;并快速上线&＃xff0c;结果可想而知。”
\u0026#xD;\nAlice说道&＃xff1a;“其实&＃xff0c;这已经是短周期发布分支的变形&＃xff0c;即有多个活跃分支的长周期发布分支策略&＃xff08;如图3所示&＃xff09;。这种分支策略是应该尽量避免的&＃xff0c;它的复杂性和维护成本都很高&＃xff0c;因为&＃xff1a;
\u0026#xD;\nBob问道&＃xff1a;“有什么办法避免这种糟糕的多活跃分支开发策略吗&＃xff1f;”
\u0026#xD;\n“办法当然有&＃xff0c;但不能解决所有问题。”Joe回答道&＃xff0c;“比方说&＃xff0c;首先&＃xff0c;要确保每个版本的开发质量&＃xff0c;让客户放心升级。其次&＃xff0c;软件产品要支持自动升级。在通常情况下&＃xff0c;只要满足需求&＃xff0c;用户就不会轻易升级软件。所以&＃xff0c;要让软件具有自动发现新版本并在后台自动升级的能力。当然&＃xff0c;在升级后要通知用户。这样&＃xff0c;只要将新版本发布到互联网上的某个服务器上就行了。最后&＃xff0c;也是最重要的一点&＃xff0c;新版本发布周期要短一些&＃xff0c;不断快速地推出新特性&＃xff0c;这样就可以让用户对产品及研发团队有信心&＃xff0c;让客户感觉他们的需求很快就会被满足。”
\u0026#xD;\n“对于那些企业用户来说&＃xff0c;这种方法可能不管用。因为&＃xff0c;企业内网很少可以连通外网。”Alice说道。
\u0026#xD;\n“如果是这种情况的话&＃xff0c;除了软件本身质量好且能自动无缝升级以外&＃xff0c;在销售时可以与客户签订协议&＃xff0c;告知所售软件版本的生命周期&＃xff08;比如18个月&＃xff09;以及升级条款&＃xff0c;促使企业升级该软件&＃xff0c;比如免费的大版本升级&＃xff0c;或者因缺陷原因可免费升级等等。”Joe回答道。
\u0026#xD;\n“嗯&＃xff0c;我们开发的是游戏软件平台&＃xff0c;部署在互联网上&＃xff0c;所以不会遇到这个问题。”Alice说道。
\u0026#xD;\nJoe微笑着说道&＃xff1a;“我们将会面临另外一种问题&＃xff0c;即多个小团队开发不同的游戏组件问题。”
\u0026#xD;\n“哦&＃xff0c;对了&＃xff01;现在我们的游戏平台中虽然仅有几个游戏&＃xff0c;目前还一起在主干上开发。但在下一版本中&＃xff0c;我们会增加大量的游戏组件&＃xff0c;那应该如何应对&＃xff1f;我们的持续集成环境应该是什么样的呢&＃xff1f;”Alice大声地问道。
\u0026#xD;\n“嗯&＃xff0c;是个好问题&＃xff01;”Joe回答道。“我已经有了一些想法。我们内测结束后&＃xff0c;再详细讨论吧&＃xff01;时间也不早啦&＃xff0c;大家回去休息吧&＃xff0c;周末愉快&＃xff01;”
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有