敏捷开发中最基本的分支管理模式实战和补遗

关于3分支的开发方式,请详见我的另一篇随笔 <敏捷开发中最基本的分支管理模式解析 >; 3分支模式的示意图如下


如果你和你的开发团队同时面临以下几个问题,那么我强烈建议你至少考虑采用3分支的开发模式:

·         你开发只用一个分支或两个分支.

·         你的项目已经进入维护阶段,就是说项目本身已经上线使用.

·         用户的后续修改很多,而且仍然会有突发性的紧急错误修复.

·         你的代码需要通过测试人员测试才能发布.

·         你的发布人员就是简单的把现有的分支打包发布.

如果你的项目组存在以上几个问题,那么可以说作为一个上线项目,你们的处境非常不利,你们每一次的发布都可能对原有系统产生不可预计的破坏;但不发布任何改动显然是不行的,为不断满足客户的要求,系统必须升级;要使每一次的发布对系统的影响降到最低,3分支方案是最基本的解决办法.

要采用3分支的开发模式,其实并不困难,首先,我先假设一下你们项目组拥有以下3个角色(并不一定是3个人):

Ø 开发人员

Ø 测试人员

Ø 发布人员

如何产生3分支:

Ø 首先,确认当前版本的代码和现行系统的内容一致.

Ø 把现行的分支命名为主干分支(Main)

Ø 从主干分支分出2个分支,分别命名为开发分支(Development)和发布分支(Release)

Ø 明确分支的负责人: 开发人员负责开发分支,测试人员负责主干分支,发布人员负责发布分支.

如何使用3分支

v 开发人员

Ø 开发人员人员可以在开发分支上开发当前版本,并任意签入代码. 注意已经提交测试的版本,不能在开发分支上修改.

Ø 开发人员仅当被测试人员通知修复错误时,才能在主干分支上修改指定的错误代码,并签入.

Ø 开发人员仅当被发布人员许可的情况下,才能在发布分支上修复紧急错误;注意紧急修复一般都是非常紧急和微小的,如果改动较大,应该考虑进入版本开发.

Ø 如果开发人员认为某一个版本已经开发结束,他有权把开发分支现有的代码完全合并入主干分支,提交测试.(只有一个特例,就是上一个版本还没有通过测试并发布,那么下一个版本就不能合并入主干分支,这属于项目管理中的失误,并不在本文章讨论范围)

v 测试人员    

Ø 测试人员有权在测试出错误后,让开发人员在主干上直接修复.

Ø 测试人员需要定期,将主干分支代码完全合并到开发分支. (这一步看似简单, 但其实十分重要!)

Ø 测试人员可以在测试通过后,将主干分支完全合并到发布分支,移交发布人员准备发布.

v 发布人员

Ø 发布人员可以允许开发人员直接在发布分支上修复紧急错误.

Ø 紧急修复后,发布人员需要把发布分支完全合并到主干分支.

Ø 发布人员可以编译发布分支,并制作发布版本.

 

不过开发中不可能是一帆风顺的,紧急事件和临时变更经常发生,面对各种开发中的紧急情况,我们应该如何利用多分支开发来减少临时变更带来的风险.(而且在处理某些特殊事件时,必须采用面向修改集的代码合并技术才能解决问题,但产生的合并问题是不可预见的,这也是出现临时变更时必须面对的风险.)

 

特殊场景	处理办法
开发版本中任务需要紧急发布	不能保证开发的质量,对系统稳定极为不利,建议至少等到测试阶段再更新
测试版本中任务需要紧急发布	前提是该任务已经通过测试,然后将该任务相关的修改集单独合并到发布分支,然后紧急发布系统
开发版本中任务被取消	回滚该任务对应的修改集,如果和其他代码重叠,解决合并问题
测试版本中任务被取消	同样采用回滚的方式,但回滚后,代码必须再次合并回开发分支
开发版本中任务被延期	在版本开发结束时,采用修改集合并的方法代替最新版合并方式,把除该任务以外的修改集一一合并到主干分支,留下的修改集进入下一个版本.
测试版本中任务被延期	类似于上面的方法,把版代码合并到发布分支时,跳过该任务对应的修改集,把剩下的修改集分别合并入发布分支发布,被跳过的修改集保留到下一个版本提交.
紧急错误修复被取消	回滚紧急修复代码,如果该修复代码已经合并回主干分支了,还需要把回滚后代码再次合并回主干分支,当然通过定期合并,还将合并回开发分支.