我现在的增量补丁的整理方式

admin 发布于：2018-05-18 14:00:41

阅读：loading

记不得最早时的投产文件是怎么整理的，也忘记是如何去投产的了，印象深的部署就属前几年机构CRM项目中的全量war包的部署了，使用MyEclipse的将项目导出war文件，然后再使用另外维护的测试、生成等环境的同样的目录结构的文件进行覆盖替换，通过WAS或PaaS的控制台和命令进行投产。

近两年所处的现状是使用增量部署的方式进行投产，加上又有每天必须提交代码的限制（基本上），如果模块功能在修改或编码的周期较长，就非常不利于后期的补丁整理了，以前都是一段时间一提交，然后整理补丁时都是根据eclipse的svn插件上的文件修改图标去找修改的文件，下面具体说下增量整理投产补丁文件的方式吧。

第一种，根据svn的文件修改的图片去选中整理，这种方式较为简单，即在eclipse的Package Explorer（包资源管理器）中依次去选择需要整理的代码文件，包括java、jsp、css等各种资源文件，而后点击右键导出Jar文件的方式即可，将导出的Jar文件解压后基本上就是各个补丁文件，需要注意这种方式生成的文件结构是否符合需要（这种方式多年没使用过了，本文描述纯回忆），这种方式就比较适合允许隔段时间提交代码的方式，另外按住Crtl键依次选中文件的方式也时常不爽，一次没按住或选错了也挺麻烦。

第二种，使用eclipse的Navigator（导航）窗口整理，默认这个窗口是隐藏的，相信很多人并不知道这个窗口，它可以将整个workspace下的所有项目的所有文件都给树形展示，包括class文件，可以直接选择所有的文件进行导出，在导出时选择同时生成文件层级结构，这样就可以直接导出补丁文件包，使用场景和弊端与第一种完全一致。

Eclipse Navigator.png

第三种，使用maven编译的目录拷贝，貌似曾经这么干过，时间久了就不细说了。

第四种，从SVN的提交历史记录中查找，这是近两年琢磨出来的整理方式，也是个人觉得最靠谱的方式，具体应用场景如下：

1）符合每天提交代码的规范（约定）；

2）提交代码填写（伪强制）注释；

3）随时查找代码提交历史；

从SVN的客户端“小乌龟”筛选出自己近期（本次）的代码提交历史，按需将所有待投产的文件整理成列表，至于具体的筛选则是根据自己的用户名将过滤出所有个人提交的代码历史记录，同时根据提交代码的注释自行区分，参考如下图所示：

Show log.png

Show Log Detail.png

可以根据各种信息进行筛选，一般都是自行整理补丁，所以筛选这里输入作者名称居多，另外如果有日期区间较短无法显示更多的提交明细时，可通过点击下方的Next 100去加载更多的提交历史，可同时多选多条的提交明细数据，小乌龟会自动的将所选的提交历史中对应的相关文件进行去重复，我们只需要将去重后的列表项导出或拷贝至文件中即可，特别提示：除了右键的Export菜单外，还可以使用Crtl + C的方式复制，虽没有复制的右键菜单，但不能限制你的想象力。

找到所有相关提交的文件后，将其复制后存储至Excel中，可使用Excel的排序功能，将所有的路径排序显示，便于按照模块去找对应的补丁文件，参考如下图所示：

提交明细.png

此外，我习惯将所有的补丁放置在code目录下，同时将所有文件按照实际部署的路径进行一一创建后放置在对应的目录，先将编译后的目录地址拷贝（具体到具体的classes下的包路径，通常是/分割）；至于创建目录则采用Windows的快捷键鼠标右键+F，创建完后将路径粘贴，粘贴后的文件夹名称会自动的去掉其中的/，然后再剪切剩余的路径在创建子级文件夹，如此如此就完事了。

附增量和全量部署的优缺点（想到哪里就写到哪里）：

增量部署的好处：

1）、部署简单，每次只关心本次需投产的补丁文件；

2）、功能出错率较低，其它不投产的功能不受影响；

弊端：

1）开发测试与生产等环境的代码会存在不一致的情况；

2）时间越久部署功能越多（含有接入第三方系统或接口等）移植越麻烦；

3）补丁整理繁琐；

4）见全量部署的好处；

全量部署的好处：

1）、部署代码包方便整理，直接打包即可；

2）、部署的代码均为目前最新的代码；