一、目前svn的标准目录结构:
trunk:主干,如果说把一个软件项目从开始到消亡比作一个故事的话,主线情节都在这里被SVN记录着。
branches:分支,有很多种用法,比如:版本发布维护分支、新特性开发分支,甚至是缺陷修复分支等等。
tags:标签,或者叫快照,某个版本发布时候,都在这里留档。
二、管理模式
1、集中式:trunk进行主线开发
一般的,我们的所有的开发都是基于trunk进行开发,当一个版本/release开发告一段落(开发、测试、文档、制作安装程序、打包等)结束后,代码处于冻结状态(人为规定,可以通过hook来进行管理)。此时应该基于当前冻结的代码库,打tag。当下一个版本/阶段的开发任务开始,继续在trunk进行开发。
此时,如果发现了上一个已发行版本(Released Version)有一些bug,或者一些很急迫的功能要求,而正在开发的版本(Developing Version)无法满足时间要求,这时候就需要在上一个版本上进行修改了。应该基于发行版对应的tag,做相应的分支(branch)进行开发。
举例:刚刚发布版本1.1.0,现在正在开发1.2.0。此次上个版本出现bug需要紧急修复。要在1.1.0的基础上进行bug修正。顺序如下:
(1)1.1.0开发完成,代码冻结。
(2)基于已经冻结的trunk,为release1.1.0打tag。
此时的目录结构为:
svn://project/
+trunk/(freeze)
+branches/
+tags/
+tag_release_1.1.0(copy from trunk)
(3)1.2.0进行开发,trunk此时为1.2.0的开发版本
(4)发现1.1.0有bug需要紧急修复,基于1.1.0的tag做branch。
此时的目录结构为:
svn://project/
+trunk/(dev 1.2.0)
+branches/
+dev_1.1.0_bugfix(copy from tag/release_1.1.0)
+tags/
+tag_release_1.1.0(copy from trunk)
(5)在dev_1.1.0_bugfix分支上进行bug修复,trunk仍然做1.2.0的开发。
(6)在dev_1.1.0_bugfix完成后,基于dev_1.1.0_bugfix分支拉出一个tag分支:tag_release_1.1.1
(7) 将dev_1.1.0_bugfix分支的内容merge到trunk上。
此种模式trunk永远是开发的主要目录。也是目前现状的开发模式。
2、分散式:分支进行主要开发
这种开发模式当中,trunk是不承担具体开发任务的,主要承担版本发布,一个版本/阶段的开发任务在开始的时候,根据已经release的版本做新的开发分支,并且基于这个分支进行开发。
举例:
(1)1.1.0开始开发,从trunk上拉取dev1.1.0的branch。
此时的目录结构:
svn://project/
+trunk/(不承当开发任务)
+branches/
+dev_1.1.0(copy from trunk)
+tags/
(2)1.1.0开发完成后,merge dev1.1.0到trunk上。
此时的目录结构:
svn://project/
+trunk/(merge from dev1.1.0)
+branches/
+dev_1.1.0(开发任务结束,冻结)
+tags/
(3)根据trunk做1.1.0版本的tag
此时的目录结构:
svn://project/
+trunk/(merge from dev1.1.0)
+branches/
+dev_1.1.0(开发任务结束,冻结)
+tags/
+tag_release_1.1.0(copy from trunk)
四、两种模式的区别和思考
1、两种模式的共同点是:出现BUG的时候,都需要从tag上拉取分支进行开发。
2、两种模式的区别是:trunk上开发,还是在branch上开发。
由此总结:1、无论选择哪一种方式,一定需要打TAG分支,用于在出现bug回滚,新版本又在开发期间,可以从tag拉取代码进行修复。
2、结合jenkins流程化控制管理,项目必须适应的变化:
(1)必须摈弃掉增量手工替换文件的发版方式,每次发版全量替包。
(2)项目使用maven或者ant管理,用于jenkins的自动化构建使用。更推荐使用maven。其有清晰的文件目录以及maven私服来管理第三方依赖包。
(3)如果使用集中式开发,trunk主线,那么测试环境发布trunk主支。在最后一次成功的版本基础上打tag,并且生产环境发布tag分支。
(4)如果使用分散式开发,trunk主线只承当合并。每次新版本都拉取一条或多条branch。版本经理合并branch代码到trunk进行测试。测试环境发布trunk分支。
最后一个成功版本打完tag后,可以直接将镜像推送到habor生产进行发布。
五、后续优化事项
1、引入jira,设想在jira上新建版本管理。版本统筹任务,svn提交的pre-commit对任务的状态进行判断,如果任务已经终结,测试需要将相关bug重新录入任务。
严格的svn代码提交控制。
2、使用jenkins自动生成tag版本。
ps:所谓严格代码控制,都是为了让开发对发版存有敬畏之心!