首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 软件管理 > 软件开发 >

升级包制造

2012-07-25 
升级包制作做升级包其实不是一件很容易的事情,并不是完全没有技术含量的,另外也很需要耐心和细致。同时,如

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

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

现在回头想想,这个简单是有原因的:

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、制作升级包时,还要考虑备份和回滚等,才能保证升级的安全性

热点排行