版本管理及升级包制作小结

近期版本计划如下图,trunk上继续测试,修改BUG。同时拉一个开发分支,做现场的定制需求开发,8月底发到现场

版本管理及升级包制作小结_第1张图片

其中spc003b020、spc005b020是要发到现场的,所以8月底就需要制作升级包,从spc003b020升级到spc005b020

再之后,会把分支上的代码合入trunk,发布GA版。届时再从trunk上做升级包,把现场版本从spc005b020升到GA

在此过程中,branch需要保留,用于定位现场问题,并出补丁。trunk上的bug修改,不需要向下合入branch,但是branch上修改的问题,都需要向上合入trunk。否则在版本替换的时候,branch上修改的问题就丢失了

图比较简单,可以总结出以下几条:

1、每一个版本都需要tag,这点很关键。之后无论是需要定位某一个版本的BUG,或者基于某个版本制作升级包,如果没有tag,就做不到。比如某天发了一个版本,但是没有打标签,那代码变化之后,要定位这个版本的问题,或者要基于这个版本升级,就做不到了,因为找不回当时的代码

2、制作升级包的第一步,就是要明确目标,即从哪个版本升到哪个版本,有始有终,做升级包才有据可依

3、找到了起点和终点之后,就可以制作升级包了。可以通过比对2个tag的差异,找出需要升级的文件。也可以通过平时记录的方式,把每一次的变更记录下来,这样制作升级包更容易

后者的方式我认为是更好的,但这需要比较好的管理,日常的管理成本也会高一些。如果执行不到位,那变更就会有缺失,依赖变更文件,就会出现升级不完全甚至升级失败

需要重点关注的是sql脚本,和动态的配置文件。因为一般的.class、.jsp等文件,大不了不做筛选,全量替换。但是对于数据库变更,和动态的配置文件变更,如果平时没有做好记录和文件归档,制作升级包时就会困难重重

4、一个产品,版本不断升级,维护版本图是一种不错的实践。有点像小学时候数学题的线段图,有了这么一个图,对版本就能做到心里有数

5、今天问了一个比较愚蠢的问题:如果从某一个tag拉出了branch,那么在这个branch上,之前的tag还能看到吗。

实际上,branch和tag是放在不同的路径下的。一般svn库上,有几个目录,分别是trunk、branches、tags。

branch和tag是放在不同的路径下,所以所有的tag,都是可以看到和比对的

6、以前有一个问题,我一直不理解。为什么代码稳定一段时间之后,就不允许擅自提交代码,即“黑代码”,必须有修改BUG才能提交,而且BUG必须有记录。

我原先认为,有一些开发人员自己的优化和重构,应该是鼓励的,为什么要禁止呢?

首先,擅自提交的代码,是没有测试工作量支撑的,也就不能保证不引入问题。

但更重要的,实际上是版本管理的问题。当代码基本稳定之后,就可能对外发布。擅自提交的代码,即使能保证不引入BUG,但如果没有有效跟踪的话,在制作升级包的时候,就有可能遗漏掉。

如果每次发布版本,都是全量发布,那么其实问题不大,因为虽然“黑代码”没有跟踪,但是由于是全量发布,所以实际上也发出去了,现场的版本和trunk上的代码,依然能保证是一致的。

但是实际中,让现场全量重装基本是很困难的(停机时间、保留业务数据等),所以一般都是通过升级包的方式来发布。那么如上文所说,制作升级包有时是依赖代码变更记录的,而“黑代码”没有记录,所以就不会被包含在升级包里。

那么当现场执行了升级包之后,现场没有“黑代码”,但是“黑代码”却已经提交到trunk上了。那么现场的版本,就与trunk不一致,就为定位问题和继续制作升级包埋下了隐患

所以,问题的关键,不在于是否“有BUG才能改代码”,而是“改的代码是否有记录”。之前“有BUG才能改代码”的规定,实际上是把BUG清单,作为代码跟踪的入口

你可能感兴趣的:(版本管理,升级包)