Perforce Helix 分支策略

 

因Perforce Helix具有强大的分支管理功能,创建分支不会复制文件,所以快速创立分支、性能稳定、代价很低、理论上可以随便创建(不像SVN,文后有比较)。但是在实际项目管理应用的时候,有经验的项目管理者不会随意地创建分支,如果不是很理解分支管理策略的话,就会造成创建出重复多余没有太大意义的分支,造成开发团队的混乱。下面介绍的是Perforce Helix Core的分支策略,产品经理或项目经理想实现基于测试驱动,主(基)线开发、并行开发的模式研发的话,就可以放心大胆地创建你想好的分支,大幅度提高产品或项目的迭代速度,软件研发平台上面的版本管理工具的瓶颈在Perforce Helix Core面前将彻底被打破。

 

    一、常用开发模式

如图所示,我们可以看到包含了几种主要的分支:

・主分支,主要管理我们的最新的稳定的随时可以执行的代码。

・开发分支,根据项目需求从主分支上建立的的分支,用于项目开发。

・测试分支,用于项目测试的分支。

・发布分支,经过验证的用于发布的分支。

・功能分支,具体的功能开发用,原则上只和开发分支交互。

・故障分支,发生bug时的故障对应分支。

 

其中,主分支和开发分支是一直存在的,当一个阶段开发完成,创建测试分支,测试通过后,我们可以创建发布分支,功能分支和故障分支只有在需要的时候才创建。

 

例如当我们有一个新需求时,从主分支新建一个开发分支,其中如果有新功能需要开发,我们可以在开发分支上再创建功能分支,当新功能开发、测试完成后再合并回开发分支;开发途中,根据需要可以从开发分支合并到测试分支,测试通过后,合并测试分支到主分支,当一个阶段开发、测试完成后,我们就可以将开发分支合并到主分支,再从主分支创建发布分支。

在发布版本中发现问题时,我们可以创建故障分支,对应后将结果合并回发布分支,再从发布分支合并到主分支,最后合并到开发分支,从而保证开发代码是最新的。

 

二、部分发布

有些情况下,当我们开发了多个功能后,只需要发布其中的部分功能时,我们该怎么对应呢?

如图所示,我们开发了功能A、功能B、功能C等3个功能,现在只需要发布功能A和功能C,我们在开发分支上对功能A和功能C测试完成后,就可以利用Perforce Helix只将功能A和功能C的变更部分从开发分支合并到测试分支,测试通过后,从测试分支合并回主分支,再从主分支创建发布分支,就可以实现部分功能的发布。

 

 

三、利用Stream

Perforce Helix可以依据上述的分支策略使用通常的分支功能来管理我们的分支,但随着分支的增加,我们很难掌握项目中所有分支之间的关系。

为了便于我们在开发中更好的使用分支,Perforce Helix为我们提供了Stream功能,Stream为我们提供了可视化的分支管理模式,能清晰的了解各个分支之间的关系,使我们能随时掌控项目的所有分支的情况,从而提高我们的开发效率。

 

如图所示,这是按照前面所讲的分支策略做成的Stream,我们可以看到,Stream提供了几种分支类型:

 主Stream,分支策略的主分支使用此类型

 开发Stream,分支策略的开发、测试和功能分支使用此类型

 发布Stream,分支策略的发布分支使用此类型

 任务Stream,短期间使用,分支策略的故障分支可以使用此类型

注:Stream和Stream之间的线表示了Stream间的关系,箭头表示了Stream间代码可以合并的方向,通常开发Stream只能将发生的故障合并到主分支。

 

在这个图上,我们能看见项目里所有Stream间的关系,其中,任务Stream完成后,可以将任务Stream改为需要的Stream类型,如图:当故障对应完后,Task Stream的rel-bug变更为Release Stream的release1.1。

 

四、Stream案例

  使用Stream可以方便的根据需要增加变更Stream。

  以下是在运用中Stream的变迁案例:

 

                     (6)

 

     如图所示:

(1)项目刚开始,规模较小时,我们只需要有一个Main stream。

(2)开发测试到一个阶段后,有可以发布的版本时,我们可以创建一个发布stream rel1.0。             

(3)在rel1.0里发现有故障时,我们可以创建一个任务stream rel1.0-bug来对应。

(4)当故障对应完成后,将任务stream变更为发布stream rel1.1。

(5)有开发新的需求时,我们创建一个开发stream dev2.0。

(6)开发完成,合并到主分支后,我们可以再创建一个发布stream rel2.0 。

 

五、SVN比较

首先,SVN没有Stream功能,只能用通常的分支管理方法,当分支增多时,分支关联关系难辨,无法可视化,管理会变得越来越困难。

 

其次,SVN对大文件,大数据量文件的支持不太好,随着文件增多,提交履历增多,分支增加,SVN的操作速度会越来越慢,甚至拉分支会途中失败,合并途中失败更多。这样基本上现场无法实现上面说明的基于主线模型或测试驱动模型的代码管理,成为研发工具链平台实现高效的严重瓶颈的链节点。