知识库总目录: No.0 Web开发知识库
出于对于更新效率的要求,我们在更新生产环境时,比较多的是采用增量更新的方式:即仅将需要更新的文件打个包,在生产环境解压(一般需要重启服务)即可完成更新。
而在这个过程中有几种漏洞,不可不察。
1.内部类
对于java文件更新申请人一般提交的是源文件(即java文件)而非编译后文件,然而增量更新打包清单往往仅根据源文件清单生成而来;
但若某个源文件中存在内部类,其编译后,每个内部类会独自生成一个class文件,更新清单会将其遗漏。
因此建议由更新申请人应注明本次更新中存在内部类的java文件,由更新执行人手工修改更新清单,将内部类class文件补全
例:
A.java
A.java中有个puclic class A,A中有个成员内部类 B,方法内部类C,还有一个匿名内部类new TimerTask()
则编译出的class文件有
A.class
A$B.class
A$1C.class
A$1.class
2.特殊配置文件
特殊配置文件即上篇中提到的生产、测试环境配置内容有差异的配置文件。
由于无论是开发环境,还是基线测试环境,这些特殊配置文件中内容都是配置的测试环境内容,当这种文件需要提交更新时,提交人一般提交的是测试版(要先发布在基线测试环境上),而后续又将测试版发布在生产环境,后果相当严重。
此时,也建议由更新申请人应注明本次更新中存的特殊配置文件,以便执行人做后续处理。
3.常量
先看一个例子:
原代码中B跟A有关系,不过编译后就跟A没啥关系了,B编译完后就成了这个样子:
所以当常量内容发生变化修改了常量所在的类后,只更新这个类没有用,而是需更新所有调用类。