CN116661810A - 一种版本发布部署方法、装置、存储介质及设备 - Google Patents

Abstract

本申请实施例提供一种版本发布部署方法、装置、存储介质及设备，该方法中，获取待分布版本的系统需求信息，即指示该待发布版本包含的多个子系统对应的配置内容的信息，之后，根据该系统需求信息，控制各子系统的发布顺序，并确定待生成信息，再以此生成部署策略，从而实现版本发布方案的自动化生成，并且，通过扫描代码以及预先生成的配置策略，自动地对该版本发布方案进行预检查。如此，减少人工干预的情况，提升工作效率，降低时间成本，并且有效地防止生产事故发生，保障发版进程的顺利进行。

Description

一种版本发布部署方法、装置、存储介质及设备

技术领域

本申请涉及代码开发技术领域，具体而言，涉及一种版本发布部署方法、装置、存储介质及设备。

背景技术

在软件开发中，系统部署前开发人员需要编写对应的部署方案，再由运维人员对照部署方案进行实际的发版。如果某个版本开发的需求过多且复杂，比如涉及多个数据库脚本、多个Apollo配置项、内外部的配置添加等的话，人工处理代码版本的发布容易带来操作失误，比如遗漏某个配置等，耗费了很多时间，容易影响软件版本发布进程。

发明内容

本申请的目的在于提供一种版本发布部署方法、装置、存储介质及设备，旨在解决相关技术中存在的人工处理代码版本发布容易带来操作失误，耗费大量时间，影响版本发布进程的问题。

第一方面，本申请提供的一种版本发布部署方法，包括：

获取待发布版本的系统需求信息，所述系统需求信息是指示所述待发布版本包含的多个子系统对应的配置内容的信息；

根据所述系统需求信息，控制各子系统的发布顺序，并确定待生成信息，再根据所述发布顺序和所述待生成信息生成部署策略；

通过扫描代码以及预先生成的配置策略，对所述部署策略进行检测。

在上述实现过程中，获取待分布版本的系统需求信息，即指示该待发布版本包含的多个子系统对应的配置内容的信息，之后，根据该系统需求信息，控制各子系统的发布顺序，并确定待生成信息，再以此生成部署策略，从而实现版本发布方案的自动化生成，并且，通过扫描代码以及预先生成的配置策略，自动地对该版本发布方案进行预检查。如此，减少人工干预的情况，提升工作效率，降低时间成本，并且有效地防止生产事故发生，保障发版进程的顺利进行。

进一步地，在一些实施例中，所述系统需求信息包括所述多个子系统中每个子系统对应的应用编号或系统名称，以及待改造的子系统的配置信息。

在上述实现过程中，通过采集待发布版本包含的多个子系统中每个子系统对应的应用编号或系统名称，以及待改造的子系统的配置信息，为后续实现自动化生成部署方案并进行预检查奠定良好的数据基础。

进一步地，在一些实施例中，所述系统需求信息是基于版本日对接JIRA系统获取到的。

在上述实现过程中，提供一种获取到当前版本对应的系统需求信息的具体方式，即基于版本日来对接JIRA系统。

进一步地，在一些实施例中，所述根据所述系统需求信息，控制各子系统的发布顺序，包括：

根据所述应用编号或系统名称，探测对应代码的依赖关系以及接口的调用关系，基于探测结果配置各子系统的发布顺序。

在上述实现过程中，针对多系统版本，根据APPID或者系统名称进行对应系统的探测，梳理出对应代码的依赖关系以及接口的调用关系，以此控制各子系统的发布顺序，有利于实现版本发布方案的自动化生成及预检查。

进一步地，在一些实施例中，所述待改造的子系统的配置信息包括数据库脚本和Apollo配置项；所述确定待生成信息，包括：

通过所述数据库脚本和Apollo配置项，识别出所述待发布版本的代码改动内容，基于所述代码改动内容获取待生成信息。

在上述实现过程中，针对数据库脚本和Apollo配置项这些经常遗漏的配置内容，结合代码的扫描，识别出此版本的代码改动，以此来获取对应的需要生成的信息，有利于实现版本发布方案的自动化生成及预检查。

进一步地，在一些实施例中，所述通过扫描代码以及预先生成的配置策略，对所述部署策略进行检测，包括：

按照所述部署策略中包含的数据库脚本的顺序点分解成多个检测步骤，根据所述多个检测步骤进行代码扫描，并将预先生成的配置策略与所述部署策略中包含的Apollo配置项进行比对，基于代码扫描结果和比对结果确定所述部署策略是否存在遗漏项。

在上述实现过程中，通过预先生成的配置策略实现针对部署策略的一个比对映射功能，结合代码扫描，检测初步生成的部署策略中是否存在遗漏项，从而有效减少发版时的失误，降低时间成本。

进一步地，在一些实施例中，所述方法还包括：

当检测到所述部署策略存在遗漏项时，输出报警信息。

在上述实现过程中，在检测到部署策略存在遗漏项时，发送报警信息，及时提醒相关人员进行修正，从而防止生产事故发生，减少发版失误带来的损失。

第二方面，本申请提供的一种版本发布部署装置，包括：

获取模块，用于获取待发布版本的系统需求信息，所述系统需求信息是指示所述待发布版本包含的多个子系统对应的配置内容的信息；

生成模块，用于根据所述系统需求信息，控制各子系统的发布顺序，并确定待生成信息，再根据所述发布顺序和所述待生成信息生成部署策略；

检测模块，用于通过扫描代码以及预先生成的配置策略，对所述部署策略进行检测。

第三方面，本申请提供的一种电子设备，包括：存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如第一方面任一项所述的方法的步骤。

第四方面，本申请提供的一种计算机可读存储介质，所述计算机可读存储介质上存储有指令，当所述指令在计算机上运行时，使得所述计算机执行如第一方面任一项所述的方法。

第五方面，本申请提供的一种计算机程序产品，所述计算机程序产品在计算机上运行时，使得计算机执行如第一方面任一项所述的方法。

本申请公开的其他特征和优点将在随后的说明书中阐述，或者，部分特征和优点可以从说明书推知或毫无疑义地确定，或者通过实施本申请公开的上述技术即可得知。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的一种版本发布部署方法的流程图；

图2为本申请实施例提供的一种自动化系统发版的部署方案的工作流程的示意图；

图3为本申请实施例提供的一种版本发布部署装置的框图；

图4为本申请实施例提供的一种电子设备的结构框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

如背景技术记载，相关技术存在着人工处理代码版本发布容易带来操作失误，耗费大量时间，影响版本发布进程的问题。基于此，本申请实施例提供一种版本发布部署方案，以解决上述问题。

接下来对本申请实施例进行介绍：

如图1所示，图1是本申请实施例提供的一种版本发布部署方法的流程图，所述方法可以应用于终端或服务器。该终端可以是各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携式计算机和台式计算机等；该服务器可以是单个服务器，也可以是多个服务器组成的分布式服务器集群。该终端或服务器提供软件版本处理的环境，这一环境包括软件部分和硬件部分，其中，软件部分主要包括操作系统，如Windows、Linux等，硬件部分主要包括计算资源、存储资源等，如CPU(Central Processing Unit，中央处理器)、内存、硬盘等。需要说明的是，该终端/服务器也可以实现成多个软件或软件模块，或者还可以实现成单个软件或软件模块，本申请对此不作限制。

所述方法包括：

在步骤101、获取待发布版本的系统需求信息，所述系统需求信息是指示所述待发布版本包含的多个子系统对应的配置内容的信息；

本实施例方案是一种自动化的部署方案生成机制，其可以实现为一种中间件，如SDK(Software Development Kit，软件开发工具包)或JAR(Java Archive，Java归档)等。本步骤中提到的待发布版本包含多个子系统，也就是说，该待发布版本可以是指需要发布的包含多个子系统的软件系统。例如，在金融科技领域，该待发布版本可以是包含多个业务系统，如客服系统、信贷系统、汽车金融系统等的银行系统。

该系统需求信息指示待发布版本包含的多个子系统对应的配置内容。在一些实施例中，该系统需求信息可以包括多个子系统中每个子系统对应的应用编号或系统名称，以及待改造的子系统的配置信息。也就是说，针对待发布版本的需求进行统计分析，采集到主办系统的APPID(应用编号)或系统名称，指示此版本的改造所涉及的子系统以及相关简要的修改点，回退方案，配置项等信息。通过采集这些信息，为后续自动化生成部署方案并进行预检查奠定良好的数据基础。

进一步地，在一些实施例中，该系统需求信息可以是基于版本日对接JIRA系统获取到的。JIRA系统是一种项目与事物跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。在实际应用中，每个需求通常是通过JIRA系统创建好，然后纳入要发布的对应版本，因此，基于版本日来对接JIRA系统，可以获取到每个版本的需求信息。

在步骤102、根据所述系统需求信息，控制各子系统的发布顺序，并确定待生成信息，再根据所述发布顺序和所述待生成信息生成部署策略；

当系统需要发版时，基于同一业务场景，或者同一大项目下的不同子系统发布的时候对于调用关系、配置值、数据表的依赖可能都有顺序关系，执行的先后顺序，配置发布的先后顺序，或者配置的开关的开启时间顺序等之间都有关联关系，因此，为了梳理相关依赖的顺序关系、执行的先后调用关系以及各自的依赖关系，需要控制各子系统的发布顺序。

在一些实施例中，本步骤中提到的根据所述系统需求信息，控制各子系统的发布顺序可以包括：根据所述应用编号或系统名称，探测对应代码的依赖关系以及接口的调用关系，基于探测结果配置各子系统的发布顺序。也就是说，在实现时，针对多系统版本，根据APPID或者系统名称进行对应系统的探测，探测对应代码的依赖关系，如探测页面、JOB表达式等关键性特征，以判断对应的子系统是前端系统还是后端系统，再根据接口的URL(Uniform Resource Locator，统一资源定位器)调用关系，确定哪个子系统先部署，哪个子系统后部署。例如，探测到A系统和B系统均涉及到同一个ULR，A系统的该URL上添加有注解@feigntclient，B系统的该URL上有@controller注解，可以判定A系统属于数据客户端，B系统属于服务提供方，因而确定B系统需要优先A系统部署，可控制B系统方案顺序规则处于A系统之前。

控制好各子系统的发布顺序后，可以根据采集的系统需求探测对应的其他配置，主要是准确的数据库脚本和Apollo配置项这些经常遗漏的内容，以此来获取需要生成的信息。也就是说，前面提到的待改造的子系统的配置信息可以包括数据库脚本和Apollo配置项。生成数据库项目时，预先部署脚本、数据库对象定义和后期部署脚本合并为一个生成脚本，即数据库脚本，其是用于创建数据库对象的语句的集合；Apollo是一种分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景，而相应地，Apollo配置项就是待发布版本接入Apollo时设置的应用配置。

在一些实施例中，本步骤中提到的确定待生成信息可以包括：通过所述数据库脚本和Apollo配置项，识别出所述待发布版本的代码改动内容，基于所述代码改动内容获取待生成信息。也就是说，结合代码的扫描，比如添加的带版本日的注释，或者根据提交git的版本日期识别出此版本的代码改动，以此来获取对应的需要生成的信息，即提取待发布版本的脚本和配置内容。

确定各子系统的发布顺序和待生成信息后，可以按照该发布顺序，针对提取的脚本和配置内容生成执行时间点，以此生成部署策略。这里的部署策略可以认为是按生成的执行时间点生成的一个模板清单，后续运维开发可以按照该模板清单来执行发版操作。

在步骤103、通过扫描代码以及预先生成的配置策略，对所述部署策略进行检测。

本实施例方案中，在自动化生成代码发布方案，即部署策略后，通过扫描代码以及预先生成的配置策略，自动地对该代码发布方案进行预检查，以实现细节上的填充增补，从而防止生产事故发生，提升工作效率。

在一些实施例中，本步骤可以包括：按照所述部署策略中包含的数据库脚本的顺序点分解成多个检测步骤，根据所述多个检测步骤进行代码扫描，并将预先生成的配置策略与所述部署策略中包含的Apollo配置项进行比对，基于代码扫描结果和比对结果确定所述部署策略是否存在遗漏项。也就是说，配置项内容体现在部署策略中，在实现时，按照数据库脚本的顺序点分解成多步骤，发布的时候根据这些步骤进行预检查，扫描代码，并通过预先生成的配置策略来实现针对部署策略的一个比对映射功能，以此来检查部署策略中是否存在遗漏项。例如，检查对应的属性字段，以检查数据库脚本是否有执行，在检查结果为否时，进行代码扫描检查点，若数据库中没有，而代码中存在新增加的字段，确定存在遗漏项；同样地，针对配置项、开关等，对于事先生成的脚本顺序，若代码扫描结果为不存在配置，确定存在遗漏项。如此，通过自动化地检测，有效减少了发版时的失误，也降低了时间成本。

进一步地，在一些实施例中，上述方法还可以包括：当检测到所述部署策略存在遗漏项时，输出报警信息。也就是说，在检测到部署策略存在遗漏项时，可以通过邮件、短信、客户端消息等方式发送报警信息，以及时提醒相关人员进行修正，从而防止生产事故发生，减少发版失误带来的损失。

本申请实施例，获取待分布版本的系统需求信息，即指示该待发布版本包含的多个子系统对应的配置内容的信息，之后，根据该系统需求信息，控制各子系统的发布顺序，并确定待生成信息，再以此生成部署策略，从而实现版本发布方案的自动化生成，并且，通过扫描代码以及预先生成的配置策略，自动地对该版本发布方案进行预检查。如此，减少人工干预的情况，提升工作效率，降低时间成本，并且有效地防止生产事故发生，保障发版进程的顺利进行。

为了对本申请的方案做更为详细的说明，接下来介绍一具体实施例：

本实施例涉及银行的版本发布部署场景。针对银行的软件系统，如信贷系统、客服系统、金融保险系统等，其版本开发由于涉及多个数据库脚本，多个Apollo配置项等，需求过多而且复杂，因此人工处理时容易遗漏相关的配置管理，而且代码版本的发布过程可能依赖于某些参数值，这些参数值可能只有当天才能申请下来，开发人员时间上很难按照对应的需求产品事先统计好发布的规则方案。这样人工处理代码版本的发布容易带来操作失误，而且耗费时间。基于此，本实施例提供一种自动化系统发版的部署方案，以解决上述问题。

该方案的工作流程如图2所示，其包括：

S201、针对版本的需求进行统计分析；

具体地，由于一般来说，每个需求是通过JIRA创建好，然后纳入每个要发布的对应版本的，因此，基于版本日来对接JIRA系统，可获取到每个版本的需求信息，比如能采集到指示涉及哪些系统的改造的信息、主办系统APPID等，以及一些简要的修改点，回退方案，配置信息等；

S202、根据采集的数据进行智能分析，控制系统的发布顺序；

具体地，由于针对的软件系统涉及多系统，因此根据APPID或者系统名称进行对应的系统探测，以便控制系统部署方案的先后顺序，在实现时，对代码的依赖关系进行探测，比如探测涉及页面、JOB表达式等的关键性特征，以判断对应系统是前端系统还是后端系统；根据接口的URL调用关系进行探测，以便控制哪个系统先部署，哪个后部署，一般采用先后端再前端的顺序进行控制；

S203、根据采集的系统需求探测对应的其他配置；

具体地，这里的其他配置主要是准备的数据库脚本和Apollo配置项等经常遗漏的配置内容；结合代码的扫描，比如添加的带版本日的注释，或者根据提交git的版本日期等识别出此版本的代码改动，以此来获取对应的需要生成的信息；

S204、初步生成部署方案；

具体地，针对S203中提取的脚本和配置的主要内容生成执行点，按照系统的部署时间点生成对应的配置方案，所有的配置等都会基于此版本的部署时间点来提取；例如，一软件系统包括A系统、B系统和C系统这三个子系统，生成的部署方案可以是：6点发布A系统配置，6点半发布B系统，待B系统发布后需要调整A系统的配置值，再发布C系统，以及执行B系统脚本等；

S205、对生成的部署方案进行预检查；

具体地，根据初步生成的部署方案进行细节上的填充增补，按照数据库脚本的顺序点分解成多步骤，发布的时候根据这些步骤进行预检查，扫描代码，比如检查对应的属性字段，以检查数据库脚本是否有执行，在检查结果为否时，进行代码扫描检查点，若数据库中没有，而代码中存在新增加的字段，则输出报警信息进行提醒；同样地，针对配置项、开关等，对于事先生成的脚本顺序，若代码探测的时候发现没有配置，则输出报警信息进行提醒。

本实施例方案，基于代码需求发布单生成发布模块，根据配置的基础参数生成到对应的模块里，进行依赖顺序的组合，同时能自动地对代码发布方案进行预检查。如此，减少人工干预的情况，防止生产事故发生，并且提升工作效率。

与前述方法的实施例相对应，本申请还提供版本发布部署装置及其应用的终端的实施例：

如图3所示，图3是本申请实施例提供的一种版本发布部署装置的框图，包括：

获取模块31，用于获取待发布版本的系统需求信息，所述系统需求信息是指示所述待发布版本包含的多个子系统对应的配置内容的信息；

生成模块32，用于根据所述系统需求信息，控制各子系统的发布顺序，并确定待生成信息，再根据所述发布顺序和所述待生成信息生成部署策略；

检测模块33，用于通过扫描代码以及预先生成的配置策略，对所述部署策略进行检测。

在一些实施例中，上述系统需求信息包括所述多个子系统中每个子系统对应的应用编号或系统名称，以及待改造的子系统的配置信息。

在一些实施例中，上述系统需求信息是基于版本日对接JIRA系统获取到的。

在一些实施例中，上述生成模块32包括控制子模块；

所述控制子模块用于：根据所述应用编号或系统名称，探测对应代码的依赖关系以及接口的调用关系，基于探测结果配置各子系统的发布顺序。

在一些实施例中，上述待改造的子系统的配置信息包括数据库脚本和Apollo配置项；上述生成模块32包括确定子模块；

所述确定子模块用于：通过所述数据库脚本和Apollo配置项，识别出所述待发布版本的代码改动内容，基于所述代码改动内容获取待生成信息。

在一些实施例中，上述检测模块33具体用于：

按照所述部署策略中包含的数据库脚本的顺序点分解成多个检测步骤，根据所述多个检测步骤进行代码扫描，并将预先生成的配置策略与所述部署策略中包含的Apollo配置项进行比对，基于代码扫描结果和比对结果确定所述部署策略是否存在遗漏项。

在一些实施例中，上述装置还包括：

输出模块，用于当检测到所述部署策略存在遗漏项时，输出报警信息。

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

本申请还提供一种电子设备，请参见图4，图4为本申请实施例提供的一种电子设备的结构框图。电子设备可以包括处理器410、通信接口420、存储器430和至少一个通信总线440。其中，通信总线440用于实现这些组件直接的连接通信。其中，本申请实施例中电子设备的通信接口420用于与其他节点设备进行信令或数据的通信。处理器410可以是一种集成电路芯片，具有信号的处理能力。

上述的处理器410可以是通用处理器，包括中央处理器(CPU，Central ProcessingUnit)、网络处理器(NP，Network Processor)等；还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器410也可以是任何常规的处理器等。

存储器430可以是，但不限于，随机存取存储器(RAM，Random Access Memory)，只读存储器(ROM，Read Only Memory)，可编程只读存储器(PROM，Programmable Read-OnlyMemory)，可擦除只读存储器(EPROM，Erasable Programmable Read-Only Memory)，电可擦除只读存储器(EEPROM，Electric Erasable Programmable Read-Only Memory)等。存储器430中存储有计算机可读取指令，当所述计算机可读取指令由所述处理器410执行时，电子设备可以执行上述图1或图2方法实施例涉及的各个步骤。

可选地，电子设备还可以包括存储控制器、输入输出单元。

所述存储器430、存储控制器、处理器410、外设接口、输入输出单元各元件相互之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可通过一条或多条通信总线440实现电性连接。所述处理器410用于执行存储器430中存储的可执行模块，例如电子设备包括的软件功能模块或计算机程序。

输入输出单元用于提供给用户创建任务以及为该任务创建启动可选时段或预设执行时间以实现用户与服务器的交互。所述输入输出单元可以是，但不限于，鼠标和键盘等。

可以理解，图4所示的结构仅为示意，所述电子设备还可包括比图4中所示更多或者更少的组件，或者具有与图4所示不同的配置。图4中所示的各组件可以采用硬件、软件或其组合实现。

本申请实施例还提供一种存储介质，所述存储介质上存储有指令，当所述指令在计算机上运行时，所述计算机程序被处理器执行时实现方法实施例所述的方法，为避免重复，此处不再赘述。

本申请还提供一种计算机程序产品，所述计算机程序产品在计算机上运行时，使得计算机执行方法实施例所述的方法。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

Claims (10)

1.一种版本发布部署方法，其特征在于，包括：

获取待发布版本的系统需求信息，所述系统需求信息是指示所述待发布版本包含的多个子系统对应的配置内容的信息；

根据所述系统需求信息，控制各子系统的发布顺序，并确定待生成信息，再根据所述发布顺序和所述待生成信息生成部署策略；

通过扫描代码以及预先生成的配置策略，对所述部署策略进行检测。

2.根据权利要求1所述的方法，其特征在于，所述系统需求信息包括所述多个子系统中每个子系统对应的应用编号或系统名称，以及待改造的子系统的配置信息。

3.根据权利要求2所述的方法，其特征在于，所述系统需求信息是基于版本日对接JIRA系统获取到的。

4.根据权利要求2所述的方法，其特征在于，所述根据所述系统需求信息，控制各子系统的发布顺序，包括：

根据所述应用编号或系统名称，探测对应代码的依赖关系以及接口的调用关系，基于探测结果配置各子系统的发布顺序。

5.根据权利要求2所述的方法，其特征在于，所述待改造的子系统的配置信息包括数据库脚本和Apollo配置项；所述确定待生成信息，包括：

通过所述数据库脚本和Apollo配置项，识别出所述待发布版本的代码改动内容，基于所述代码改动内容获取待生成信息。

6.根据权利要求5所述的方法，其特征在于，所述通过扫描代码以及预先生成的配置策略，对所述部署策略进行检测，包括：

按照所述部署策略中包含的数据库脚本的顺序点分解成多个检测步骤，根据所述多个检测步骤进行代码扫描，并将预先生成的配置策略与所述部署策略中包含的Apollo配置项进行比对，基于代码扫描结果和比对结果确定所述部署策略是否存在遗漏项。

7.根据权利要求6所述的方法，其特征在于，所述方法还包括：

当检测到所述部署策略存在遗漏项时，输出报警信息。

8.一种版本发布部署装置，其特征在于，包括：

获取模块，用于获取待发布版本的系统需求信息，所述系统需求信息是指示所述待发布版本包含的多个子系统对应的配置内容的信息；

生成模块，用于根据所述系统需求信息，控制各子系统的发布顺序，并确定待生成信息，再根据所述发布顺序和所述待生成信息生成部署策略；

检测模块，用于通过扫描代码以及预先生成的配置策略，对所述部署策略进行检测。

9.一种计算机可读存储介质，其特征在于，其上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述的方法。

10.一种电子设备，其特征在于，包括处理器、存储器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述计算机程序时实现如权利要求1至7任一项所述的方法。