一种应用部署方法及系统与流程

本说明书实施例涉及计算机技术领域，尤其涉及一种应用部署方法及系统。

背景技术：

应用部署时通常需要依赖很多的对象，这里依赖的对象可以是应用部署时所需要的底层运行环境软件、第三方库等，比如jdk(javadevelopmentkit，java语言的软件开发工具包)、jar文件(javaarchivefile，java归档文件)、mysql数据库等。对于一个应用部署需要依赖的对象，例如，需要依赖的对象的当前版本编号为v，在某个时间检测到当前版本v的对象存在缺陷，需要升级到版本v+1才能解决对象存在缺陷的问题，进而才能正常的进行应用部署。因此当进行应用部署时，需要检测应用部署时依赖的对象的版本，检测通过后才能正常进行应用部署。

现有的方式为：在应用的源代码中内置依赖规则，并在应用中插入对应的扫描插件，当应用部署时，通过扫描插件扫描应用部署时依赖的对象的版本，判断当前依赖的对象的版本是否满足依赖规则，若满足才能正常的进行应用部署。但是现有的这种方式非常不灵活，当应用的源代码中内置依赖规则变更后，需要用户手动去升级对应的扫描插件，如果用户没有及时升级对应的扫描插件，这样新的依赖规则就不能及时发挥作用，有可能导致应用部署时依赖的对象存在缺陷，导致应用在部署后出现故障，进而造成损失。

技术实现要素：

针对上述技术问题，本说明书实施例提供一种应用部署方法及系统，技术方案如下：

一种应用部署方法，应用于版本控制系统，所述系统包括规则管理平台与至少一台应用服务器，所述规则管理平台与所述系统包含的所有应用服务器连接，其中在所述规则管理平台内可实时配置依赖规则，并且所配置的依赖规则实时生效于所述系统内的任一应用服务器，该方法包括：

规则管理平台接收应用服务器发送的在所述应用服务器进行应用部署时需要依赖的对象的名称以及依赖的对象的版本信息；

规则管理平台在配置的依赖规则中，查找与所述名称相匹配的依赖规则；

规则管理平台根据查找到的依赖规则对所述版本信息进行校验；

规则管理平台将校验结果发送至应用服务器；

应用服务器接收所述校验结果，在所述校验结果为成功的情况下，进行应用部署。

一种应用部署系统，该系统包括：规则管理平台与应用服务器；

规则管理平台接收应用服务器发送的在所述应用服务器进行应用部署时需要依赖的对象的名称以及依赖的对象的版本信息；

规则管理平台在配置的依赖规则中，查找与所述名称相匹配的依赖规则；

规则管理平台根据查找到的依赖规则对所述版本信息进行校验；

规则管理平台将校验结果发送至应用服务器；

应用服务器接收所述校验结果，在所述校验结果为成功的情况下，进行应用部署。

本说明书实施例所提供的技术方案，规则管理平台接收应用服务器发送的应用部署时需要依赖的对象的名称以及依赖的对象的版本信息，在配置的依赖规则中，规则管理平台查找与依赖的对象的名称相匹配的依赖规则，规则管理平台根据查找到的依赖规则对依赖的对象的版本信息进行校验，并将校验结果发送至应用服务器，应用服务器接收校验结果，在校验结果为成功的情况下，进行应用部署。确保应用部署时需要依赖的对象是正常的对象，由此保证了应用在部署后可以正常运行，避免了损失的发生。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本说明书实施例。

此外，本说明书实施例中的任一实施例并不需要达到上述的全部效果。

附图说明

为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书实施例中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1是本说明书实施例的规则管理平台与应用服务器的连接示意图；

图2是本说明书实施例的应用部署方法中规则管理平台与应用服务器的交互示意图；

图3是本说明书实施例的应用部署方法中规则管理平台与应用服务器的优选交互示意图；

图4是本说明书实施例的规则管理平台统计依赖的对象的使用状况和分布情况的示意图；

图5是本说明书实施例的应用于规则管理平台的应用部署装置的结构示意图；

图6是用于配置本说明书实施例装置的一种设备的结构示意图。

具体实施方式

应用部署时需要依赖很多的对象，依赖的对象存在不同的版本，当进行应用部署时，需要检测当前版本的对象，检测通过后才能依赖对象进行正常的应用部署，例如对于jdk，作为应用部署时依赖的对象，当前使用的版本编号为v，在某个时间检测出当前版本v的jdk存在缺陷，则当前版本v的jdk不能再使用，需要升级到版本v+1，以解决jdk存在缺陷的问题，进而才能依赖jdk正常的进行应用部署。

当前应用在应用服务器部署时，通过应用中插入的扫描插件，扫描应用部署时依赖的对象的版本，判断当前依赖的对象的版本是否满足在应用的源代码中内置的依赖规则，若满足依赖规则，才能正常的进行应用部署。由以上可知，由于应用在应用服务器部署时依赖于扫描插件，当某个时间检测出依赖的对象存在缺陷时，则正在使用的依赖规则需要停止使用，需要变更依赖规则及时生效至应用服务器，因此需要将应用的源代码中内置的依赖规则进行重新配置，原先的扫描插件对应变更之前的依赖规则，在将应用的源代码中内置的依赖规则进行重新配置之后，需要用户手动去升级对应的扫描插件，这种方式非常的不灵活，并且如果用户没有及时升级对应的扫描插件，这样新的依赖规则就不能及时发挥作用，有可能导致应用部署时依赖的对象存在缺陷，导致应用在部署后出现故障，进而造成损失。

针对上述问题，本说明书实施例提供一种应用部署的技术方案，应用于版本控制系统，该系统包括规则管理平台与至少一台应用服务器，该规则管理平台与版本系统包含的所有应用服务器连接，其中规则管理平台与应用服务器的连接示意图如图1所示。其中在规则管理平台内，可以实时配置依赖规则，并且所配置的依赖规则实时生效于版本控制系统内的任一应用服务器，意味着当某个时间检测出依赖的对象存在缺陷时，可以在规则管理平台实时配置依赖规则，所配置的依赖规则可以及时生效于版本控制系统内的任一应用服务器。由以上可知，避免了用户升级扫描插件的操作，可以确保应用部署时需要依赖的对象是正常的对象，如此一来保证了应用在部署后可以正常运行，避免了损失的发生。

具体的，本说明书实施例提供的技术方案如下：

规则管理平台接收应用服务器发送的在所述应用服务器进行应用部署时需要依赖的对象的名称以及依赖的对象的版本信息；规则管理平台在配置的依赖规则中，查找与所述名称相匹配的依赖规则；规则管理平台根据查找到的依赖规则对所述版本信息进行校验；规则管理平台将校验结果发送至应用服务器；应用服务器接收所述校验结果，在所述校验结果为成功的情况下，进行应用部署。

为了使本领域技术人员更好地理解本说明书实施例中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行详细地描述，显然，所描述的实施例仅仅是本说明书的一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于保护的范围。

如图2所示，为本说明书实施例提供的应用部署方法中规则管理平台与应用服务器的交互图，该方法可以包括以下步骤：

s201，规则管理平台接收应用服务器发送的在所述应用服务器进行应用部署时需要依赖的对象的名称以及依赖的对象的版本信息；

当应用在应用服务器进行部署时，会通过部署脚本准备相应的依赖的对象，并对其中一些对象，例如对可执行jar文件进行编译连接，在经过上述步骤之后，部署脚本会采集应用在应用服务器部署时需要依赖的对象的名称以及依赖的对象的版本信息，在采集完上述信息之后上报给应用服务器，由应用服务器将应用在本地进行部署时需要依赖的对象的名称以及依赖的对象的版本信息发送给规则管理平台，具体的可以通过发送规则校验请求，该校验请求中携带应用在本地进行部署时需要依赖的对象的名称以及依赖的对象的版本信息，规则管理平台接收规则校验请求中携带的上述信息。

作为一个例子，当应用在应用服务器进行部署时，通过部署脚本准备相应的依赖的对象，这里依赖的对象可以是jdk、可执行jar文件、mysql数据库等，并通过部署脚本对可执行jar文件进行编译连接，其中可执行jar文件可以包含java开源的编译文件class集合，也可以包含用户自主开发和维护的编译文件class集合，在经过上述步骤之后，部署脚本采集应用在应用服务器部署时需要依赖的对象的名称，即jdk、可执行jar文件名称、mysql等，以及依赖的对象的版本信息，即jdk8、可执行jar文件的版本1.0.2、mysql数据库的版本5.1.52等，在采集完上述信息之后，上报给应用服务器，由应用服务器将上述信息发送给规则管理平台，规则管理平台接收上述信息。

值得注意的是，本说明书实施例中通过部署脚本采集应用在本地进行部署时需要依赖的对象的名称以及依赖的对象的版本信息，并将采集的上述信息上报给应用服务器，由应用服务器将上述信息发送给规则管理平台，具体对于通过部署脚本采集应用在本地进行部署时需要依赖的对象的名称以及依赖的对象的版本信息，这只是其中一种采集依赖的对象的名称以及依赖的对象的版本信息的实现方式，本说明书实施例只是对其中一种实现方式进行举例说明，并不是对如何采集进行限定。

s202，规则管理平台在配置的依赖规则中，查找与所述名称相匹配的依赖规则；

规则管理平台在接收到应用服务器发送的应用在应用服务器进行部署时需要依赖的对象的名称以及依赖的对象的版本信息之后，在配置的依赖规则中，查找与依赖的对象的名称相匹配的依赖规则。这里配置的依赖规则，即在规则管理平台内实时配置的依赖规则，作为一个例子，在规则管理平台内，可以实时配置底层运行环境软件的依赖规则，如对于依赖的jdk，实时配置的依赖规则可以是应用部署时依赖的jdk为jdk8，而不能为jdk7及以下的版本，可以实时配置可执行jar文件的依赖规则，如对于依赖的可执行jar文件，实时配置的依赖规则可以是应用部署时依赖的可执行jar文件的版本为1.0.3，而不能是1.0.2以下的版本。

其中为了避免随意在规则管理平台内实时配置依赖规则，在规则管理平台内提供了具有角色管理能力的超级管理员、管理员和观察者等，超级管理员可以随意配置规则管理平台内的依赖规则，管理员可以配置自己添加的依赖规则，观察者只能查看规则管理平台内的依赖规则，而不能配置规则管理平台内的依赖规则。

在查找与依赖的对象的名称相匹配的依赖规则的过程中，常规的查找方法是基于关键字查找，作为一个例子，查找与jdk相匹配的依赖规则，可以以jdk作为关键字，在配置的依赖规则中，查找存在关键字jdk的依赖规则，进而判断是否与jdk相匹配。

值得注意的是，本说明书实施例对其中一种查找依赖规则的实现方式进行举例说明，并不是限定如何查找依赖规则。

s203，规则管理平台根据查找到的依赖规则对所述版本信息进行校验；

规则管理平台在查找到与依赖的对象的名称相匹配的依赖规则之后，根据查找到的依赖规则对依赖的对象的版本信息进行校验，这里校验指的是判断依赖的对象的版本信息是否满足依赖规则，作为一个例子，查找到与jdk相匹配的依赖规则，此依赖规则为应用部署时依赖的jdk为jdk8，而不能为jdk7及以下的版本，依赖的对象的版本信息为jdk7，则可以判断依赖的对象的版本信息不满足依赖规则，意味着校验失败。

其中，规则管理平台在根据查找到的依赖规则对依赖的对象的版本信息进行校验之前，判断应用是否在预设的白名单内，该白名单用于免除规则校验。对于一些特殊场景，为了使某些应用服务器或者应用免除规则的校验，在规则管理平台内预先设置白名单，在白名单内的应用或者应用服务器可以免除规则校验。

另外，规则管理平台在根据查找到的依赖规则对依赖的对象的版本信息进行校验之前，判断所查找到的依赖规则是否满足预设的要求。在规则管理平台内实时配置的依赖规则，可以为其设置生命周期，即在依赖规则的生命周期内，该依赖规则有效，作为一个例子，在规则管理平台内实时配置的依赖规则，在10天内有效，这里判断所查找到的依赖规则是否满足预设的要求可以是判断所查找到的依赖规则的当前存在时间是否在其预设的有效生命周期内。当然，在规则管理平台内实时配置的依赖规则，还可以配置其生效的起始时间，意味着在配置完成依赖规则之后，经过一段时间该依赖规则才会生效，作为一个例子，在某一天配置完成依赖规则，配置其生效的起始时间为10天之后，意味着10天之后该依赖规则才会生效，这里判断所查找到的依赖规则是否满足预设的要求可以是判断当前时间是否在为所查找到的依赖规则预先配置的生效的起始时间之后。

规则管理平台在根据查找到的依赖规则对依赖的对象的版本信息进行校验之前，可以只判断如上述所说的其中一种，当然也可以先判断应用是否在预设的白名单内，若否，则进一步判断所查找到的依赖规则是否满足预设的要求，或者先判断所查找到的依赖规则是否满足预设的要求，若是，进一步判断应用是否在预设的白名单内。其中，先判断应用是否在预设的白名单内，若否，则进一步判断所查找到的依赖规则是否满足预设的要求，为本说明书实施例的优选实施例。

s204，规则管理平台将校验结果发送至应用服务器；

规则管理平台在根据所查找到的依赖规则对依赖的对象的版本信息进行校验之后，将校验结果发送至应用服务器。其中若校验成功时，则意味着应用在应用服务器进行部署时依赖的对象满足依赖规则；若校验失败时，则意味着应用在应用服务器进行部署时依赖的对象不满足依赖规则，在校验结果中会携带具体的校验失败信息，作为一个例子，具体的校验失败信息可以是jdk版本太低，不满足依赖规则。

s205，应用服务器接收所述校验结果，在所述校验结果为成功的情况下，进行应用部署。

规则管理平台在将校验结果发送至应用服务器之后，应用服务器接收该校验结果，在该校验结果为成功的情况下，继续执行部署脚本，利用部署脚本部署应用，并启动应用。在该校验结果为失败的情况下，终止应用部署，并且根据校验结果中携带的失败信息，提示用户对对应的依赖的对象进行处理，作为一个例子，具体的校验失败信息是jdk版本太低，不满足依赖规则，则需要提示用户升级jdk的版本，并提示用户可以升级到哪个版本。在用户对对应的依赖的对象进行处理之后，继续执行应用服务器中的部署脚本，重新执行上述s201至s204的步骤，应用服务器接收校验结果，在校验结果为成功的情况下，应用可以正常的部署并运行起来。

在上述技术方案的基础之上，如图3所示，本说明书实施例还可以包括以下步骤：

s206，规则管理平台对接收到的依赖的对象的名称以及依赖的对象的版本信息进行存储，用于对所述依赖的对象的使用状况和分布状况进行统计。

为了方便对应用部署时依赖的对象的使用状况和分布情况进行统计，规则管理平台在接收到依赖的对象的名称以及依赖的对象的版本信息之后，对接收到的依赖的对象的名称以及依赖的对象的版本信息进行存储。作为一个例子，如图4所示，规则管理平台与三台应用服务器连接，应用1在应用服务器1进行部署时需要依赖jdk9、jar文件1.0.3、mysql5.1.52，应用2在应用服务器2进行部署时需要依赖jdk9、jar文件1.0.3、mysql5.1.52，应用3在应用服务器3进行部署时需要依赖jdk9、jar文件1.0.3、mysql5.1.52，规则管理平台接收每台应用服务器发送的依赖的对象的名称以及依赖的对象的版本信息，并进行存储，以此来统计jdk9、jar文件1.0.3、mysql5.1.52的使用状况和分布状况。

由上述对本说明书实施例的技术方案的描述，当应用在应用服务器进行部署时，规则管理平台接收应用服务器发送的应用部署时需要依赖的对象的名称以及依赖的对象的版本信息，在配置的依赖规则中，规则管理平台查找与依赖的对象的名称相匹配的依赖规则，规则管理平台根据查找到的依赖规则对依赖的对象的版本信息进行校验，并将校验结果发送至应用服务器，应用服务器接收校验结果，在校验结果为成功的情况下，进行应用部署。

应用本说明书实施例提供的技术方案，避免了用户升级扫描插件的操作，可以确保应用部署时需要依赖的对象是正常的对象，如此一来保证了应用在部署后可以正常运行，避免了损失的发生。

相对于上述方法实施例，本说明书实施例还提供一种应用部署装置，应用于规则管理平台，如图5所示，可以包括：接收模块510、规则查找模块520、校验模块530、发送模块540。

接收模块510，用于接收应用服务器发送的在所述应用服务器进行应用部署时需要依赖的对象的名称以及依赖的对象的版本信息；

规则查找模块520，用于在配置的依赖规则中，查找与所述名称相匹配的依赖规则；

校验模块530，用于根据查找到的依赖规则对所述版本信息进行校验；

发送模块540，用于将校验结果发送至应用服务器，以使应用服务器接收所述校验结果，在所述校验结果为成功的情况下，进行应用部署。

本说明书实施例还提供一种应用部署系统，该系统包括：规则管理平台与应用服务器；

规则管理平台接收应用服务器发送的在所述应用服务器进行应用部署时需要依赖的对象的名称以及依赖的对象的版本信息；

规则管理平台在配置的依赖规则中，查找与所述名称相匹配的依赖规则；

规则管理平台根据查找到的依赖规则对所述版本信息进行校验；

规则管理平台将校验结果发送至应用服务器；

应用服务器接收所述校验结果，在所述校验结果为成功的情况下，进行应用部署。

上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

由上述对本说明书实施例的技术方案的描述，当应用在应用服务器进行部署时，规则管理平台接收应用服务器发送的应用部署时需要依赖的对象的名称以及依赖的对象的版本信息，在配置的依赖规则中，规则管理平台查找与依赖的对象的名称相匹配的依赖规则，规则管理平台根据查找到的依赖规则对依赖的对象的版本信息进行校验，并将校验结果发送至应用服务器，应用服务器接收校验结果，在校验结果为成功的情况下，进行应用部署。

应用本说明书实施例提供的技术方案，避免了用户升级扫描插件的操作，可以确保应用部署时需要依赖的对象是正常的对象，如此一来保证了应用在部署后可以正常运行，避免了损失的发生。

本说明书实施例还提供一种计算机设备，如图6所示，该设备可以包括：处理器610、存储器620、输入/输出接口630、通信接口640和总线650。其中处理器610、存储器620、输入/输出接口630和通信接口640通过总线650实现彼此之间在设备内部的通信连接。

处理器610可以采用通用的cpu(centralprocessingunit，中央处理器)、微处理器、应用专用集成电路(applicationspecificintegratedcircuit，asic)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。

存储器620可以采用rom(readonlymemory，只读存储器)、ram(randomaccessmemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器620可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器620中，并由处理器610来调用执行。

输入/输出接口630用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

通信接口640用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如usb、网线等)实现通信，也可以通过无线方式(例如移动网络、wifi、蓝牙等)实现通信。

总线650包括一通路，在设备的各个组件(例如处理器610、存储器620、输入/输出接口630和通信接口640)之间传输信息。

需要说明的是，尽管上述设备仅示出了处理器610、存储器620、输入/输出接口630、通信接口640以及总线650，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。

本说明书实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现前述的应用部署方法。该方法至少包括：

一种应用部署方法，应用于规则管理平台，该方法包括：

接收应用服务器发送的在所述应用服务器进行应用部署时需要依赖的对象的名称以及依赖的对象的版本信息；

在配置的依赖规则中，查找与所述名称相匹配的依赖规则；

根据查找到的依赖规则对所述版本信息进行校验；

将校验结果发送至应用服务器，以使应用服务器接收所述校验结果，在所述校验结果为成功的情况下，进行应用部署。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本说明书实施例可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本说明书实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本说明书实施例各个实施例或者实施例的某些部分所述的方法。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，在实施本说明书实施例方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅是本说明书实施例的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本说明书实施例原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本说明书实施例的保护范围。