升级包制作

做升级包其实不是一件很容易的事情，并不是完全没有技术含量的，另外也很需要耐心和细致。同时，如果平时有到位的管理手段，在制作升级包的时候也会提高效率，减少工作量

在前一家公司的时候，有一段时间负责维护公司的门户网站。虽然代码改动的频率也挺高的，不过每次升级就特别简单。

现在回头想想，这个简单是有原因的：

1、领导对网站可用性没有硬性的指标，所以找个夜深人静，甚至中午午休的时间升级就可以了，不需要热部署什么的

2、网站搞了几年下来，数据库表结构已经很稳定了，各种小修小改主要都是代码层面的。所以每次升级的时候，不涉及数据库脚本的升级

3、服务器就在公司机房，只有这么一套，所以不涉及版本管理的问题

4、每次升级也很简单粗暴，就是把整个.war包扔上去，重启，不需要做升级补丁

现在做的产品，上述的条件基本不具备：

1、应用如果停机升级的话，对商用会有很大影响，所以绝对不能频繁重启，要保证升级的成功率

2、应用尚未稳定，常常有数据库层面的变更。除了要专门制作数据库升级脚本之外，还要考虑保留业务历史数据，不能简单地drop create

3、应用不是集中部署的，在好几个局点都有不同的版本，研发除了trunk之外，还有若干个branch，所以涉及到版本管理的问题。比如说捷克跑的是B110，上海跑的是B080，那要一起升级到SPC001，就需要制作不同的升级包

4、升级不一定是全量替换，需要比对筛选出有区别的文件，以补丁的形式发布

这里先简要地记录几条制作升级包的注意事项，后续再慢慢完善

0、总的来说，制作升级包首先要明确两点，即现场的版本，以及目标版本。一个是头，一个是尾。明确了这一点，才能进行文件的比对，特别是比对sql脚本的差异，制作升级sql

1、对于代码文件的替换，比如.js，.css，.jsp，.class等，有一种最简单粗暴的方法，就是直接全量替换。比如说，直接把/jsp目录给全量替换了，不去考虑其中有哪些.jsp是改动过的

2、对上述代码文件的替换，如果平时有比较完善的管理手段，比如说每次修改都用列表进行记录，那在制作升级包的时候，就可以根据这个列表，筛选出修改的文件。但这依赖于平时的管理。还有一种方法，就是比如从B100升级到B110，可以取B100的tag，然后用svn的比对功能进行比对

3、对于配置文件的升级，因为可能开发提供的只是一个模板，实际是在现场进行配置的，比如说域名，IP这些，都是会根据现场的环境来调整的。所以这类配置文件的升级，可以在制作升级包时事先填好，也可以发布到现场，提供升级指导要求现场配置。

4、配置文件尽量集中存放，或者有详细的文档说明配置文件的位置，这样在制作升级包的时候才好筛选，以免遗漏。配置文件的修改，也可以在平时就进行跟踪记录

5、SQL脚本的升级，是最麻烦的。因为直接覆盖肯定是不行的，一般都需要比对前后sql的区别，专门制作升级脚本。比如B100是insert 123，B110是insert 456，那就需要专门写一个update 123 to 456

6、sql脚本也应该集中存放，这样制作升级包的时候就容易筛选比对

7、脚本的变化，是特别需要记录的。因为普通的文件，毕竟还可以全量替换。但是这个方法对sql脚本升级行不通，所以通常需要筛选，这样的话，平时的记录就可以发挥作用了

总结一下：

1、制作升级包的前提，是明确当前版本和目标版本。这样文件的比对才能有的放矢

2、文件的存放路径要可控。比如sql脚本统一存放，配置文件统一存放，jsp、js都有合理的目录规划，这样取文件才不会遗漏

3、普通的文件，有一种简单的方式是全量替换。即不管文件是否有改动，都统一覆盖一遍，这样肯定是不会有遗漏的。但是要注意一点，如果升级的时候，需要删除一些旧的文件，这个方法就行不通了

4、如果是配置文件，可能需要根据现场的情况，进行灵活的调整。可以在升级包里根据现场的情况事先配置好，也可以提供指导文档，在现场进行配置

5、对于sql文件，情况是最复杂的，需要比对2个版本的sql差异，专门制作sql升级脚本，比如update alter等

6、精确的方式，就不应该全量替换，而要筛选出需要升级的文件。这有两种方式，一种是依赖平时的跟踪记录。这种方式可以减少制作升级包时的工作量，但会增加平时的工作量。另一种方式是用svn进行比对

7、制作升级包时，还要考虑备份和回滚等，才能保证升级的安全性