本发明实施例涉及多渠道包生成技术领域，尤其涉及一种安装包多渠道打包方法、装置、计算机设备及存储介质。
背景技术：
安卓安装包(androidpackage，apk)是一种安卓操作系统的应用程序安装文件，android项目开发完成后需要打包成apk，并下载到终端设备运行。在开发android项目时，由于android市场的开放性，android市场的发布平台较多，各个发布平台均发布有相应的apk，即在各个渠道均有相同的apk。当软件开发商需要统计各个渠道中运行应用的用户量等数据时，可以对apk进行多渠道打包，使各个apk携带渠道信息，然后当apk安装运行时将渠道信息和采集的用户量等数据发送给软件开发商。
现有技术中，常用的apk进行渠道打包方式是将apk人工放在指定目录下，然后将渠道值写在apk的注释区，通过相关的命令一键生成相应的渠道包。但是，由于在进行apk打包时需要采用人工方式将apk放入打包工具的相应位置后再通过命令行控制进行apk打包，无法保证生成的渠道包与apk之间对应关系的唯一性，即无法保证渠道包打包之前的apk与生成的渠道包中的各个apk之间是否是同一个apk，造成生成的多个渠道包中的各个apk并不是同一个apk。
技术实现要素：
本发明实施例提供一种安装包多渠道打包方法、装置、计算机设备及存储介质，以实现安装包与生成的多渠道包中的各个安装包之间的唯一性。
第一方面，本发明实施例提供了一种安装包多渠道打包方法，该方法包括：
通过持续集成工具jenkins从版本控制系统中获取目标安装包；其中，所述目标安装包为所述版本控制系统中需要多渠道打包的初始安装包；
通过jenkins建立所述目标安装包的多渠道打包任务，并根据所述多渠道打包任务生成所述目标安装包对应的多渠道包。
第二方面，本发明实施例还提供了一种安装包多渠道打包装置，该装置包括：
安装包获取模块，用于通过持续集成工具jenkins从版本控制系统中获取目标安装包；其中，所述目标安装包为所述版本控制系统中需要多渠道打包的初始安装包；
多渠道打包模块，用于通过jenkins建立所述目标安装包的多渠道打包任务，并根据所述多渠道打包任务生成所述目标安装包对应的多渠道包。
第三方面，本发明实施例还提供了一种计算机设备，该计算机设备包括：
一个或多个处理器；
存储装置，用于存储一个或多个程序，
当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如上所述的安装包多渠道打包方法。
第四方面，本发明实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上所述的安装包多渠道打包方法。
本发明实施例提供了一种安装包多渠道打包方法、装置、计算机设备及存储介质，通过持续集成工具jenkins从版本控制系统中获取目标安装包；其中，目标安装包为版本控制系统中需要多渠道打包的初始安装包；通过jenkins建立目标安装包的多渠道打包任务，并根据多渠道打包任务生成目标安装包对应的多渠道包。本发明实施例解决了在安装包多渠道打包过程中无法保证生成的渠道包与安装包之间对应关系的唯一性，造成生成的多渠道包并不是对同一个安装包进行渠道打包生成的问题，实现了安装包与多渠道包中的各个安装包之间的唯一性。
附图说明
图1是本发明实施例一中的安装包多渠道打包方法的流程示意图；
图2是本发明实施例二中的安装包多渠道打包方法的流程示意图；
图3a是本发明实施例二中的持续集成工具jenkins界面示意图；
图3b是本发明实施例二中的持续集成工具jenkins另一个界面示意图；
图4是本发明实施例三中的安装包多渠道打包方法的流程示意图；
图5是本发明实施例四中的安装包多渠道打包装置的结构示意图；
图6是本发明实施例五中的一种计算机设备的结构示意图。
具体实施方式
下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部结构。
实施例一
图1是本发明实施例一中的安装包多渠道打包方法的流程示意图，本实施例的安装包多渠道打包方法可适用于用户在对应用安装包进行多渠道打包的情况。本实施例的安装包多渠道打包方法具体由安装包多渠道打包装置来执行，该装置可以采用软件和/或硬件的方式来实现。如图1所示，该安装包多渠道打包方法可以包括：
步骤101、通过持续集成工具jenkins从版本控制系统中获取目标安装包；其中，目标安装包为版本控制系统中需要多渠道打包的初始安装包。
在本实施例中，jenkins是一个开源软件项目，可以提供一个开放易用的软件平台，使软件做到可以持续集成，可以用于监控持续重复的工作。版本控制系统是一种记录一个或多个文件内容变化，以便将来查阅某一文件版本修订情况的系统。版本控制系统不仅可以应用于软件源代码的文本文件，而且可以对任何类型的文件进行版本控制。版本控制系统的类型可以分为本地版本控制系统、集中化版本控制系统和分布式版本控制系统。其中，集中化版本控制系统简称为cvcs，这类版本控制系统包括诸如cvs、subversion以及perforce等；分布式版本控制系统简称dvcs，这类版本控制系统包括诸如像git、mercurial、bazaar以及darcs等。为了方便对目标安装包进行控制管理，在本实施例中版本控制系统可以采用分布式版本控制系统。例如，可以采用git分布式版本控制系统对目标安装包进行统一管理。
在本实施例中，各种类型的初始安装包可以上传到版本控制系统中，并通过版本控制系统特有的管理功能对各类型的初始安装包进行统一管理。版本控制系统可以对版本控制系统中各类型的初始安装包以及各类型初始安装包的修改版本进行存储，以便用户可以通过版本控制系统获取各类型初始安装包的最新版本。版本控制系统特有的管理功能可以体现在对初始安装包在版本控制系统中的进行保存时的目录信息、历史记录和修改详情的管理。其中，初始安装包可以是被开发人员开发出来的源安装包，该初始安装包不包含任何渠道信息。初始安装包可以分为多种类型，如开发人员开发的系统软件安装包、影音软件安装包和游戏软件安装包等软件安装包。初始安装包可以为android系统适用的apk形式的软件安装包，或者其他形式的软件安装包，本实施例对此不做限定。
在本实施例中，版本控制系统可以对系统中保存的各种初始安装包进行统一管理，当需要对版本控制系统中的某一个初始安装进行多渠道打包时，此时该需要多渠道打包的初始安装包就可以作为本实施例的目标安装包。
在上述实施例的基础上，可选的，在通过持续集成工具jenkins从版本控制系统中获取目标安装包之前，该安装包多渠道打包方法可以包括：
将开发人员生成的初始安装包按照预先设置的规则提交至版本控制系统中；通过版本控制系统对初始安装包和初始安装包的属性信息进行统一管理，属性信息包括初始安装包在版本控制系统的目录信息、历史记录和修改详情。
一般的，开发人员在开发一个项目时，通常是分配给多个开发人员不同的任务，让多个开发人员共同完成项目的开发，此时不同开发人员完成各自分配的功能模块，最后再将各个开发人员完成的功能模块集合在一起生成初始的安装包作为开发人员共同完成的初始安装包。
具体地，开发人员开发完成初始安装包之后，可以按照预先设置的规则将初始安装包提交上传至版本控制系统，通过版本控制系统对上传至版本控制系统的各个初始安装包进行统一管理。预先设置的规则可以是用户在使用版本控制系统时，在版本控制系统的指定目录下创建的备份初始安装包的文件夹的备份路径。该文件夹用于将初始安装包在版本控制系统的指定目录下进行备份存储。示例性的，版本控制系统指定目录下创建的备份文件夹的备份路径具体可以为：..\back\{app_version_code}\{version_sequence}\base.apk；其中，app_version_code表示当前备份文件夹下初始安装包的版本号，比如版本号可以为“4.5.0”；version_sequence表示当前备份文件夹下该初始安装包在当前版本号下的版本次序，比如第一版可以“01”，第二版可以为“02”；base.apk表示当前备份文件夹下的初始安装包。
具体地，初始安装包的属性信息可以包括初始安装包在版本控制系统中进行保存的目录信息、每一个初始安装包的历史记录和每一处历史记录的修改详情等。其中，初始安装包的目录信息与初始安装包在版本控制系统的指定目录下创建的备份初始安装包的文件夹的备份路径是一致的。即初始安装包在版本控制系统的指定目录下创建的备份初始安装包的文件夹的备份路径可以与初始安装包在版本控制系统中进行保存时的目录信息保持一致。初始安装包的历史记录可以是开发人员或者技术人员对版本控制系统中初始安装包的进行更改、替换、渠道打包以及进行其他操作的历史记录信息。例如，a技术人员在xxx年xxx月xxx日对xxx初始安装包进行更改的历史记录信息。初始安装包的修改详情可以是开发人员或者技术人员对初始安装包的历史记录中某一个历史记录的修改详情。例如，当a技术人员在xxx年xxx月xxx日对xxx初始安装包的进行更改时，可以对修改的历史记录中的进行修改的详细内容进行显示，比如是对该初始安装包的内容进行了哪些修改。
步骤102、通过jenkins建立目标安装包的多渠道打包任务，并根据多渠道打包任务生成目标安装包对应的多渠道包。
一般情况下，渠道包是指在各大应用市场发布的安装包的清单文件中某个meta-data标签下，配置一个渠道值形成的打包文件。由于这类标签的作用就是用来区分安装包是从哪个应用市场下载的。例如，当需要将某一个安装包发布到360应用市场时，这个渠道值就可以配置成360，在其他应用市场发布，渠道值就配置相应用市场的渠道信息。多渠道打包是指将某一个安装包生成多个渠道的安装包文件的工程，这样的话当安装包在各个应用市场发布时，可以方便对安装包进行统计分析。
在本实施例中，在通过jenkins从版本控制系统中获取目标安装包之后，可以通过集成工具jenkins针对该从版本控制系统中获取的目标安装包构建多渠道打包任务。然后根据建立的目标安装包的多渠道打包任务通过渠道包打包工具生成目标安装包的多渠道包。其中，渠道包打包工具可以采用美团打包工具，根据多渠道打包任务通过美团工具将渠道值写入目标安装包的注释区，经过多次对目标安装包写入渠道值可以生成目标安装包的多个渠道包。
本发明实施例提供了一种安装包多渠道打包方法，通过jenkins从版本控制系统中获取目标安装包，并通过jenkins建立目标安装包的多渠道打包任务，并根据多渠道打包任务生成目标安装包对应的多渠道包。本发明实施例解决了在安装包多渠道打包过程中无法保证生成的渠道包与安装包之间对应关系的唯一性，造成生成的多渠道包并不是对同一个安装包进行渠道打包生成的问题，保证了在对安装包进行多渠道打包时对同一个安装包进行多渠道打包，实现了安装包与多渠道包中的各个安装包之间的唯一性。
实施例二
图2是本发明实施例二中的安装包多渠道打包方法的流程示意图，本发明实施例在上述实施例一的基础上进行优化。如图2所示，该安装包多渠道打包方法可以包括：
步骤201、根据目标安装包的目录信息在持续集成工具jenkins中配置目标安装包的路径参数，目录信息包括目标安装包在版本控制系统中的版本号和版本次序。
在本实施例中，各个初始安装包在版本控制系统中进行统一管理时，初始安装包在版本控制系统的指定目录下创建的备份初始安装包的文件夹的备份路径可以与初始安装包在版本控制系统中进行保存时的目录信息保持一致。此时，各个初始安装包的目录信息可以包括各初始安装包在版本控制系统中的版本号和版本次序，具体示例参考实施例一的解释说明。当需要对版本控制系统中的某一个初始安装包进行多渠道打包时可以将该需要多渠道打包的初始安装包作为目标安装包。示例性的，在jenkins中配置的目标安装包的具体路径为${workspace}/back/$fenqileverison/$fenqilepushnumber/base.apk。其中，${workspace}为当前jenkins的任务的根目录，$fenqileverison为在jenkins配置的目标安装包的版本号，$fenqilepushnumber为在jenkins配置的目标安装包在当前版本号下的第几版安装包。
在本实施例中，图3a是本发明实施例二中的持续集成工具jenkins界面示意图，图3b是本发明实施例二中的持续集成工具jenkins另一个界面示意图。参见图3a和3b，使用jenkins中配置目标安装包的路径参数的好处在于：jenkins具有一个可视化的界面，开发人员可以根据目标安装包的目录信息，在jenkins的可视化界面上配置目标安装包在版本控制系统中所属的版本号和版本次序，并将该版本号和版本次序作为从版本控制系统拉取对应目标安装包的路径参数。可选的，在jenkins中配置需要获取的目标安装报的版本号和版本次序等目录信息时，可以在jenkins的可视化的界面采用下拉列表的形式从列表选项中选择需要配置的目标安装包的目录信息。例如，需要配置的目标安装包的目录信息包括目标安装包的名称、版本号和版本次序等，这里不局限于版本号和版本次序等信息，也可以采用其他特有的标记信息进行区分不同的安装包。示例性的，参见图3a，name栏为版本号提示栏，栏中内容为fenqileverison，表示需要对目标安装包版本号进行配置；choices栏中选择的需要在jenkins配置的目标安装包的版本号4.5.0，descriptionyy栏为上述内容的描述栏。参见图3b，name栏为版本次序提示栏，栏中内容为fenqilepushnumber，表示需要对目标安装包当前版本号对应的版本次序进行配置；choices栏中选择的需要在jenkins配置的目标安装包的当前版本号对应的版本次序01，descriptionyy栏为上述内容的描述栏。
在上述实施例的基础上，可选的，在通过持续集成工具jenkins从版本控制系统中获取目标安装包之前，该安装包多渠道打包方法可以包括：
将开发人员生成的初始安装包按照预先设置的规则提交至版本控制系统中；通过版本控制系统对初始安装包和初始安装包的属性信息进行统一管理，属性信息包括初始安装包在版本控制系统的目录信息、历史记录和修改详情。
步骤202、根据路径参数通过jenkins从版本控制系统中获取目标安装包，目标安装包为版本控制系统中需要多渠道打包的初始安装包。
在本实施例中，路径参数可以是jenkins与版本控制系统之间建立的通过jenkins从版本控制系统中获取目标安装包的路径关系。在jenkins中配置完成需要从版本控制系统中获取的目标安装包的版本号和版本次序，就可以根据路径参数从版本控制系统中直接拉取过来。当在jenkins配置完成需要获取的目标安装包的版本号和版本次序后，jenkins执行相应的获取功能从版本控制系统中直接获取目标安装包。例如，路径参数可以是...back\4.5.0\01\base.apk，其中，“back”表示安装包备份文件夹，“4.5.0”表示目标安装包的版本号，“01”表示目标安装包的版本次序，“base.apk”表示目标安装包。
步骤203、通过jenkins建立目标安装包的多渠道打包任务，并根据多渠道打包任务生成目标安装包对应的多渠道包。
在本实施例中，在通过jenkins从版本控制系统中获取目标安装包后，可以通过jenkins的任务构建功能建立一个目标安装包多渠道打包的任务。可选的，可以使用jenkins中的executeshell，通过命令行的形式建立目标安装包的多渠道打包任务。然后根据目标安装包的多渠道打包任务通过打包工具执行多渠道打包任务生成目标安装包对应的多个渠道包。具体地，通过打包工具可以多个不同的渠道信息分别写入到多个相同的目标安装包中，例如将渠道值写入目标安装包的注释区，这样就可以生成目标安装包的多个渠道包，后续可以将多个渠道包分别发布在不同平台上。另外，也可以通过打包工具将一个渠道值写入目标安装包中生成一个渠道包，然后再将另一个渠道值写入一个相同的目标安装包中生成另一个渠道包，经过多次循环也可以生成目标安装包的多个渠道包。可选的，可以根据目标安装包的多渠道打包任务通过美团打包工具生成多渠道包。
本发明实施例提供了一种安装包多渠道打包方法，根据目标安装包的目录信息在jenkins中配置目标安装包的路径参数，然后根据路径参数通过jenkins从版本控制系统中获取目标安装包，再通过jenkins建立目标安装包的多渠道打包任务，并根据多渠道打包任务生成目标安装包对应的多渠道包。本发明实施例解决了在安装包多渠道打包过程中无法保证生成的渠道包与安装包之间对应关系的唯一性，造成生成的多渠道包并不是对同一个安装包进行渠道打包生成的问题，保证了在对安装包进行多渠道打包时对同一个安装包进行多渠道打包，实现了安装包与多渠道包中的各个安装包之间的唯一性。
实施例三
图4是本发明实施例三中的安装包多渠道打包方法的流程示意图，本发明实施例在上述实施例一和实施例二的基础上进行优化。如图4所示，该安装包多渠道打包方法可以包括：
步骤301、通过持续集成工具jenkins从版本控制系统中获取目标安装包；其中，目标安装包为版本控制系统中需要多渠道打包的初始安装包。
在本实施例中，可选的，通过jenkins从版本控制系统中获取目标安装包，包括：根据目标安装包的目录信息在jenkins中配置目标安装包的路径参数，目录信息包括目标安装包在版本控制系统中的版本号和版本次序；根据路径参数通过jenkins从版本控制系统中获取目标安装包，目标安装包为版本控制系统中需要多渠道打包的初始安装包。
步骤302、通过jenkins设置目标安装包对应的多渠道包的输出目录。
步骤303、根据多渠道包的输出目录通过jenkins建立目标安装包的多渠道打包任务。
在本实施例中，在通过jenkins从版本控制系统中获取目标安装包之后，还可以通过jenkins设置生成的目标安装包对应的多渠道包的输出目录。可选的，可以在jenkins的可视化界面上设置多渠道包的保存目录，以便将生成的多渠道包保存在预先设置保存目录的文件夹，使用户可以轻松找到多渠道包。当然，在jenkins的可视化界面上设置多渠道包的保存目录时，可以采用下拉列表形式从列表中寻找预先设置的保存目录；也可以采用下拉列表形式在列表中新建文件夹，用以保存多渠道包。
示例性的，可以设置目标安装包的输出目录为${workspace}/channels/，其中，${workspace}为当前jenkins的任务的根目录，$channels表示多渠道包，此时生成的多渠道包可以保存在该输出目录下的文件夹中。
步骤304、根据多渠道打包任务生成目标安装包对应的多渠道包。
在上述实施例的基础上，可选的，在通过jenkins从版本控制系统中获取目标安装包之前，该安装包多渠道打包方法可以包括：
将开发人员生成的初始安装包按照预先设置的规则提交至版本控制系统中；通过版本控制系统对初始安装包和初始安装包的属性信息进行统一管理，属性信息包括初始安装包在版本控制系统的目录信息、历史记录和修改详情。
在上述实施例的基础上，可选的，在根据多渠道包的输出目录通过持续集成工具jenkins建立目标安装包的多渠道打包任务之后，还包括：
将目标安装包对应的多渠道包存储至多渠道包的输出目录所属的文件中；通过应用程序接口api将多渠道包推送给指定人员。
在本实施例中，在根据多渠道包的输出目录通过jenkins建立目标安装包的多渠道打包任务之后，可以直接将目标安装包对应的多渠道包存储至多渠道包的输出目录所属的文件中。当指定技术人员或者开发人员需要多渠道包时，可以将jenkins指定目录下的目标安装包对应的多渠道包的链接通过应用程序接口api送给指定相关人员，相关人员可直接下载使用。
本发明实施例提供了一种安装包多渠道打包方法，通过jenkins从版本控制系统中获取目标安装包，再通过jenkins设置目标安装包对应的多渠道包的输出目录，根据多渠道包的输出目录通过jenkins建立目标安装包的多渠道打包任务。本发明实施例解决了在安装包多渠道打包过程中无法保证生成的渠道包与安装包之间对应关系的唯一性，造成生成的多渠道包并不是对同一个安装包进行渠道打包生成的问题，保证了在对安装包进行多渠道打包时对同一个安装包进行多渠道打包，实现了安装包与多渠道包中的各个安装包之间的唯一性。
实施例四
图5是本发明实施例四中的安装包多渠道打包装置的结构示意图，本实施例的安装包多渠道打包装置可适用于用户在对应用安装包进行多渠道打包的情况，该装置可以采用软件和/或硬件的方式来实现。如图5所示，该安装包多渠道打包装置可以包括：安装包获取模块401和多渠道打包模块402；其中，
安装包获取模块401，用于通过持续集成工具jenkins从版本控制系统中获取目标安装包；其中，所述目标安装包为所述版本控制系统中需要多渠道打包的初始安装包；
多渠道打包模块402，用于通过jenkins建立所述目标安装包的多渠道打包任务，并根据所述多渠道打包任务生成所述目标安装包对应的多渠道包。
在上述实施例的基础上，可选的，所述安装包多渠道打包装置还可以包括：
安装包提交包块403，用于将开发人员生成的初始安装包按照预先设置的规则提交至所述版本控制系统中；
安装包管理模块404，用于通过所述版本控制系统对所述初始安装包和所述初始安装包的属性信息进行统一管理；其中，所述属性信息包括所述初始安装包在所述版本控制系统的目录信息、历史记录和修改详情。
在上述实施例的基础上，可选的，所述安装包获取模块401可以包括：
配置单元，用于根据所述目标安装包的目录信息在所述jenkins中配置所述目标安装包的路径参数；其中，所述目录信息包括所述目标安装包在所述版本控制系统中的版本号和版本次序；
获取单元，用于根据所述路径参数通过所述jenkins从所述版本控制系统中获取所述目标安装包；其中，所述目标安装包为所述版本控制系统中需要多渠道打包的初始安装包。
在上述实施例的基础上，可选的，所述多渠道打包模块402可以包括：
输出目录设置单元，用于通过所述jenkins设置所述目标安装包对应的多渠道包的输出目录；
打包任务构建单元，用于根据所述多渠道包的输出目录通过jenkins建立所述目标安装包的多渠道打包任务。
在上述实施例的基础上，可选的，所述安装包多渠道打包装置还包括：
多渠道包存储模块405，用于将所述目标安装包对应的多渠道包存储至所述多渠道包的输出目录所属的文件中；
多渠道包推送模块406，用于通过应用程序接口api将所述多渠道包推送给指定人员。
本发明实施例所提供的安装包多渠道打包装置可执行上述本发明任意实施例所提供的安装包多渠道打包方法，具备执行该安装包多渠道打包方法相应的功能模块和有益效果。
实施例五
图6是本发明实施例五提供的一种计算机设备的结构示意图。图6示出了适于用来实现本发明实施方式的示例性计算机设备512的框图。图6显示的计算机设备512仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。
如图6所示，计算机设备512以通用计算设备的形式表现。计算机设备512的组件可以包括但不限于：一个或者多个处理器516，系统存储器528，连接不同系统组件(包括系统存储器528和处理器516)的总线518。
总线518表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器，外围总线，图形加速端口，处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说，这些体系结构包括但不限于工业标准体系结构(isa)总线，微通道体系结构(mac)总线，增强型isa总线、视频电子标准协会(vesa)局域总线以及外围组件互连(pci)总线。
计算机设备512典型地包括多种计算机系统可读介质。这些介质可以是任何能够被计算机设备512访问的可用介质，包括易失性和非易失性介质，可移动的和不可移动的介质。
系统存储器528可以包括易失性存储器形式的计算机系统可读介质，例如随机存取存储器(ram)530和/或高速缓存存储器532。计算机设备512可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例，存储系统534可以用于读写不可移动的、非易失性磁介质(图6未显示，通常称为“硬盘驱动器”)。尽管图6中未示出，可以提供用于对可移动非易失性磁盘(例如“软盘”)读写的磁盘驱动器，以及对可移动非易失性光盘(例如cd-rom，dvd-rom或者其它光介质)读写的光盘驱动器。在这些情况下，每个驱动器可以通过一个或者多个数据介质接口与总线518相连。存储器528可以包括至少一个程序产品，该程序产品具有一组(例如至少一个)程序模块，这些程序模块被配置以执行本发明各实施例的功能。
具有一组(至少一个)程序模块542的程序/实用工具540，可以存储在例如存储器528中，这样的程序模块542包括但不限于操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块542通常执行本发明所描述的实施例中的功能和/或方法。
计算机设备512也可以与一个或多个外部设备514(例如键盘、指向设备、显示器524等)通信，还可与一个或者多个使得用户能与计算机设备512交互的设备通信，和/或与使得该计算机设备512能与一个或多个其它计算设备进行通信的任何设备(例如网卡，调制解调器等等)通信。这种通信可以通过输入/输出(i/o)接口522进行。并且，计算机设备512还可以通过网络适配器520与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。如图所示，网络适配器520通过总线518与计算机设备512的其它模块通信。应当明白，尽管图6中未示出，可以结合计算机设备512使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、raid系统、磁带驱动器以及数据备份存储系统等。
处理器516通过运行存储在系统存储器528中的程序，从而执行各种功能应用以及数据处理，例如实现本发明实施例所提供的安装包多渠道打包方法，包括：
通过持续集成工具jenkins从版本控制系统中获取目标安装包；其中，所述目标安装包为所述版本控制系统中需要多渠道打包的初始安装包；
通过jenkins建立所述目标安装包的多渠道打包任务，并根据所述多渠道打包任务生成所述目标安装包对应的多渠道包。
实施例六
本发明实施例六还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本发明实施例所提供的安装包多渠道打包方法，包括：
通过持续集成工具jenkins从版本控制系统中获取目标安装包；其中，所述目标安装包为所述版本控制系统中需要多渠道打包的初始安装包；
通过jenkins建立所述目标安装包的多渠道打包任务，并根据所述多渠道打包任务生成所述目标安装包对应的多渠道包。
本发明实施例的计算机存储介质，可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括——但不限于无线、电线、光缆、rf等等，或者上述的任意合适的组合。
可以以一种或多种程序设计语言或其组合来编写用于执行本发明操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如java、smalltalk、c++，还包括常规的过程式程序设计语言—诸如”c”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(lan)或广域网(wan)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。
注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。