我们的项目中准备尝试CI和敏捷,使用svn作为版本管理工具。在开发方式上有主干开发和分支开发两种方式,我们设想的方式是:

1. 项目启动时,建立svn代码路径,今后(包括各种升级)都是在主干路径上进行

2. 当完成一个迭代的开发与测试后,建立新分支(branch),qa在该分支上进行回归测试,确保没问题之后,使用该分支上线。除非有bug,否则不允许修改该分支代码,并且修改后的代码必须立即merge回主干以避免冲突。

在这种主干开发方式中,关键点我认为是,开辟新分支前需要进行完整的UT和自动化测试,保证代码的较高质量。否则一旦开辟新分支测试后,发现bug过多,将导致rd既在主干进行业务功能开发,又在分支上修bug,还得将分支代码merge回主干,反而会中断正常工作、增加工作量。

以下摘录这两种开发方式的定义:http://www.quanlei.com/2012/03/3075.html

1、主干开发

在这种模式下,开发人员几乎总是签入代码到主干,而使用分支的情况极少。主干开发有如下三个好处:

  • 确保所有的代码被持续集成
  • 确保开发人员及时获得他人的修改
  • 避免项目后期的“合并地狱”和“集成地狱”

缺点:

每次向主干签入并不都是可发布状态

2、按发布创建分支

在这种模式下,在某个版本即将发布之前,创建一个分支,该发布版本的测试和验证全部在该分支上进行,而最新的开发工作仍旧在主干上进行。要遵循如下规则:

  • 一直在主干上开发新功能
  • 当待发布版本的所有功能都完成了,且希望继续开发新功能时才创建一个分支
  • 在分支上只允许提交那些修复严重缺陷的代码,并且这些修改必须立即合并回主干
  • 当执行实际的发布时,这个分支可以选择性的打一个标签

除了这种主干开发-分支上线的模式外,还有多分支的开发模式,像http://www.uml.org.cn/softwareprocess/201002094.asp中,就提倡使用三分支,即开发分支、测试分支、发布分支,但是这样在多个分支间的merge会较为频繁。

Leave a Reply