Jenkins持续集成集群、APP打包方法和服务器与流程

本发明涉及计算机技术领域，尤其涉及一种jenkins持续集成集群、app打包方法和服务器。

背景技术

詹金斯jenkins持续集成是基于jenkins提供持续集成的服务。在相关技术中，各客户端向服务器(即jenkins持续集成设备)提交打包任务，服务器按顺序依次执行打包。

然而，随着应用app的开发和积累，所需apparchive打包时间也越来越长，由此导致服务器完成所有打包的总耗时很长。并且，如果排序在前的打包任务异常，甚至导致服务器死锁，那么后续打包任务就无法执行了。

所以，上述相关技术存在如何缩短打包时间和提高服务器可靠性的技术问题。

技术实现要素：

本发明实施例提供了一种jenkins持续集成集群、app打包方法和服务器，用于实现缩短打包时间和提高服务器可靠性的技术效果。

第一方面，本发明提供了一种jenkins持续集成集群，包括：

主服务器，以及与所述主服务器连接的多个从服务器；

所述主服务器用于接收客户端提交的多个应用程序app打包任务，根据多个所述打包任务，确定执行每个所述打包任务的所述从服务器，并将每个所述打包任务发送给对应的所述从服务器；

所述从服务器用于接收所述主服务器发送的所述打包任务，并执行所述打包任务。

可选的，所述主服务器用于根据多个所述打包任务的所属类型确定对应每个预设类型的所述打包任务的数量，基于每个所述预设类型对应的所述打包任务的数量将多个所述从服务器划分为对应每个所述预设类型的从服务器组，并按照每个所述打包任务对应的所述预设类型将所述打包任务发送给所述预设类型对应的所述从服务器组中的一个所述从服务器。

可选的，所述主服务器还用于根据多个所述打包任务的名称确定对应每个名称的所述打包任务的数量，基于每个所述名称对应的所述打包任务的数量将所述从服务器组划分为对应每个所述名称的从服务器子组，并按照每个所述打包任务的名称将所述打包任务发送给对应所述名称的所述从服务器子组中的一个所述从服务器。

可选的，所述主服务器用于将所述打包任务发送给所述从服务器子组中权重最高的所述从服务器。

可选的，所述主服务器还用于按照每个所述从服务器所在的所述从服务器组向所述从服务器发送安全证书。

可选的，所述主服务器还用于获取每个所述从服务器的状态，按照每个所述从服务器的状态为每个所述从服务器分配所述权重。

第二方面，本发明提供了一种应用程序app打包方法，应用于jenkins持续集成集群的主服务器，所述jenkins持续集成集群还包括与所述主服务器连接的多个从服务器，所述方法包括：

接收客户端提交的多个app打包任务；

根据多个所述打包任务，确定执行每个所述打包任务的所述从服务器；

将每个所述打包任务发送给对应的所述从服务器，以使所述从服务器接收所述主服务器发送的所述打包任务，并执行所述打包任务。

可选的，根据多个所述打包任务，确定执行每个所述打包任务的所述从服务器，包括：

根据多个所述打包任务的所属类型确定对应每个预设类型的所述打包任务的数量；

基于每个所述预设类型对应的所述打包任务的数量将多个所述从服务器划分为对应每个所述预设类型的从服务器组；

按照每个所述打包任务对应的所述预设类型，确定所述预设类型对应的所述从服务器组中的一个所述从服务器为执行所述打包任务的所述服务器。

可选的，根据多个所述打包任务，确定执行每个所述打包任务的所述从服务器，还包括：

根据多个所述打包任务的名称确定对应每个名称的所述打包任务的数量；

基于每个所述名称对应的所述打包任务的数量将所述从服务器组划分为对应每个所述名称的从服务器子组；

确定所述预设类型对应的所述从服务器组中的一个所述从服务器为执行所述打包任务的所述服务器，包括：

按照每个所述打包任务的名称，确定所述名称对应的所述从服务器子组中的一个所述从服务器为执行所述打包任务的所述服务器。

可选的，确定所述名称对应的所述从服务器子组中的一个所述从服务器为执行所述打包任务的所述服务器，包括：

确定所述从服务器子组中权重最高的所述从服务器为执行所述打包任务的所述从服务器。

可选的，所述方法还包括：

按照每个所述从服务器所在的所述从服务器组向所述从服务器发送安全证书。

可选的，所述方法还包括：

获取每个所述从服务器的状态；

按照每个所述从服务器的状态为每个所述从服务器分配所述权重。

第三方面，本发明提供了一种服务器，所述服务器为jenkins持续集成集群的主服务器，所述jenkins持续集成集群还包括与所述主服务器连接的多个从服务器，所述服务器包括：

接收模块，用于接收客户端提交的多个app打包任务；

确定模块，用于根据多个所述打包任务，确定执行每个所述打包任务的所述从服务器；

第一发送模块，用于将每个所述打包任务发送给对应的所述从服务器，以使所述从服务器接收所述主服务器发送的所述打包任务，并执行所述打包任务。

可选的，所述确定模块用于根据多个所述打包任务的所属类型确定对应每个预设类型的所述打包任务的数量；基于每个所述预设类型对应的所述打包任务的数量将多个所述从服务器划分为对应每个所述预设类型的从服务器组；按照每个所述打包任务对应的所述预设类型，确定所述预设类型对应的所述从服务器组中的一个所述从服务器为执行所述打包任务的所述服务器。

可选的，所述确定模块还用于根据多个所述打包任务的名称确定对应每个名称的所述打包任务的数量；基于每个所述名称对应的所述打包任务的数量将所述从服务器组划分为对应每个所述名称的从服务器子组；按照每个所述打包任务的名称，确定所述名称对应的所述从服务器子组中的一个所述从服务器为执行所述打包任务的所述服务器。

可选的，所述确定模块用于确定所述从服务器子组中权重最高的所述从服务器为执行所述打包任务的所述从服务器。

可选的，所述服务器还包括第二发送模块，用于按照每个所述从服务器所在的所述从服务器组向所述从服务器发送安全证书。

可选的，所述服务器还包括：

获取模块，用于获取每个所述从服务器的状态；

权重分配模块，用于按照每个所述从服务器的状态为每个所述从服务器分配所述权重。

第四方面，本发明提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现第二方面任一项所述方法的步骤。

第五方面，本发明提供了一种服务器，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现第二方面任一项所述方法的步骤。

本申请实施例中的上述一个或多个技术方案，至少具有如下一种或多种技术效果：

在本发明实施例的技术方案中，jenkins持续集成集群包括主服务器和多个从服务器，所述主服务器用于接收客户端提交的多个打包任务，根据多个所述打包任务，确定执行每个所述打包任务的所述从服务器，并将每个所述打包任务发送给对应的所述从服务器，所述从服务器用于接收所述主服务器发送的所述打包任务，并执行所述打包任务。可见，通过将多个所述打包任务分配给多个所述从服务器并行执行，相较于现有技术执行相同数量的打包任务，本发明实施例缩短了打包时间。并且，由于执行打包任务的所述从服务器有多个，即使其中一个或多个所述从服务器死锁，后续的所述打包任务可以分配给其他所述从服务器执行，由此避免了死锁而导致后续打包任务无法执行的后果，故而提高了服务器可靠性。

附图说明

图1为本发明实施例中一种jenkins持续集成集群的架构示意图；

图2为本发明实施例中另一种jenkins持续集成集群的架构示意图；

图3为本发明实施例中另一种jenkins持续集成集群的架构示意图；

图4为本发明实施例中app打包方法的流程图；

图5为本发明实施例中一服务器的结构示意图；

图6为本发明实施例中另一服务器的结构示意图。

具体实施方式

本发明实施例提供了一种jenkins持续集成集群、app打包方法和服务器，用于实现缩短打包时间和提高服务器可靠性的技术效果。

为了解决上述技术问题，本发明提供的技术方案总体思路如下：

在本发明实施例的技术方案中，jenkins持续集成集群包括主服务器和多个从服务器，所述主服务器用于接收客户端提交的多个打包任务，根据多个所述打包任务，确定执行每个所述打包任务的所述从服务器，并将每个所述打包任务发送给对应的所述从服务器，所述从服务器用于接收所述主服务器发送的所述打包任务，并执行所述打包任务。可见，通过将多个所述打包任务分配给多个所述从服务器并行执行，相较于现有技术执行相同数量的打包任务，本发明实施例缩短了打包时间。并且，由于执行打包任务的所述从服务器有多个，即使其中一个或多个所述从服务器死锁，后续的所述打包任务可以分配给其他所述从服务器执行，由此避免了死锁而导致后续打包任务无法执行的后果，故而提高了服务器可靠性。

下面通过附图以及具体实施例对本发明技术方案做详细的说明，应当理解本申请实施例以及实施例中的具体特征是对本申请技术方案的详细的说明，而不是对本申请技术方案的限定，在不冲突的情况下，本申请实施例以及实施例中的技术特征可以相互组合。

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

本发明第一方面提供了一种jenkins持续集成集群。

jenkins源自于哈得孙hudson，是一个基于爪哇java编写的开源集成工具，其提供了软件开发持续集成服务，它运行在javaservlet容器中，支持软件配置管理工具(包括accurevscm、cvs、subversion、git、perforce、clearcase和rtc)，可以执行基于apacheant和apachemaven的项目，以及任意的shell脚本和windows批处理命令。持续集成是一种软件开发实践，在实践中项目成员频繁地进行集成，集成后都会通过自动化构建(包括测试)。大型团队使用此种方法大大地减少了集成问题并且能够快速地开发出高内聚性的软件。

如图1所示，本发明实施例中的jenkins持续集成集群包括一个主服务器和多个从服务器，多个从服务器与主服务器连接。尽管jenkins持续集成集群包括一个主服务器和多个从服务器，但是jenkins持续集成集群一致对每个客户端提供服务，故而客户端可以将jenkins持续集成集群作为一个服务器来看。其中，客户端指的是提交应用程序app打包任务所使用的终端，例如平板电脑或一体机等。

具体来讲，客户端的打包任务提交给主服务器，故而主服务器用于接收每个客户端提交的app打包任务。主服务器接收多个打包任务后，根据多个打包任务，确定执行每个打包任务的从服务器，并将每个打包任务发送给对应的从服务器。

其中，在一种实施方式中，主服务器接收多个打包任务指的是主服务器接收预设数量的打包任务。预设数量可以根据实际进行设置。换言之，主服务器在接收到足够预设数量的打包任务后，为本次预设数量的打包任务分配具体执行的从服务器。分配完成后，再重新等待足够预设数量的打包任务，并再次分配从服务器。或者，在另一种实施方式中，由于接入jenkins持续集成集群的客户端有多个，每个客户端按照需要随时向jenkins持续集成集群提交打包任务，因此主服务器在任意时刻收到的打包任务可能是多个。故而在该种实施方式中，以时刻进行划分，主服务器为每个时刻收到的打包任务分配从服务器。在具体实现过程中，可以采用上述任一种实施方式，或者在不冲突的情况下结合两种实施方式，本发明不做具体限制。

主服务器根据多个打包任务确定执行每个打包任务的从服务器有多种实施方式。例如，根据多个打包任务所属类型，为每个类型的打包任务划分出一定数量的从服务器来执行该类型的打包任务。或者，例如根据多个打包任务的名称，为不同名称的打包任务划分一定数量的从服务器来执行该名称的打包任务。或者，例如根据打包任务所需要占用资源，为打包任务分配从服务器，进一步例如为占用资源较高的打包任务分配剩余资源较多的从服务器，为占用资源较少的打包任务分配剩余资源较少的从服务器。在后文中，将对其中几种实施方式进行具体介绍。在具体实现过程中，本发明所述领域的普通技术人员可以根据实际进行选择，本发明不做具体限制。

为每个打包任务确定出对应的从服务器后，主服务器将每个打包任务发送到对应的从服务器中。进而，从服务器接收打包任务后，执行打包任务，以完成打包。

由上述描述可知，通过将多个打包任务分配给多个从服务器并行执行，相较于现有技术执行相同数量的打包任务，本发明实施例缩短了打包时间。并且，由于执行打包任务的从服务器有多个，即使其中一个或多个从服务器死锁，后续打包任务可以分配给其他从服务器执行，由此避免了死锁导致后续打包任务无法执行的后果，故而提高了服务器可靠性。

下面对几种主服务器确定执行打包任务对应的从服务器的实施方式进行介绍。在具体实现过程中，包括但不限于以下几种实施方式。

第一种：

在第一种实施方式中，主服务器具体用于：

根据多个所述打包任务的所属类型确定对应每个预设类型的所述打包任务的数量，基于每个所述预设类型对应的所述打包任务的数量将多个所述从服务器划分为对应每个所述预设类型的从服务器组，并按照每个所述打包任务对应的所述预设类型将所述打包任务发送给所述预设类型对应的所述从服务器组中的一个所述从服务器。

具体来讲，打包任务的属性中包括打包任务的所属类型。在本发明实施例中，类型包括但不限于xcodeproj，provisioning_profile_specifier和code_sign_identity等。主服务器通过读取打包任务的属性确定打包任务的所属类型。

主服务器中预先设置有预设类型，例如xcodeproj，provisioning_profile_specifier和code_sign_identity等，本领域技术人员可以根据需要统计打包任务数量的类型设置预设类型。读取出多个打包任务的所属类型，进一步统计出每个预设类型的打包任务的数量。例如，通过如下代码统计xcodeproj，provisioning_profile_specifier和code_sign_identity类型的打包任务数量。

match_provisioning_profile_specifier(

xcodeproj:{xcworkspace_name},//获取证书

provisioning_profile_specifier:{xcworkspace_provision}//验证权限

code_sign_identity:'iphonedeveloper',

target:{target_name}',

development_team:"temp_id"//验证工程合法性

)

为了缩短打包时间并合理分配从服务器资源，主服务器基于每个预设类型对应的打包任务的数量对多个从服务器进行划分，进而将多个从服务器划分多个从服务器组，如图2所示。具体来讲，如果一个预设类型对应的打包任务数量较多，则主服务器划分较多数量的从服务器作为该预设类型对应的从服务器组；反之，如果一个预设类型对应的打包任务数量较少，则主服务器划分较少数量的从服务器作为该预设类型对应的从服务器组。每个从服务器组包括零个、一个或多个从服务器。

举例来说，假设从服务器共有10个，在当前接收到的100个打包任务中，xcodeproj类型的打包任务有77个，provisioning_profile_specifier类型的打包任务有23个。那么，主服务器将从服务器划分为两个从服务器组，其中第一个从服务器组包括8个从服务器，对应xcodeproj类型；第二个从服务器组包括2个从服务器，对应provisioning_profile_specifier类型。

另外，本领域技术人员应当理解，尽管主服务器“基于每个所述预设类型对应的所述打包任务的数量将多个所述从服务器划分为对应每个所述预设类型的从服务器组”，但是，如果某个预设类型对应的打包任务数量为零，为了进一步缩短打包时间并合理分配从服务器，主服务器可以不为该预设类型划分从服务器组。那么，从服务器组的数量将等于或小于预设类型的数量，且每个从服务器组包括一个或多个从服务器。

接下来，对于每个打包任务，主服务器根据打包任务所属类型，将该打包任务发送给对应预设类型的从服务器组中的任意一个从服务器执行。

沿用上文中的例子，在接收到的100个打包任务中，第一个打包任务的所属类型为xcodeproj，则主服务器将第一个打包任务发送给第一个从服务器组中的任意一个从服务器执行。

由上述描述可以看出，在第一种实施方式中，为打包任务数量较多的预设类型分配数量较多的从服务器，保证从服务器资源合理分配，避免大量同类型打包任务由于没有充足设备资源而延长打包时间。

第二种：

在第二种实施方式中，主服务器具体用于：

根据多个所述打包任务的所属类型确定对应每个预设类型的所述打包任务的数量，基于每个所述预设类型对应的所述打包任务的数量将多个所述从服务器划分为对应每个所述预设类型的从服务器组，并按照每个所述打包任务对应的所述预设类型将所述打包任务发送给所述预设类型对应的所述从服务器组中的权重最高的所述从服务器。

第二种实施方式与第一种实施方式的相同之处不再重复赘述。第二种实施方式与第一种实施方式的不同之处在于：主服务器除了将从服务器划分为多个从服务器组，主服务器还根据每个从服务器的状态为每个从服务器分配权重，并且将打包任务分配给从服务器组中权重最高的从服务器来执行。

具体来讲，主服务器实时获取每个从服务器的状态，并动态地为每个从服务器分配权重。其中，从服务器的状态包括但不限于从服务器的cpu占用率、内存占用率、运行线程数量、接口数量和网络速度等。从服务器的状态越好，例如cpu占用率越低、内存占用率越低、运行线程数量越少、接口数量越多和网络速度越高，主服务器为该从服务器动态分配的权重则越高；反之，从服务器的状态越差，例如cpu占用率越高、内存占用率越高、运行线程数量越多、接口数量越少和网络速度越低，主服务器为该从服务器动态分配的权重则越低。那么，将打包任务分配给从服务器组中权重最高的从服务器，由此保证每个打包任务都可以分配给当前从服务器组中状态最好的从服务器执行，进而降低打包任务排队等待的时间，也避免了打包任务分配给死锁的从服务器，进一步缩短打包时间，提高服务器可靠性。

沿用上文中的例子来说，在分配第一个打包任务时，第一个从服务器组中的8个从服务器ip地址和权重如下：

192.168.0.101weight:25

192.168.0.102weight:15

192.168.0.103weight:10

192.168.0.104weight:10

192.168.0.105weight:10

192.168.0.106weight:10

192.168.0.107weight:10

192.168.0.108weight:10

其中，“192.168.0.101weight:25”表示从服务器的ip地址为192.168.0.101，权重为25。其余7个以此类推，此处就不再一一详述了。由于此时ip地址为192.168.0.101的从服务器权重最高，因此主服务器将第一个打包任务发送给第一个从服务器组中ip地址为192.168.0.101的从服务器执行。

第三种：

结合第一种实施方式，在第三种实施方式中，主服务器还进一步用于：

根据多个所述打包任务的名称确定对应每个名称的所述打包任务的数量，基于每个所述名称对应的所述打包任务的数量将所述从服务器组划分为对应每个所述名称的从服务器子组，并按照每个所述打包任务的名称将所述打包任务发送给对应所述名称的所述从服务器子组中的一个所述从服务器。

具体来讲，打包任务的属性中还进一步包括打包任务的名称。在本发明实施例中，打包任务的名称可以根据需要预先设置一个或多个，本发明不做具体限制。主服务器通过读取打包任务的属性确定打包任务的名称，进一步统计出每个名称的打包任务的数量。例如，通过如下代码统计xcodeproj，provisioning_profile_specifier和code_sign_identity类型下每个名称的打包任务数量。

match_job_name_specifier(

xcodeproj:{xcworkspace_name},//获取证书

job_name:{job_name}

code_sign_identity:'iphonedeveloper',

target:{target_name}',

development_team:"temp_id"//使用最高权限进行自动验证和从服务器权限匹配

)

为了进一步缩短打包时间并合理分配从服务器资源，主服务器基于每个预设类型下每个名称对应的打包任务的数量将每个从服务器组进一步划分为多个从服务器子组，如图3所示。具体来讲，如果一个名称对应的打包任务的数量较多，则主服务器划分较多数量的从服务器作为该名称对应的从服务器子组；反之，如果一个名称对应的打包任务的数量较少，则主服务器划分较少数量的从服务器作为该名称对应的从服务器子组。每个从服务器子组包括一个或多个从服务器。

沿用上文中的例子来说，xcodeproj类型的打包任务有77个，对于xcodeproj类型的第一个从服务器组包括8个从服务器。在xcodeproj类型的77个打包任务中，名称为aaa的打包任务有50个，名称为bbb的打包任务有27个。那么，主服务器将第一个从服务器组划分为两个从服务器子组，其中第一个从服务器子组包括5个从服务器，对应aaa；第二个从服务器子组包括3个从服务器，对应bbb。provisioning_profile_specifier类型的打包任务有23个，对于provisioning_profile_specifier类型的第二个从服务器组包括2个从服务器。在provisioning_profile_specifier类型的23个打包任务中，名称为ccc的打包任务有11个，名称为ddd的打包任务有12个。那么，主服务器将第二个从服务器组划分为两个从服务器子组，其中第一个从服务器子组包括1个从服务器，对应ccc；第二个从服务器子组包括1个从服务器，对应ddd。

接下来，对于每个打包任务，主服务器根据每个打包任务的所属类型以及名称，将该打包任务发送给对应从服务器子组中的任意一个从服务器执行。

沿用上文中的例子，在接收到的100个打包任务中，第一个打包任务的所属类型为xcodeproj，名称为aaa，则主服务器将第一个打包任务发送给第一个从服务器组的第一个从服务器子组中的任意一个从服务器执行。

由上述描述可以看出，在第三种实施方式中，为打包任务数量较多的名称分配数量较多的从服务器，保证从服务器资源合理分配，避免大量同名称打包任务由于没有充足设备资源而延长打包时间。

第四种：

结合第三种实施方式，在第四种实施方式中，主服务器在将打包任务发送给从服务器子组中任意一个从服务器时，具体用于将所述打包任务发送给所述从服务器子组中权重最高的所述从服务器。

沿用上文中的例子来说，在分配执行第一个打包任务的从服务器时，第一个从服务器组的第一个从服务器子组中的5个从服务器ip地址和权重如下：

192.168.0.101weight:25

192.168.0.102weight:15

192.168.0.103weight:10

192.168.0.104weight:10

192.168.0.105weight:10

由于此时ip地址为192.168.0.101的从服务器权重最高，因此主服务器将第一个打包任务发送给第一个从服务器组的第一个服务器子组中ip地址为192.168.0.101的从服务器执行。

在具体实现过程中，包括但不限于以上几种实施方式。本领域技术人员可以根据实际选择任意一种实施方式，本发明不做具体限制。

进一步，结合上述实施方式中的任一实施方式，主服务器进一步还用于：

按照每个所述从服务器所在的所述从服务器组向所述从服务器发送安全证书。

具体来讲，由于主服务器每次接收的多个打包任务所属类型和名称可能有所不同，因此，主服务器具体是按照每次接收到的多个打包任务的实际情况动态划分从服务器组和从服务器子组的。因此，对于从服务器，其所在的从服务器组和从服务器子组也是会发生变化的。

为了保证从服务器能够顺利执行打包任务，主服务器在完成从服务器组和从服务器子组的划分之后，根据每个从服务器所在的从服务器组以及所在从服务器子组，向每个从服务器发送对应的安全证书。

更进一步，完成从服务器组和从服务器子组的划分之后，主服务器还用于：

获取每个所述从服务器的状态，按照每个所述从服务器的状态为每个所述从服务器分配所述权重。

举例来说，可以通过如下过程实现安全证书发送、权重分配等其他预处理：

platform：iosdo

gym(

workspace:"./#{workspacename}.xcworkspace",//配置工程名

scheme:"#{schemename}",//配置项目名

silent:true,//静默打包方式

clean:true,//清除旧的构建包

configuration:configuration,//配置文件不暴露

output_directory:"./build",//输出文件夹路径

output_name:outputname,//输出文件名

export_method:method,//配置导出方式为method保密

destination:"generic/platform＝ios"，//平台描述为ios平台

)

end

下面对构建jenkins持续集成集群进行介绍。

在主服务器上部署jenkins的工作域，该工作域中包括多个节点。主服务器将jenkins项目发布到从服务器上，部署项目到不同从服务器的公猫tomcat或应用服务器jboss，这样就形成了jenkins持续集成集群。从服务器不需要安装jenkins，只需要在从服务器上部署每个节点对应的工作空间。具体构建集群的步骤如下：

(1)增加jenkins节点(即从服务器)：

为每个从服务器设置节点ip地址，例如上文中的192.168.0.101等。为每个从服务器设置统一的启动验证方式。该启动验证方式可以为任意验证方式，例如ssh(安全壳协议，secureshell)等。以及为每个从服务器设置域名等。

(2)设置节点属性：

为每个从服务器设置最大执行任务数量，例如5或6等。为每个从服务器建立工作目录。设置每个从服务器的jdk(java语言的软件开发工具包，javadevelopmentkit)路径。

(3)启动主服务器：

通过脚本命令sudolaunchctlload/library/launchdaemons/org.jenkins-ci.plist启动主服务器。

(4)启动各个节点：

通过launchagent方式启动所有从服务器，从服务器下载主服务器分配的安全证书，并保存在本地。

在本发明实施例中，主服务器将每个从服务器jdk路径配置与主服务器jdk路径一致为较佳选择。一方面，方便主服务器通过统一的jdk路径进入任意从服务器进行管理，另一方面，后续增加新的从服务器时不需要再单独设置jdk路径。

另外，对于客户端，在本发明实施例中，客户端自动打包、丢弃旧的构造建立新的构造。具体地，客户端可以通过运行以下代码实现：

exportlang＝en_us.utf-8

exportlanguage＝en_us.utf-8

exportlc_all＝en_us.utf-8

exportpath＝"/usr/local/bin:$path"

echo"rm-rfbuild"

rm-rfbuild

echo"mkdirbuild"

mkdirbuild

sh${workspace}/build.sh${jobname}${buildnum}${exportmethod}

cd${workspace}/build

基于与前述实施例中jenkins持续集成集群同样的发明构思，本发明第二方面还提供一种app打包方法，应用于主服务器，如图4所示，包括：

s101：接收客户端提交的多个app打包任务；

s102：根据多个所述打包任务，确定执行每个所述打包任务的所述从服务器；

s103：将每个所述打包任务发送给对应的所述从服务器，以使所述从服务器接收所述主服务器发送的所述打包任务，并执行所述打包任务。

其中，s102具体包括：

根据多个所述打包任务的所属类型确定对应每个预设类型的所述打包任务的数量；

基于每个所述预设类型对应的所述打包任务的数量将多个所述从服务器划分为对应每个所述预设类型的从服务器组；

按照每个所述打包任务对应的所述预设类型，确定所述预设类型对应的所述从服务器组中的一个所述从服务器为执行所述打包任务的所述服务器。

进一步，s102还可以包括：

根据多个所述打包任务的名称确定对应每个名称的所述打包任务的数量；

基于每个所述名称对应的所述打包任务的数量将所述从服务器组划分为对应每个所述名称的从服务器子组；

确定所述预设类型对应的所述从服务器组中的一个所述从服务器为执行所述打包任务的所述服务器，包括：

按照每个所述打包任务的名称，确定所述名称对应的所述从服务器子组中的一个所述从服务器为执行所述打包任务的所述服务器。

更进一步，确定所述名称对应的所述从服务器子组中的一个所述从服务器为执行所述打包任务的所述服务器，包括：

确定所述从服务器子组中权重最高的所述从服务器为执行所述打包任务的所述从服务器。

更进一步，所述方法还包括：

按照每个所述从服务器所在的所述从服务器组向所述从服务器发送安全证书。

更进一步，所述方法还包括：

获取每个所述从服务器的状态；

按照每个所述从服务器的状态为每个所述从服务器分配所述权重。

前述图1-图3实施例中的jenkins持续集成集群的各种变化方式和具体实例同样适用于本实施例的app打包方法，通过前述对jenkins持续集成集群的详细描述，本领域技术人员可以清楚的知道本实施例中app打包方法的实施方法，所以为了说明书的简洁，在此不再详述。

基于与前述实施例中jenkins持续集成集群同样的发明构思，本发明第三方面还提供一种服务器，所述服务器为前文所述主服务器，如图5所示，所述服务器包括：

接收模块101，用于接收客户端提交的多个app打包任务；

确定模块102，用于根据多个所述打包任务，确定执行每个所述打包任务的所述从服务器；

第一发送模块103，用于将每个所述打包任务发送给对应的所述从服务器，以使所述从服务器接收所述主服务器发送的所述打包任务，并执行所述打包任务。

具体来讲，确定模块102用于根据多个所述打包任务的所属类型确定对应每个预设类型的所述打包任务的数量；基于每个所述预设类型对应的所述打包任务的数量将多个所述从服务器划分为对应每个所述预设类型的从服务器组；按照每个所述打包任务对应的所述预设类型，确定所述预设类型对应的所述从服务器组中的一个所述从服务器为执行所述打包任务的所述服务器。

进一步，确定模块102还用于根据多个所述打包任务的名称确定对应每个名称的所述打包任务的数量；基于每个所述名称对应的所述打包任务的数量将所述从服务器组划分为对应每个所述名称的从服务器子组；按照每个所述打包任务的名称，确定所述名称对应的所述从服务器子组中的一个所述从服务器为执行所述打包任务的所述服务器。

更进一步，确定模块102用于确定所述从服务器子组中权重最高的所述从服务器为执行所述打包任务的所述从服务器。

更进一步，所述服务器还包括第二发送模块，用于按照每个所述从服务器所在的所述从服务器组向所述从服务器发送安全证书。

更进一步，所述服务器还包括：

获取模块，用于获取每个所述从服务器的状态；

权重分配模块，用于按照每个所述从服务器的状态为每个所述从服务器分配所述权重。

前述图1-图3实施例中的jenkins持续集成集群的各种变化方式和具体实例同样适用于本实施例的服务器，通过前述对jenkins持续集成集群的详细描述，本领域技术人员可以清楚的知道本实施例中服务器的实施方法，所以为了说明书的简洁，在此不再详述。

基于与前述实施例中jenkins持续集成集群和app打包方法同样的发明构思，本发明还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现前文所述主服务器执行的任一方法的步骤。

基于与前述实施例中jenkins持续集成集群和app打包方法同样的发明构思，本发明还提供一种服务器，包括存储器204、处理器202及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现前文所述主服务器执行的任一方法的步骤。

其中，在图6中，总线架构(用总线200来代表)，总线200可以包括任意数量的互联的总线和桥，总线200将包括由处理器202代表的一个或多个处理器和存储器204代表的存储器的各种电路链接在一起。总线200还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口206在总线200和接收器201和发送器203之间提供接口。接收器201和发送器203可以是同一个元件，即收发机，提供用于在传输介质上与各种其他装置通信的单元。

处理器202负责管理总线200和通常的处理，而存储器204可以被用于存储处理器202在执行操作时所使用的数据。

前述图1-图3实施例中的jenkins持续集成集群的各种变化方式和具体实例同样适用于本实施例的服务器，通过前述对jenkins持续集成集群的详细描述，本领域技术人员可以清楚的知道本实施例中服务器的实施方法，所以为了说明书的简洁，在此不再详述。

本申请实施例中的上述一个或多个技术方案，至少具有如下一种或多种技术效果：

在本发明实施例的技术方案中，jenkins持续集成集群包括主服务器和多个从服务器，所述主服务器用于接收客户端提交的多个打包任务，根据多个所述打包任务，确定执行每个所述打包任务的所述从服务器，并将每个所述打包任务发送给对应的所述从服务器，所述从服务器用于接收所述主服务器发送的所述打包任务，并执行所述打包任务。可见，通过将多个所述打包任务分配给多个所述从服务器并行执行，相较于现有技术执行相同数量的打包任务，本发明实施例缩短了打包时间。并且，由于执行打包任务的所述从服务器有多个，即使其中一个或多个所述从服务器死锁，后续的所述打包任务可以分配给其他所述从服务器执行，由此避免了死锁而导致后续打包任务无法执行的后果，故而提高了服务器可靠性。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。