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

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



其中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清单，作为代码跟踪的入口