基于SVN的项目管理

我们在此处不讨论 GIT 比 SVN 好多少,也不讨论 Maven 和 Gradle 哪个好用,基于现有的开发环境,大多数公司还是采用 SVN + Maven 来进行项目管理——因为这已经满足了大多数的代码管理需求,并且对于一个成熟的公司来讲,项目管理工具的改变可能需要很大的成本和决心,基于 GIT 的项目管理将会在以后详细介绍。

做程序开发和项目管理的老银棍们肯定知道,基于 SVN 的项目开发管理有两种方式:集中式开发和分散式开发,对应正常的语言描述来讲,集中式开发对应的是基于trunk进行开发,而分散式开发对应的就是基于branches进行开发。两者并没有绝对的好坏之分,具体采用哪种方式,完全凭个人喜好、项目架构和公司规定进行选择。

集中式开发——基于Trunk的开发

基于主干的开发方式可能是比较主流的开发方式,三个目录的主要定义如下:

trunk:开发工程(非稳定)

tag:我们认为稳定的发布包

branches:BUG、需求变更分支

用语言描述一下开发步骤:在trunk中新建一个项目,此时版本号是1.0.0-SNAPSHOT,分配权限给所有的开发人员,所有开发人员功能开发完毕之后提交代码到trunk,测试基于trunk进行测试,此时trunk处于锁定状态——不允许再在trunk上进行新功能的开发,测试完毕之后打tag,至此1.0.0-RELEASE版本正式发布,trunk中的版本号变为1.1.0-SNAPSHOT,解锁Trunk,所有开发人员开始开发1.1.0-SNAPSHOT,此时如果发生未测出来的BUG和需求变动,基于1.0.0-RELEASE的tag打分支1.0.0-PATCH,所有相关开发人员对1.0.0-PATCH进行维护开发,同时主干的1.1.0-SNAPSHOT也在同步进行。

基于SVN的项目管理

这里很多人会问,如何将1.0.0-PATCH中的代码合并到1.1.0-SNAPSHOT中?这里用一个场景来具体描述

程序员小张负责用户注册模块的开发,在整个项目1.0.0-RELEASE发布之后,1.1.0-SNAPSHOT中小张需要对注册模块进行一个升级,此时(注意,代码没有正式开始编写),在线上运行的1.0.0-RELEASE版本发现了一个隐秘的BUG(可能是代码BUG,也可能是业务BUG),小张需要先为1.0.0-RELEASE这个tag打出一个分支1.0.0-PATCH-01对这个BUG进行修复,修复完毕之后,将1.0.0-PATCH-01合并到主干中,生成版本1.0.1-SNAPSHOT,然后发布到Tag中,此时Tags中包含1.0.0-RELEASE和1.0.1-RELEASE两个tag,之后,进行新版本1.1.0-SNAPSHOT的开发——这是最好的结果。

但是事实并非如人所愿,我们最常遇到的情况是1.1.0-SNAPSHOT已经开发了一段时间,此时发现了1.0.0-RELASE中的这个隐藏BUG,需要紧急修复,我们这里同样用一个场景来具体描述。

程序员小张负责用户注册模块的开发,在整个项目1.0.0-RELEASE发布之后,1.1.0-SNAPSHOT中小张需要对注册模块进行一个升级,此时(注意,代码已经正式开始编写),在线上运行的1.0.0-RELEASE版本发现了一个隐秘的BUG(可能是代码BUG,也可能是业务BUG),小张需要先为1.0.0-RELEASE这个tag打出一个分支1.0.0-PATCH-01对这个BUG进行修复,修复完毕之后,将1.0.0-PATCH-01单独上线接下来的故事就比较复杂了,小张需要将1.0.0-PATCH-01中的代码手动的与正在开发的1.1.0-SNAPSHOT进行一个合并——这是常见但是异常的结果

为什么说第二个场景属于常见但是异常,这非常考验整个PMO管理——为什么会出现紧急BUG?为什么需要紧急上线?这会造成两个最直接的麻烦:

1. 线上版本不是RELEASE版本的,而是一个分支PATCH。

2. 将PATCH中的代码合并到正在开发的代码中会异常痛苦。

如果遇到这样的情况,首先不能慌张,尽可能的先将线上的BUG解决掉,再来考虑如何在新版本中合并代码的问题,这样肯定会造成1.1.0的延期发布以及1.0.1的缺失,严重的可能还需要重新审视——但是你避免不了,不过责任是比较清楚的。

当然为了能够尽可能的避免这种情况出现,一般建议新版本上线后的一段时间内(比如一个礼拜)开发人员先暂停开发做一个休整,做做项目总结、补充一些文档之类的工作,之后再进行1.1.0的迭代,这样做不仅能够完美收尾,还能减少情景2出现的概率,对公司、开发人员以及项目管理来讲都是有利的。

分散式开发——基于Branches的开发

分散式开发是基于分支branches进行开发,也是我个人比较喜欢的一种方式,其三个目录的定义如下:

trunk:稳定的主干

tag:我们认为稳定的发布包

branches:开发切片

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:http://www.heiqu.com/4c24a72a662b6598ba63ebe8db574892.html