一种软件打包发布管理方法

摘要

本发明的一种软件打包发布管理方法，在确认版本的迭代内容以后，在打包的时候选中相应的版本号，只生成需要的脚本，精确地控制需要发布的内容，避免未测试的代码部署到正式环境；在执行打包脚本时，对于源码没有更新的组件不进行重新编译，从而达到只编译改变的部分，缩短编译时间，达到增量编译；基于历史版本日志的版本回溯，每一次进行打包生成一个日志目录，当用户需要生成某次历史版本的时候，选中需要的历史版本的日志，从日志里面选出打包脚本，执行脚本命令打出需要的包，不需要每次打包的时候备份打出的包，仅存储本次打包产生的包，从而降低存储的空间，达到以较低的硬盘空间实现历史版本的维护。

说明书

技术领域

本发明属于持续集成的技术领域，涉及一种软件打包发布管理方法。

背景技术

Jenkins是一款广泛使用的开源持续集成软件，可兼容各种形式的编译和打包工作，支持多种SCM协议，对基于MAVEN的编译打包支持良好，支持定时自动执行和脚本。但是它使用的svn地址+最新版本的模式进行打包，无法进行组件版本的精细控制，打包的时候使用全量编译，不管代码有没有变更过都会执行编译的命令，耗费较多的时间。因此可能会产生以下的问题：

1.在测试之后发布之前提交的代码和部署到私服的JAR包会被打入最新的发布包中，生产环境中会有未测试代码带来的风险；

2.部分开始测试但未通过的代码将会影响版本的发布,特别是修改现有已经上线的产品和功能的时候,将会使版本无法发布；

3.版本回溯只能通过备份的方式,将发布的版本人为备份起来,占用较多的空间而且其内包含的各组件状态是黑箱状态。

发明内容

本发明的目的在于提供一种可精细控制的、可持续集成的、可增量编译的软件打包发布管理方法。

本发明一种软件打包发布管理方法，包括一软件打包发布管理系统，该软件打包发布管理系统包括：组件、组件子模块、项目、环境、历史版本管理模块、组件版本选择模块、打包模块、打包详情、下载详情，以及预编写的插件，该插件包括svn内容更新工具、maven项目管理工具和变更清零工具；所述软件打包发布管理方法，包括如下步骤：

步骤1、创建组件

对项目需要的组件进行分类创建组件子模块，便于通过组件管理和查找对应的组件子模块；

步骤2、创建组件子模块

设置是否需要构建当前组件的组件子模块，设置组件子模块的svn服务器地址和版本号，设置通过svn服务器地址下载的源代码存放在本地的目录，设置生成文件的类型，通过该生成文件的类型来区分生成打包脚本的是前端、后端、还是全部集合的包，设置是否可以引入外部链接，将上述的设置内容作为项目打包脚本生成的参数；

上述每一组件子模块是遵循maven的pom文件的结构来进行配置的；

上述svn服务器地址、版本号以及通过svn服务器地址下载的源代码存放在本地的目录为svn工具进行源代码管理的参数；

上述生成文件的类型，为了满足项目前后端分开部署，以项目打包脚本生成的参数形式来告诉maven编译成需要的文件类型；

svn工具根据是否可以引用外部链接的参数来执行导出单个文件或者整个文件夹；

步骤3、创建项目

设置打包管理的根目录，选择项目需要的组件子模块，形成打包该项目所需要的脚本的参数；

步骤4、创建环境

设置环境的目录，用来管理打包日志、文件下载、区分不同环境打包出来的文件，生成maven打包的时候不同环境的不同配置项参数和环境依赖的工具的地址；

每一个项目可以拥有多个环境，每个项目的其他环境都是依赖于测试环境来打包的，初始必须创建一个code为test的测试环境；

步骤5、执行脚本打包的预先编写插件

每个组件子模块都是一个小的项目，执行maven项目管理工具对组件子模块的管理的封装，对打包脚本里每个组件子模块进行依赖、清理、编译的项目管理工作；

执行变更清零工具来判断每个组件子模块的svn源代码是否有变化，若有变化则判断是否需要重新打包，若需要重新打包，进行打包的同时清除之前打包的包，同时对打包过程输出日志，该日志包括每个组件子模块打包成功日志、失败原因日志；

执行svn内容更新工具传入svn的服务器地址，以及当前需要更新内容的版本号，该svn内容更新工具先判断组件子模块是否存在本地，如果不存在本地，则直接检出代码且返回继续执行脚本，若存在本地，则获取存在本地的组件子模块的svn服务器地址和版本号，如果传入svn的服务器地址与存在本地的svn服务器地址不一致，则删除本地文件，然后再检出代码且返回继续执行脚本，如果传入svn的源代码版本号比存在本地的版本号大，则svn更新代码，如果传入svn的源代码版本号比存在本地的版本小，则表示需要检出代码且返回继续执行脚本，在svn内容更新工具对比源代码版本号的时候，对存在检出、更新、删除的变更标志的组件子模块记录到日志里面，同时svn内容更新工具还会记录svn的详细操作日志，包括进行了检出、更新、删除操作的组件子模块信息及时间信息；

步骤6、选择各个组件子模块的打包版本

用户选择项目，进入环境列表，选择环境，用户选择测试环境会出现“新建打包”按钮和历史版本日志列表，其他的环境只出现历史版本日志列表；

历史版本日志列表，映射maven项目管理工具在执行打包脚本的历史版本日志目录集合；选择环境列表除测试环境的任一环境进入历史版本日志列表，用户选择需要历史版本下的“打包”按钮转而执行步骤7.1；

用户选择进入测试环境，显示测试环境的历史版本列表，选择需要的历史版本，进入环境列表，这个界面会显示该项目所有的环境，当用户选择测试环境下的“打包”按钮的时候是对测试环境的历史版本重新打包转执行步骤7.1；当用户选择其他环境的“打包”按钮的时候，会把测试环境当前历史版本目录下的打包脚本拷贝到所选择的环境下转而执行步骤7.1；其他的环境是没有“新建打包”的按钮；

用户进入新建环境，点击“新建打包”，会进入展现出打包该项目的所有组件子模块，用户根据从开发人员收集到的svn更新内容，过滤选择需要升级版本的组件子模块、需要降级版本的组件子模块、或者需要禁用的组件子模块，转而执行步骤7.2；

确认发布/测试版本的各个组件子模块的内容以后，测试人员收集相关开发人员提交内容的svn版本，测试人员根据收集的svn版本，在打包的时候选中相应的版本号，对于其他的新增模块或者其他模块的更改或者本模块在确认版本后再提交的svn版本不予关注，系统只会生成需要的脚本，精确地控制需要发布的内容，避免未测试通过的代码部署到正式环境；测试人员在执行打包动作时把收集的内容进行版本日志记录，打包发布以后，测试人员针对版本日志记录进行测试，生成对应版本的测试报告，当测试人员想知道某个版本修改的内容，就可以查询版本日志记录以及对应版本的测试报告，从而做到每个版本有源可循；版本控制人员根据版本日志记录和对应版本测试报告，拷贝测试通过的脚本，执行脚本对生成环境的打包，该生成环境的打包必须在测试环境通过的基础上方能进行；

当开发人员将源代码通过svn提交到svn服务器的时候，svn服务器利用svn的钩子命令，把当前提交的源代码中包含的svn信息通过本系统的接口提交到“软件打包发布管理系统”，同时该接口通过匹配模块，把提交的svn信息跟组件子模块匹配起来，形成组件子模块的svn内容更新列表，供用户使用，上述svn信息包括版本号、svn日志和修改文件的url地址；

步骤7、生成打包脚本并执行

在生成脚本的时候根据制定好的打包规则会额外在脚本里面生成清除上次生成的包的命令和生成日志的命令；

每次执行打包脚本的时候先清除之前打包的包；接着根据当前时间和随机数生成一个历史版本目录，将当前的打包脚本拷贝进入历史版本目录，同时下面步骤8产生的日志和最终打出的包也放在这个历史版本目录，形成历史版本日志；

步骤7.1、根据步骤6选择的历史版本点击“打包”按钮，根据历史版本号将历史版本文件夹的打包脚本拷贝当前linux执行环境，并执行打包脚本；

步骤7.2、新建打包，根据当前的组件子模块的配置，该配置包括用户选择的打包版本、如果未选择以上次的版本为标准目录的内容，生成一条条数据，然后根据打包脚本生成规则在linux环境生成打包脚本，并在linux环境下执行该打包脚本；

步骤8、调用svn内容更新工具对现有的源代码进行管理

打包脚本执行的时候，自动调用svn内容更新工具对现有的源代码进行管理，利用svn内容更新工具根据打包脚本的服务器源代码地址、源代码下载的地址、以及源代码的版本号，与本地存在的源代码进行比对，当本地的源代码与服务端的源代码有改变的时候，更新本地的源代码，标志为更新，利用maven编译工具重新对改变的源代码进行编译，对于源代码没有更新的组件不进行重新编译，引用原来编译的结果，只编译改变的部分；打包脚本由一个个组件子模块组成的命令，执行打包脚本的每个组件子模块命令重复步骤7-8，直到所有脚本命令执行完成，产生包文件。

另外，所述的组件：用于对于组件子模块进行分类；

所述的组件子模块：是软件持续集成的基础，是构成项目的必要条件，项目是由一个个组件子模块组成；每个组件子模块通过创建名称和源代码来区分，由path来存放通过svn下载的源代码，由url来指定组件子模块的下载地址，组件子模块的类型用来区分在生成脚本打包生产的是前端、后端、还是全部集合的包，组件子模块的版本号用来指定第一次创建模块的版本，组件子模块输出方式包括up和export，通过生成脚本的参数来告诉svn是下载整个目录或者单个文件，maven编译生成脚本的参数用于下达在当前项目模块执行命令时是否创建组件子模块的指令；在创建组件子模块的同时还会生成组件子模块与项目的关系；

所述的项目：指的是持续集成的目标；

所述的项目环境：可用于区分正式环境和测试环境，只有在测试通过的版本下才能执行打包指令，可保证正式环境的准确性；

所述的历史版本管理模块:用于查看历史版本日志，测试人员根据历史版本日志来了解之前的打包范围是否跟预期的一致，同时可对历史版本进行重新打包；

所述的组件版本选择模块：通过svn的钩子把每次用户提交svn的组件子模块版本号、修改组件子模块的svn地址、以及把提交svn的更新内容提交到系统，根据现有的组件进行判断，如果修改组件子模块的svn地址与现存的一致，则更新该组件子模块与项目的关系，并标志为“更新”，用户根据是否标志为“更新”来选择是否发布版本，当然用户也可进入选择较早的版本；

所述的打包模块：当用户进入“创建版本”界面，选择好组件版本，点击“新建打包”按钮生成打包版本的脚本，通过linux进行脚本打包，打包是单线程，整个系统仅能执行一个打包线程，在当前打包线程未结束时，若用户在其他环境发起打包请求，则创建打包任务并进入等待队列中，待当前打包线程结束后依序被执行；

所述的打包详情：在打包脚本过程中，会生成打包脚本日志、svn内容更新日志、maven编译日志和打包错误日志，用户通过打包脚本日志来进行历史版本的管理，根据svn内容更新日志来查看更新是否成功，根据maven编辑日志来查看打包失败的原因，根据打包错误日志来查看打包失败的组件子模块；

所述的下载详情：提供所有组件子模块打出来的包供用户下载；

所述的svn内容更新工具：打包脚本时，调用svn内容更新工具传入svn的服务器地址，以及当下需要更新的版本，该svn内容更新工具先判断组件子模块是否存在本地，如果不存在直接检出代码且返回继续执行脚本，如果组件子模块存在，则获取存在本地的组件子模块的svn服务器地址和版本，如果传入的svn服务器地址与存在本地的svn服务器地址不一致，则删除存在本地的组件子模块，然后再检出代码且返回继续执行脚本，如果传入的svn服务器版本比存在本地的svn服务器版本高，则svn更新代码，如果传入的svn服务器版本比存在的svn服务器版本小，则表示需要检出代码且返回继续执行脚本，在svn内容更新工具对比源代码版本号的时候，将存在检出、更新、删除的变更标志的组件子模块记录到日志里面，同时svn内容更新工具还记录svn的详细操作日志，包括进行了检出、更新、删除操作的组件子模块信息及时间信息；

所述的Maven项目管理工具：对maven打包进行封装，脚本调用Maven项目管理工具，传入环境配置文件、依赖库、设置路径、是否构建循环构建、打包方式，初始化环境，获取本地的依赖库，利用变更清零工具判断是否需要重新打包，同时对打包过程输出日志，该日志包括每个组件子模块打包成功日志、失败原因日志；

所述的变更清零工具：判断svn的源代码是否有变化，若有变化进行打包，同时清除之前打包的包。

本发明在确认版本的迭代内容以后，测试人员收集相关开发人员提交内容的svn版本，测试人员根据收集的svn版本，在打包的时候选中相应的版本号，对于其他的新增模块或者其他模块的更改或者本模块在确认版本后再提交的svn版本不予关注，系统只生成需要的脚本，精确地控制需要发布的内容，避免未测试的代码部署到正式环境；测试人员在执行打包动作时把收集的内容进行版本日志记录，打包发布以后，测试人员针对版本日志记录进行测试，生成对应版本测试报告，当测试人员想知道某个版本修改的内容，就可以查询版本日志记录以及对应版本测试报告，从而做到每个版本有源可循；版本控制人员可以根据版本日志记录和对应版本测试报告，拷贝测试通过的脚本，执行脚本对生成环境的打包，该生成环境的打包必须在测试环境通过的基础上方能进行。

本发明在执行打包脚本时，利用svn版本检测工具根据打包脚本的服务器源码地址，源码下载的地址，以及源码的版本号，与本地的存在的源码进行比对，当本地的源码与服务端的源码有改变的时候，更新本地的源码，标志为更新，让maven编译工具重新对改变的源码进行编译，对于源码没有更新的组件不进行重新编译，引用原来编译的结果，从而达到只编译改变的部分，缩短编译时间，达到增量编译。

本发明基于历史版本日志的版本回溯，每一次进行打包生成一个日志目录，将当前的打包脚本存在日志里面，当用户需要生成某次历史版本的时候，可以选中需要的历史版本的日志，从日志里面选出打包脚本，复制打包脚本到打包环境下面，执行脚本命令打出需要的包，这样用户就不需要每次打包的时候备份打出的包，而仅仅存储本次打包产生的包，从而降低存储的空间，从而达到以较低的硬盘空间实现历史版本的维护。

具体实施方式

本发明一种软件打包发布管理方法，包括一软件打包发布管理系统，该软件打包发布管理系统包括：组件、组件子模块、项目、环境、历史版本管理模块、组件版本选择模块、打包模块、打包详情、下载详情，以及预编写的插件，该插件包括svn内容更新工具、maven项目管理工具和变更清零工具；其中：

组件：用于对于组件子模块进行分类；

组件子模块：是软件持续集成的基础，是构成项目的必要条件，项目是由一个个组件子模块组成；每个组件子模块通过创建名称和源代码来区分，由path来存放通过svn下载的源代码，由url来指定组件子模块的下载地址，组件子模块的类型用来区分在生成脚本打包生产的是前端、后端、还是全部集合的包，组件子模块的版本号用来指定第一次创建模块的版本，组件子模块输出方式包括up和export，通过生成脚本的参数来告诉svn是下载整个目录或者单个文件，maven编译生成脚本的参数用于下达在当前项目模块执行命令时是否创建组件子模块的指令；在创建组件子模块的同时还会生成组件子模块与项目的关系；

项目：持续集成的目标；

项目环境：可用于区分正式环境和测试环境，只有在测试通过的版本下才能执行打包指令，可保证正式环境的准确性；

历史版本管理模块:用于查看历史版本日志，测试人员根据历史版本日志来了解之前的打包范围是否跟预期的一致，同时可对历史版本进行重新打包，以较少的硬盘空间实现历史版本的维护；

组件版本选择模块：通过svn的钩子把每次用户提交svn的组件子模块版本号、修改组件子模块的svn地址、以及把提交svn的更新内容提交到系统，根据现有的组件进行判断，如果修改组件子模块的svn地址与现存的一致，则更新该组件子模块与项目的关系，并标志为“更新”，用户根据是否标志为“更新”来选择是否发布版本，当然用户也可进入选择较早的版本；

打包模块：当用户进入“创建版本”界面，选择好组件版本，点击“新建打包”按钮的时候，会生成打包版本的脚本，通过linux进行脚本打包，打包是单线程，整个系统仅能执行一个打包线程，在当前打包线程未结束时，若用户在其他环境发起打包请求，则创建打包任务并进入等待队列中，待当前打包线程结束后依序被执行；

打包详情：在打包脚本过程中，会生成打包脚本日志、svn内容更新日志、maven编译日志和打包错误日志，用户通过打包脚本日志来进行历史版本的管理，根据svn内容更新日志来查看更新是否成功，根据maven编辑日志来查看打包失败的原因，根据打包错误日志来查看打包失败的组件子模块；

下载详情：提供所有组件子模块打出来的包供用户下载；

svn内容更新工具：打包脚本时，调用svn内容更新工具传入svn的服务器地址，以及当下需要更新的版本，该svn内容更新工具先判断组件子模块是否存在本地，如果不存在直接检出代码且返回继续执行脚本，如果组件子模块存在，则获取存在本地的组件子模块的svn服务器地址和版本，如果传入的svn服务器地址与存在本地的svn服务器地址不一致，则删除存在本地的组件子模块，然后再检出代码且返回继续执行脚本，如果传入的svn服务器版本比存在本地的svn服务器版本高，则svn更新代码，如果传入的svn服务器版本比存在的svn服务器版本小，则表示需要检出代码且返回继续执行脚本，在svn内容更新工具对比源代码版本号的时候，将存在检出、更新、删除的变更标志的组件子模块记录到日志里面，同时svn内容更新工具还记录svn的详细操作日志，包括进行了检出、更新、删除操作的组件子模块信息及时间信息；

Maven项目管理工具：对maven打包进行封装，脚本调用Maven项目管理工具，传入环境配置文件、依赖库、设置路径、是否构建循环构建、打包方式，初始化环境，获取本地的依赖库，利用变更清零工具判断是否需要重新打包，同时对打包过程输出日志，该日志包括每个组件子模块打包成功日志、失败原因日志；

变更清零工具：判断svn的源代码是否有变化，若有变化进行打包，同时清除之前打包的包，达到增量打包的效果；

所述软件打包发布管理方法，具体包括如下步骤：

步骤1、创建组件

对项目需要的组件进行分类创建组件子模块，便于通过组件管理和查找对应的组件子模块；

步骤2、创建组件子模块

设置是否需要构建当前组件的组件子模块，设置组件子模块的svn服务器地址和版本号，设置通过svn服务器地址下载的源代码存放在本地的目录，设置生成文件的类型，通过该生成文件的类型来区分生成打包脚本的是前端、后端、还是全部集合的包，设置是否可以引入外部链接，将上述的设置内容作为项目打包脚本生成的参数；

上述每一组件子模块是遵循maven的pom文件的结构来进行配置的；

上述svn服务器地址、版本号以及通过svn服务器地址下载的源代码存放在本地的目录为svn工具进行源代码管理的参数；

上述生成文件的类型，为了满足项目前后端分开部署，以项目打包脚本生成的参数形式来告诉maven编译成需要的文件类型；

svn工具根据是否可以引用外部链接的参数来执行导出单个文件或者整个文件夹；

步骤3、创建项目

设置打包管理的根目录，选择项目需要的组件子模块，形成打包该项目所需要的脚本的参数；

步骤4、创建环境

设置环境的目录，用来管理打包日志、文件下载、区分不同环境打包出来的文件，生成maven打包的时候不同环境的不同配置项参数和环境依赖的工具的地址；

每一个项目可以拥有多个环境，每个项目的其他环境都是依赖于测试环境来打包的，初始必须创建一个code为test的测试环境；

步骤5、执行脚本打包的预先编写插件

每个组件子模块都是一个小的项目，执行maven项目管理工具对组件子模块的管理的封装，对打包脚本里每个组件子模块进行依赖、清理、编译的项目管理工作；

执行变更清零工具来判断每个组件子模块的svn源代码是否有变化，若有变化则判断是否需要重新打包，若需要重新打包，进行打包的同时清除之前打包的包，达到增量打包的效果，同时对打包过程输出日志，该日志包括每个组件子模块打包成功日志、失败原因日志；

执行svn内容更新工具传入svn的服务器地址，以及当前需要更新内容的版本号，该svn内容更新工具先判断组件子模块是否存在本地，如果不存在本地，则直接检出代码且返回继续执行脚本，若存在本地，则获取存在本地的组件子模块的svn服务器地址和版本号，如果传入svn的服务器地址与存在本地的svn服务器地址不一致，则删除本地文件，然后再检出代码且返回继续执行脚本，如果传入svn的源代码版本号比存在本地的版本号大，则svn更新代码，如果传入svn的源代码版本号比存在本地的版本小，则表示需要检出代码且返回继续执行脚本，在svn内容更新工具对比源代码版本号的时候，对存在检出、更新、删除的变更标志的组件子模块记录到日志里面，同时svn内容更新工具还会记录svn的详细操作日志，包括进行了检出、更新、删除操作的组件子模块信息及时间信息；

上述步骤1至5构成了打包一个系统的基本要素，是可以执行打包的基础，增加模块、创建模块，关联模块与项目环境的关系，为执行步骤6的必要前提；

步骤6、选择各个组件子模块的打包版本

用户选择项目，进入环境列表，选择环境，如果用户选择测试环境会出现“新建打包”按钮和历史版本日志列表，其他的环境只出现历史版本日志列表；

历史版本日志列表，映射maven项目管理工具在执行打包脚本的历史版本日志(参见步骤7)目录集合；选择环境列表除测试环境的任一环境进入历史版本日志列表，用户选择需要历史版本下的“打包”按钮转而执行步骤7.1。

用户选择进入测试环境，显示测试环境的历史版本列表，选择需要的历史版本，进入环境列表（这个界面会显示该项目所有的环境），当用户选择测试环境下的“打包”按钮的时候是对测试环境的历史版本重新打包转执行步骤7.1；当用户选择其他（例如正式）环境的“打包”按钮的时候，会把测试环境当前历史版本目录下的打包脚本拷贝到所选择的（例如正式）环境下转而执行步骤7.1，其他的环境是没有“新建打包”的按钮，而是基于测试环境测试过的历史版本的打包脚本来打包，这样控制可以做到正式环境永远不会发布未测试通过的代码；

用户进入新建环境，点击“新建打包”，会进入展现出打包该项目的所有组件子模块，用户根据从开发人员收集到的svn更新内容，过滤选择需要升级版本的组件子模块、需要降级版本的组件子模块、或者需要禁用的组件子模块，转而执行步骤7.2；

确认发布/测试版本的各个组件子模块的内容以后，测试人员收集相关开发人员提交内容的svn版本，测试人员根据收集的svn版本，在打包的时候选中相应的版本号，对于其他的新增模块或者其他模块的更改或者本模块在确认版本后再提交的svn版本不予关注，系统只会生成需要的脚本，精确地控制需要发布的内容，避免未测试通过的代码部署到正式环境；测试人员在执行打包动作时把收集的内容进行版本日志记录，打包发布以后，测试人员针对版本日志记录进行测试，生成对应版本的测试报告，当测试人员想知道某个版本修改的内容，就可以查询版本日志记录以及对应版本的测试报告，从而做到每个版本有源可循；版本控制人员根据版本日志记录和对应版本测试报告，拷贝测试通过的脚本，执行脚本对生成环境的打包，该生成环境的打包必须在测试环境通过的基础上方能进行；

当开发人员将源代码通过svn提交到svn服务器的时候，svn服务器利用svn的钩子命令，把当前提交的源代码中包含的svn信息通过本系统的接口提交到“软件打包发布管理系统”，同时该接口通过匹配模块，把提交的svn信息跟组件子模块匹配起来，形成组件子模块的svn内容更新列表，供用户使用，上述svn信息包括版本号、svn日志和修改文件的url地址；

步骤7、生成打包脚本并执行

在生成脚本的时候根据制定好的打包规则会额外在脚本里面生成清除上次生成的包的命令和生成日志的命令。

每次执行打包脚本的时候先清除之前打包的包，达到节省空间的目的；接着根据当前时间和随机数生成一个历史版本目录，将当前的打包脚本拷贝进入历史版本目录，同时下面步骤8产生的日志和最终打出的包也放在这个历史版本目录，形成历史版本日志；

步骤7.1、根据步骤6选择的历史版本点击“打包”按钮，根据历史版本号将历史版本文件夹的打包脚本拷贝当前linux执行环境，并执行打包脚本；

步骤7.2、新建打包，根据当前的组件子模块的配置，该配置包括用户选择的打包版本、如果未选择以上次的版本为标准目录的内容，生成一条条数据，然后根据打包脚本生成规则在linux环境生成打包脚本，并在linux环境下执行该打包脚本；

步骤8、调用svn内容更新工具对现有的源代码进行管理

打包脚本执行的时候，自动调用svn内容更新工具对现有的源代码进行管理，利用svn内容更新工具根据打包脚本的服务器源代码地址、源代码下载的地址、以及源代码的版本号，与本地存在的源代码进行比对，当本地的源代码与服务端的源代码有改变的时候，更新本地的源代码，标志为更新，利用maven编译工具重新对改变的源代码进行编译，对于源代码没有更新的组件不进行重新编译，引用原来编译的结果，从而达到只编译改变的部分，缩短编译时间，达到增量编译；打包脚本由一个个组件子模块组成的命令，执行打包脚本的每个组件子模块命令重复步骤7-8，直到所有脚本命令执行完成，产生包文件。

以上所述，仅是本发明较佳实施例而已，并非对本发明的技术范围作任何限制，故凡是依据本发明的技术实质对以上实施例所作的任何细微修改、等同变化与修饰，均仍属于本发明技术方案的范围内。