一种自动化分布式多任务打包方法及系统与流程

本发明涉及一种自动化分布式多任务打包方法及系统。

背景技术：

近年来，随着智能手机、平板电脑等智能终端在人群中普遍应用，各类应用程序应运而生，应用程序一般先通过软件公司开发，再由开发好的应用程序以安装包的形式供用户下载安装使用。现有的应用app打包过程较为繁琐，特别在需要进行大批量、快速、一次性打出应用app安装包的情况下，若单纯依靠人力一个一个实现整个过程，就会耗费大量的人工及生产环境的资源，成本高，效率低。

技术实现要素：

本发明要解决的技术问题之一，在于提供一种自动化分布式多任务打包方法，可实现自动化打包，提高打包效率的同时节约了人工和生产环境资源，以实现释放劳动力，成本最小化，达到最高效的产出。

本发明要解决的技术问题之一是这样实现的：一种自动化分布式多任务打包方法，需提供下单服务器以及复数个接单服务器，复数个所述接单服务器分别与下单服务器通过网络连接，所述方法包括如下步骤：

步骤1、预先在下单服务器创建配置中心，所述配置中心包括定义不同的渠道、不同的功能分支，以及不同接单服务器的设备基本信息和设备接单策略，其中，所述功能分支包括功能插件，所述渠道用于包括与市场相关的插件及相关配置信息；

步骤2、通过所述下单服务器从产品后台自动获取待打包的产品信息，根据产品需求进行勾选打包配置，包括配置待打包产品的基础信息、终端的操作系统平台、渠道、需要的插件和打包分支信息，生成待处理的打包任务信息json文件；

步骤3、通过每一所述接单服务器每间隔一定时间从下单服务器请求打包任务，所述下单服务器获取所述接单服务器的配置文件与配置中心的对应配置信息进行比对，判断所述接单服务器是否符合打包要求，若是，则下发对应的打包任务给所述接单服务器进行打包，否则，拒绝所述接单服务器的当前任务请求；

步骤4、接单服务器在任务执行过程中和执行完毕时均返回执行日志给下单服务器，由所述下单设备将结果信息存储到数据库，并将结果在页面上进行展示。

进一步的，所述配置中心还提供给高级管理员相应的配置权限，所述配置权限包括配置用户的增删改执行权限、配置预约打包时间、配置接单服务器策略以及配置期望接单服务器，通过配置预约打包时间中的任务下发时间控制打包任务的执行时间，通过所述接单策略分配对应的打包任务，通过配置期望的接单服务器实现对接单服务器的指定。

进一步的，所述接单服务器的设备基本信息包括设备名称、设备标识、主机地址、端口号、登录账号和密码；

所述接单策略包括设备运行策略、打包黑白名单策略、缓存释放策略、任务量控制以及设备启用控制；

所述设备运行策略包括打包策略、设备类型以及对应的开放对象，所述打包策略包括“仅打ios包”、“仅打android包”、“先打ios包，空闲时再打android包”、“先打android包，空闲时再打ios包”和“不区分系统平台，按时间先后顺序打包”，所述设备类型包括2d设备或3d设备，所述2d设备仅用于打包2d产品，所述3d设备仅用于3d产品，所述开放对象为对所述接单服务器有使用权限的用户组；其中，2d产品和3d产品的区别包括插件、打包方式、引擎以及证书不同；

所述打包黑白名单策略中包括打包白名单或打包黑名单，所述打包白名单中记录了对应接单服务器允许打包的产品，所述打包黑名单中记录了对应接单服务器不允许打包的产品；

所述缓存释放策略通过设置定时清除一定天数的缓存实现对磁盘空间的释放；

所述任务量控制包括预先指定每一接单服务器的同时打包进程数，决定当前接单服务器能够同时执行打包任务的数量，使得超出的数量进入等待队列；

所述设备启用控制包括设置接单服务器的打包功能开启或关闭。

进一步的，所述步骤3中的“判断所述接单服务器是否符合打包要求”具体为：

依次判断当前接单服务器的打包功能是否开启、其配置文件与配置中心的配置信息是否匹配、当前用户是否具备对应的打包权限、当前接单服务器是否开启、当前接单服务器的打包进程是否未被占满、当前接单服务器的类型是否与产品的类型匹配、是否符合对应的打包系统类型、是否满足打包黑白名单策略、是否需要立即打包，只有上述所有判断条件均为是时，才能获取对应的打包任务进行打包，否则只要存在一个判断条件为否，则结束当前设备的打包流程。

进一步的，所述接单服务器执行打包任务时，根据产品的类型为2d或3d去执行对应的打包方式，其中，2d产品的打包方式是通过更新预先提供的android/ios模板、lua游戏框架以及游戏脚本，再执行预先设定的打包处理流程来完成打包任务的。

本发明要解决的技术问题之二，在于提供一种自动化分布式多任务打包系统，可实现自动化打包，提高打包效率的同时节约了人工和生产环境资源，以实现释放劳动力，成本最小化，达到最高效的产出。

本发明要解决的技术问题之二是这样实现的：一种自动化分布式多任务打包系统，需提供下单服务器以及复数个接单服务器，复数个所述接单服务器分别与下单服务器通过网络连接，所述系统包括：

配置中心模块，用于预先在下单服务器创建配置中心，所述配置中心包括定义不同的渠道、不同的功能分支，以及不同接单服务器的设备基本信息和设备接单策略，其中，所述功能分支包括功能插件，所述渠道用于包括与市场相关的插件及相关配置信息；

打包任务生成模块，用于通过所述下单服务器从产品后台自动获取待打包的产品信息，根据产品需求进行勾选打包配置，包括配置待打包产品的基础信息、终端的操作系统平台、渠道、需要的插件和打包分支信息，生成待处理的打包任务信息json文件；

打包模块，用于通过每一所述接单服务器每间隔一定时间从下单服务器请求打包任务，所述下单服务器获取所述接单服务器的配置文件与配置中心的对应配置信息进行比对，判断所述接单服务器是否符合打包要求，若是，则下发对应的打包任务给所述接单服务器进行打包，否则，拒绝所述接单服务器的当前任务请求；以及

反馈模块，用于接单服务器在任务执行过程中和执行完毕时均返回执行日志给下单服务器，由所述下单设备将结果信息存储到数据库，并将结果在页面上进行展示。

进一步的，所述配置中心还提供给高级管理员相应的配置权限，所述配置权限包括配置用户的增删改执行权限、配置预约打包时间、配置接单服务器策略以及配置期望接单服务器，通过配置预约打包时间中的任务下发时间控制打包任务的执行时间，通过所述接单策略分配对应的打包任务，通过配置期望的接单服务器实现对接单服务器的指定。

进一步的，所述接单服务器的设备基本信息包括设备名称、设备标识、主机地址、端口号、登录账号和密码；

所述接单策略包括设备运行策略、打包黑白名单策略、缓存释放策略、任务量控制以及设备启用控制；

所述设备运行策略包括打包策略、设备类型以及对应的开放对象，所述打包策略包括“仅打ios包”、“仅打android包”、“先打ios包，空闲时再打android包”、“先打android包，空闲时再打ios包”和“不区分系统平台，按时间先后顺序打包”，所述设备类型包括2d设备或3d设备，所述2d设备仅用于打包2d产品，所述3d设备仅用于3d产品，所述开放对象为对所述接单服务器有使用权限的用户组；其中，2d产品和3d产品的区别包括插件、打包方式、引擎以及证书不同；

所述打包黑白名单策略中包括打包白名单或打包黑名单，所述打包白名单中记录了对应接单服务器允许打包的产品，所述打包黑名单中记录了对应接单服务器不允许打包的产品；

所述缓存释放策略通过设置定时清除一定天数的缓存实现对磁盘空间的释放；

所述任务量控制包括预先指定每一接单服务器的同时打包进程数，决定当前接单服务器能够同时执行打包任务的数量，使得超出的数量进入等待队列；

所述设备启用控制包括设置接单服务器的打包功能开启或关闭。

进一步的，所述打包模块中的“判断所述接单服务器是否符合打包要求”具体为：

依次判断当前接单服务器的打包功能是否开启、其配置文件与配置中心的配置信息是否匹配、当前用户是否具备对应的打包权限、当前接单服务器是否开启、当前接单服务器的打包进程是否未被占满、当前接单服务器的类型是否与产品的类型匹配、是否符合对应的打包系统类型、是否满足打包黑白名单策略、是否需要立即打包，只有上述所有判断条件均为是时，才能获取对应的打包任务进行打包，否则只要存在一个判断条件为否，则结束当前设备的打包流程。

进一步的，所述接单服务器执行打包任务时，根据产品的类型为2d或3d去执行对应的打包方式，其中，2d产品的打包方式是通过更新预先提供的android/ios模板、lua游戏框架以及游戏脚本，再执行预先设定的打包处理流程来完成打包任务的。

本发明具有如下优点：通过设置接单策略统一管理各个接单服务器，分布式打包合理分配到各个设备资源，且可实现批量出包，大幅提升了打包效率；以及通过预先设置配置中心，将需要打包的部分功能以插件配置方式添加到产品中，无需人为增加代码等操作，减少开发负担，缩短整个产品生产周期。

附图说明

下面参照附图结合实施例对本发明作进一步的说明。

图1为本发明方法执行流程图。

图2为本发明系统框图。

图3为本发明一实施例中配置中心的接单服务器配置管理界面示意图。

图4为本发明一实施例中下单服务器生成打包任务界面示意图。

具体实施方式

如图1、图3和图4所示，本发明的一种自动化分布式多任务打包方法，需提供下单服务器以及复数个接单服务器，复数个所述接单服务器分别与下单服务器通过网络连接，所述方法包括如下步骤：

步骤1、预先在下单服务器创建配置中心，所述配置中心包括定义不同的渠道、不同的功能分支，以及不同接单服务器的设备基本信息和设备接单策略，其中，所述功能分支包括功能插件和其他相关配置，所述渠道用于包括与市场相关的插件(比如百度渠道，则其对应的插件包括百度logo以及相关信息等)及相关配置信息(包括名称、标识号、语言等)；

步骤2、通过所述下单服务器从产品后台自动获取待打包的产品信息，根据产品需求进行勾选打包配置，包括配置待打包产品的基础信息、终端的操作系统平台(比如安卓平台和苹果平台)、渠道(比如国外和国内商家)、需要的插件和打包分支信息(包括2d产品的功能分支信息，以及3d产品的功能分支信息和unity分支信息)，生成待处理的打包任务信息json文件；通过勾选预先定义好的渠道和打包分支等，直接将渠道和打包分支中的功能分支对应的插件添加进行打包，由于渠道和功能分支都可以由插件组成，因此在渠道有差异时，可直接对原有相似渠道中的插件进行添加或删除部分插件即可得到新的配置内容，无需重复去开发不同的渠道配置代码，只需要简单的勾选操作即可，减少人工开发成本，可实现快速打包。

步骤3、通过每一所述接单服务器每间隔一定时间从下单服务器请求打包任务，所述下单服务器获取所述接单服务器的配置文件与配置中心的对应配置信息进行比对，判断所述接单服务器是否符合打包要求，若是，则下发对应的打包任务给所述接单服务器进行打包(所述接单服务器通过获取对应的json文件进行打包)，否则，拒绝所述接单服务器的当前任务请求；其中，所述接单服务器的配置文件通过网页进行设置并存入数据库中，供接单服务器和接单服务器下载，无需登录各个接单服务器去逐一设置。

步骤4、接单服务器在任务执行过程中和执行完毕时均返回执行日志给下单服务器，由所述下单设备将结果信息存储到数据库，并将结果在页面上进行展示。

其中，所述配置中心还提供给高级管理员相应的配置权限，所述配置权限包括配置用户的增删改执行权限、配置预约打包时间、配置接单服务器策略以及配置期望接单服务器，通过配置预约打包时间中的任务下发时间控制打包任务的执行时间，通过所述接单策略分配对应的打包任务，通过配置期望的接单服务器实现对接单服务器的指定，高级管理员可进行预约定时打包，可对打包任务指定期望的接单服务器进行优先打包的权限等，高级管理员可对每个用户的增删改查和执行的权限进行指定。

在一较佳实施例中，所述接单服务器的设备基本信息包括设备名称、设备标识、主机地址、端口号、登录账号和密码；

所述接单策略包括设备运行策略、打包黑白名单策略、缓存释放策略、任务量控制以及设备启用控制；

所述设备运行策略包括打包策略、设备类型以及对应的开放对象，所述打包策略包括“仅打ios包”、“仅打android包”、“先打ios包，空闲时再打android包”、“先打android包，空闲时再打ios包”和“不区分系统平台，按时间先后顺序打包”，所述设备类型包括2d设备或3d设备，所述2d设备仅用于打包2d产品，所述3d设备仅用于3d产品，所述开放对象为对所述接单服务器有使用权限的用户组；其中，2d产品和3d产品的区别包括插件、打包方式、引擎以及证书不同；

所述打包黑白名单策略中包括打包白名单或打包黑名单，所述打包白名单中记录了对应接单服务器允许打包的产品，所述打包黑名单中记录了对应接单服务器不允许打包的产品，其中打包白名单或打包黑名单可择一选择一种进行配置，也可以不进行设置，打包黑白名单策略对高级管理员手动指定接单服务器时没有限制作用；

所述缓存释放策略通过设置定时清除一定天数的缓存实现对磁盘空间的释放；

所述任务量控制包括预先指定每一接单服务器的同时打包进程数，决定当前接单服务器能够同时执行打包任务的数量，使得超出的数量进入等待队列；

所述设备启用控制包括设置接单服务器的打包功能开启或关闭。

在一较佳实施例中，所述步骤3中的“判断所述接单服务器是否符合打包要求”具体为：

依次判断当前接单服务器的打包功能是否开启、其配置文件与配置中心的配置信息是否匹配、当前用户是否具备对应的打包权限、当前接单服务器是否开启、当前接单服务器的打包进程是否未被占满、当前接单服务器的类型是否与产品的类型匹配、是否符合对应的打包系统类型、是否满足打包黑白名单策略、是否需要立即打包，只有上述所有判断条件均为是时，才能获取对应的打包任务进行打包，否则只要存在一个判断条件为否，则结束当前设备的打包流程(即当前任务下，当前接单服务器的打包流程结束，不影响其他接单服务器继续请求此任务)。其中，若当前用户预先配置期望的接单服务器，则上述判断条件中还需要判断当前接单服务器是否为期望的接单服务器；

在一较佳实施例中，所述接单服务器执行打包任务时，根据产品的类型为2d或3d去执行对应的打包方式，其中，2d产品的打包方式是通过更新预先提供的android/ios模板、lua游戏框架以及游戏脚本，再执行预先设定的打包处理流程(包括后续的根据获取到的信息来修改模板、拷贝资源等等操作)来完成打包任务的。

如图2、图3和图4所示，本发明的一种自动化分布式多任务打包系统，需提供下单服务器以及复数个接单服务器，复数个所述接单服务器分别与下单服务器通过网络连接，所述系统包括：

配置中心模块，用于预先在下单服务器创建配置中心，所述配置中心包括定义不同的渠道、不同的功能分支，以及不同接单服务器的设备基本信息和设备接单策略，其中，所述功能分支包括功能插件和其他相关配置，所述渠道用于包括与市场相关的插件(比如百度渠道，则其对应的插件包括百度logo以及相关信息等)及相关配置信息(包括名称、标识号、语言等)；

打包任务生成模块，用于通过所述下单服务器从产品后台自动获取待打包的产品信息，根据产品需求进行勾选打包配置，包括配置待打包产品的基础信息、终端的操作系统平台(比如安卓平台和苹果平台)、渠道(比如国外和国内商家，如百度、小米等)、需要的插件和打包分支信息(包括2d产品的功能分支信息，以及3d产品的功能分支信息和unity分支信息)，生成待处理的打包任务信息json文件；通过勾选预先定义好的渠道和打包分支等，直接将渠道和打包分支中的功能分支对应的插件添加进行打包，由于渠道和功能分支都可以由插件组成，因此在渠道有差异时，可直接对原有相似渠道中的插件进行添加或删除部分插件即可得到新的配置内容，无需重复去开发不同的渠道配置代码，只需要简单的勾选操作即可，减少人工开发成本，可实现快速打包；

打包模块，用于通过每一所述接单服务器每间隔一定时间从下单服务器请求打包任务，所述下单服务器获取所述接单服务器的配置文件与配置中心的对应配置信息进行比对，判断所述接单服务器是否符合打包要求，若是，则下发对应的打包任务给所述接单服务器进行打包(所述接单服务器通过获取对应的json文件进行打包)，否则，拒绝所述接单服务器的当前任务请求；其中，所述接单服务器的配置文件通过网页进行设置并存入数据库中，供接单服务器和接单服务器下载，无需登录各个接单服务器去逐一设置；以及

反馈模块，用于接单服务器在任务执行过程中和执行完毕时均返回执行日志给下单服务器，由所述下单设备将结果信息存储到数据库，并将结果在页面上进行展示。

其中，所述配置中心还提供给高级管理员相应的配置权限，所述配置权限包括配置用户的增删改执行权限、配置预约打包时间、配置接单服务器策略以及配置期望接单服务器，通过配置预约打包时间中的任务下发时间控制打包任务的执行时间，通过所述接单策略分配对应的打包任务，通过配置期望的接单服务器实现对接单服务器的指定，高级管理员可进行预约定时打包，可对打包任务指定期望的接单服务器进行优先打包的权限等，高级管理员可对每个用户的增删改查和执行的权限进行指定。

在一较佳实施例中，所述接单服务器的设备基本信息包括设备名称、设备标识、主机地址、端口号、登录账号和密码；

所述接单策略包括设备运行策略、打包黑白名单策略、缓存释放策略、任务量控制以及设备启用控制；

所述设备运行策略包括打包策略、设备类型以及对应的开放对象，所述打包策略包括“仅打ios包”、“仅打android包”、“先打ios包，空闲时再打android包”、“先打android包，空闲时再打ios包”和“不区分系统平台，按时间先后顺序打包”，所述设备类型包括2d设备或3d设备，所述2d设备仅用于打包2d产品，所述3d设备仅用于3d产品，所述开放对象为对所述接单服务器有使用权限的用户组；其中，2d产品和3d产品的区别包括插件、打包方式、引擎以及证书不同；

所述打包黑白名单策略中包括打包白名单或打包黑名单，所述打包白名单中记录了对应接单服务器允许打包的产品，所述打包黑名单中记录了对应接单服务器不允许打包的产品，其中打包白名单或打包黑名单可择一选择一种进行配置，也可以不进行设置，打包黑白名单策略对高级管理员手动指定接单服务器时没有限制作用；

所述缓存释放策略通过设置定时清除一定天数的缓存实现对磁盘空间的释放；

所述任务量控制包括预先指定每一接单服务器的同时打包进程数，决定当前接单服务器能够同时执行打包任务的数量，使得超出的数量进入等待队列；

所述设备启用控制包括设置接单服务器的打包功能开启或关闭。

在一较佳实施例中，所述打包模块中的“判断所述接单服务器是否符合打包要求”具体为：

依次判断当前接单服务器的打包功能是否开启、其(即当前接单服务器)配置文件与配置中心的配置信息是否匹配、当前用户是否具备对应的打包权限、当前接单服务器是否开启、当前接单服务器的打包进程是否未被占满(比如android打包任务是否未达到上限、ios打包任务是否未达到上限)、当前接单服务器的类型是否与产品的类型匹配(比如2d设备是否匹配的是2d产品，3d设备是否匹配的是3d产品)、是否符合对应的打包系统类型(比如是否为对应的android系统或ios系统)、是否满足打包黑白名单策略(若设置了打包白名单，则判断产品是否在打包白名单内，若设置了打包黑名单，则判断产品是否不再打包黑名单内)、是否需要立即打包(比如设置了预约定时打包的，是否到时间可以立即执行打包)，只有上述所有判断条件均为是时，才能获取对应的打包任务进行打包，否则只要存在一个判断条件为否，则代表当前接单服务器获取该打包任务失败，结束当前设备的打包流程(即当前任务下，当前接单服务器的打包流程结束，不影响其他接单服务器继续请求此任务)。其中，若当前用户预先配置期望的接单服务器，则上述判断条件中还需要增加判断当前接单服务器是否为期望的接单服务器这一条件。

在一较佳实施例中，所述接单服务器执行打包任务时，根据产品的类型为2d或3d去执行对应的打包方式，其中，2d产品的打包方式是通过更新预先提供的android/ios模板、lua游戏框架以及游戏脚本，再执行预先设定的打包处理流程(包括后续的根据获取到的信息来修改模板、拷贝资源等等操作)来完成打包任务的。

本发明通过提供一套自动化打包流程和系统，可实现大批量、快速、一次性打出多种应用app安装包，节约人工和生产环境资源，释放劳动力、成本最小化及最高效的产出。本发明通过设置接单策略统一管理各个接单服务器，实现分布式打包合理分配到各个设备资源，无需人为去判断合适的设备，提高了打包效率。且通过预先设置配置中心，将需要打包的部分功能以插件配置方式自动配置添加到产品中，无需人为去重复代码等操作，减少开发负担，缩短整个产品生产周期，通过配置方式进行打包也可以实现批量出包，大幅提升了打包效率；本发明可采用b/s结构，配置中心为browser，作为用户使用的系统界面，也就是b，服务器是server，就是s，具体执行打包操作是放到服务器上，就是用户无需配置电脑环境即可实现控制任务运行的目的，用户操作简便。

虽然以上描述了本发明的具体实施方式，但是熟悉本技术领域的技术人员应当理解，我们所描述的具体的实施例只是说明性的，而不是用于对本发明的范围的限定，熟悉本领域的技术人员在依照本发明的精神所作的等效的修饰以及变化，都应当涵盖在本发明的权利要求所保护的范围内。