CN115454483A - 一种跨版本的版本更新方法和相关装置 - Google Patents

Abstract

本申请公开了一种跨版本的版本更新方法和相关装置，可应用于分布式领域或金融领域。获取多个增量版本的多个版本包。获取多个增量版本间的依赖关系，该依赖关系用于描述多个版本包更新的先后顺序。根据依赖关系合并多个版本包包括的更新内容，得到合并版本内容。停止业务系统的服务，并备份基线版本，基于合并版本内容和基线版本实现多个增量版本的更新。由此，通过将多个版本包包括的内容预先进行合并，得到合并版本内容，再基于合并版本内容进行统一的版本更新，无需为每个版本建立部署任务，避免重复操作等问题，降低了时间成本和人工操作风险，大幅度提升自动化部署效率，缩短了投产变更窗口，进而降低了业务系统的维护时间。

Description

一种跨版本的版本更新方法和相关装置

技术领域

本发明涉及计算机技术领域，尤其是涉及一种跨版本的版本更新方法和相关装置。

背景技术

随着移动互联网的发展和智能终端的普及，计算机系统早就从单服务器独立工作过渡到多服务器协作，包括多台服务器的集群按照分布式理论构建出庞大复杂的应用服务。对于集群中每台服务器的版本更新，一般是在投产变更窗口中，通过手工部署的方式为服务器部署更新后的版本。

但是，在全流程敏捷开发模式下，开发团队交付速率提升，每两周或者一个月就会交付一个生产版本，导致生产版本较多。而且，每年的投产变更窗口有限，经常会出现一次投产变更窗口需要更新一个业务产品的多个版本包，依次为每个版本建立部署任务，会导致重复操作等问题，进而导致投产变更窗口变长，业务系统的维护时间较长。

发明内容

针对上述问题，本申请提供一种跨版本的版本更新方法和相关装置，用于在一个自动化部署任务下完成多个增量版本的部署的情况下，降低重复操作，避免投产变更窗口变长。

基于此，本申请实施例公开了如下技术方案：

一方面，本申请实施例提供一种跨版本的版本更新方法，所述方法包括：

获取多个增量版本的多个版本包，所述增量版本的版本包包括更新内容；

获取所述多个增量版本间的依赖关系，所述依赖关系用于描述所述多个版本包更新的先后顺序；

根据所述依赖关系合并所述多个版本包包括的更新内容，得到合并版本内容；

停止业务系统的服务，并备份基线版本的版本包，所述基线版本是基于所述依赖关系获得的；

基于所述合并版本内容和所述基线版本实现所述多个增量版本的更新。

可选的，所述增量版本的版本包还包括新增文件清单和旧文件删除清单；所述根据所述依赖关系合并所述多个版本包包括的更新内容，得到合并版本内容，包括：

获取所述多个版本包分别包括的新增文件清单和旧文件删除清单；

基于所述依赖关系，将所述多个版本包中除最后一个版本包外的所有版本包顺序依次作为第一版本包，执行迭代操作，所述迭代操作包括：将所述第一版本包包括的旧文件删除清单增加至初始旧文件删除清单；对比所述初始旧文件删除清单和第二版本包包括的新增文件清单，得到目标文件的标识，从所述初始旧文件删除清单中删除所述目标文件的标识，得到更新后的初始旧文件删除清单；所述目标文件的标识用于标识在所述初始旧文件删除清单中且在所述第二版本包括的新增文件清单中的文件，所述第二版本包是所述第一版本包的下一个版本包；

将所述最后一个版本包包括的旧文件删除清单增加至所述初始旧文件删除清单，得到目标旧文件删除清单；

根据所述目标旧文件删除清单和所述多个版本包包括的更新内容，得到合并版本内容。

可选的，所述根据所述依赖关系合并所述多个版本包包括的更新内容，得到合并版本内容，包括：

根据所述依赖关系依次解压所述多个版本包包括的更新内容到所述业务系统的部署目录下，并在所述部署目录下合并解压后的所述多个版本包得到合并版本内容。

可选的，所述根据所述依赖关系合并所述多个版本包包括的更新内容，得到合并版本内容，包括：

根据所述依赖关系依次解压所述多个版本包包括的更新内容到预设目录下，并在所述预设目录下合并解压后的所述多个版本包得到合并版本内容；

所述基于所述合并版本内容实现所述多个增量版本的更新，包括：

从所述预设目标下获取所述合并版本内容；

将所述合并版本内容部署至所述业务系统的部署目录下，以基于所述合并版本内容实现所述多个增量版本的更新。

可选的，所述获取所述多个增量版本间的依赖关系，包括：

从数据库或文件中获取所述多个增量版本间的依赖关系。

可选的，所述获取所述多个增量版本间的依赖关系，包括：

获取所述多个增量版本的依赖版本标识；

根据所述多个增量版本的依赖版本标识确定所述多个增量版本间的依赖关系。

另一方面，本申请提供了一种跨版本的版本更新装置，所述装置包括：第一获取单元、第二获取单元、合并单元、准备单元和更新单元；

所述第一获取单元，用于获取多个增量版本的多个版本包，所述增量版本的版本包包括更新内容；

所述第二获取单元，用于获取所述多个增量版本间的依赖关系，所述依赖关系用于描述所述多个版本包更新的先后顺序；

所述合并单元，用于根据所述依赖关系合并所述多个版本包包括的更新内容，得到合并版本内容；

所述准备单元，用于停止业务系统的服务，并备份基线版本的版本包，所述基线版本是基于所述依赖关系获得的；

所述更新单元，用于基于所述合并版本内容和所述基线版本实现所述多个增量版本的更新。

可选的，所述增量版本的版本包还包括新增文件清单和旧文件删除清单；所述合并单元，具体用于：

获取所述多个版本包分别包括的新增文件清单和旧文件删除清单；

基于所述依赖关系，将所述多个版本包中除最后一个版本包外的所有版本包顺序依次作为第一版本包，执行迭代操作，所述迭代操作包括：将所述第一版本包包括的旧文件删除清单增加至初始旧文件删除清单；对比所述初始旧文件删除清单和第二版本包包括的新增文件清单，得到目标文件的标识，从所述初始旧文件删除清单中删除所述目标文件的标识，得到更新后的初始旧文件删除清单；所述目标文件的标识用于标识在所述初始旧文件删除清单中且在所述第二版本包括的新增文件清单中的文件，所述第二版本包是所述第一版本包的下一个版本包；

将所述最后一个版本包包括的旧文件删除清单增加至所述初始旧文件删除清单，得到目标旧文件删除清单；

根据所述目标旧文件删除清单和所述多个版本包包括的更新内容，得到合并版本内容。

可选的，所述合并单元，具体用于：

根据所述依赖关系依次解压所述多个版本包包括的更新内容到所述业务系统的部署目录下，并在所述部署目录下合并解压后的所述多个版本包得到合并版本内容。

可选的，所述合并单元，具体用于：

根据所述依赖关系依次解压所述多个版本包包括的更新内容到预设目录下，并在所述预设目录下合并解压后的所述多个版本包得到合并版本内容；

所述基于所述合并版本内容实现所述多个增量版本的更新，包括：

从所述预设目标下获取所述合并版本内容；

将所述合并版本内容部署至所述业务系统的部署目录下，以基于所述合并版本内容实现所述多个增量版本的更新。

可选的，所述第二获取单元，具体用于：

从数据库或文件中获取所述多个增量版本间的依赖关系。

可选的，所述第二获取单元，具体用于：

获取所述多个增量版本的依赖版本标识；

根据所述多个增量版本的依赖版本标识确定所述多个增量版本间的依赖关系。

另一方面，本申请提供了一种计算机设备，所述设备包括处理器以及存储器：

所述存储器用于存储程序代码，并将所述程序代码传输给所述处理器；

所述处理器用于根据所述程序代码中的指令执行上述方面所述的方法。

另一方面本申请提供了一种计算机可读存储介质，所述计算机可读存储介质用于存储计算机程序，所述计算机程序用于执行上述方面所述的方法。

另一方面，本申请实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述方面所述的方法。

相对于现有技术，本申请上述技术方案的优点在于：

获取多个增量版本的多个版本包，该多个增量版本的多个版本包对应于本次更新对应的变更窗口中需要更新的多个更新内容。获取多个增量版本间的依赖关系，该依赖关系用于描述多个版本包更新的先后顺序。根据依赖关系合并多个版本包包括的更新内容，得到合并版本内容。停止业务系统的服务，并备份基线版本，基于合并版本内容和基线版本实现多个增量版本的更新。由此，通过将多个版本包包括的内容预先进行合并，得到合并版本内容，再基于合并版本内容进行统一的版本更新，无需为每个版本建立部署任务，避免复操作等问题，降低了时间成本和人工操作风险，大幅度提升自动化部署效率，缩短了投产变更窗口，进而降低了业务系统的维护时间。

附图说明

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

图1为本申请提供的一种跨版本的版本更新方法的流程图；

图2为本申请提供的一种跨版本的版本更新方法的示意图；

图3为本申请提供的一种跨版本的版本更新装置的示意图；

图4为本申请实施例提供的一种计算机设备的结构图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

为了后续更好的说明，下面先对本申请实施例涉及的专业术语进行说明。

(1)全量版本：指版本包中包含该应用服务的所有内容，无论本次是否修改。

(2)增量版本：指版本包是基于已经在生产环境运行的应用版本或者已经正式发布的增量版本对应的全量版本(已发布，但是未部署到生产环境)的增量内容，只包含修改的内容，未修改内容不在增量版本内。

(3)依赖版本：指版本包的部署需要依赖的前一个版本包的标识，依照依赖版本可以识别出增量版本的依赖关系。

(4)基线版本：指当前生产环境已经升级到的应用版本号，每次部署新的增量版本，该基线都会随之更新。

(5)版本合并：指将多个增量版本按照依赖关系，合并为一个版本包进行生产环境变更，将原本需要多次的变更操作减少为一次变更，有效提升自动化部署效率。

(6)部署：指通过一系列操作，完成应用版本到生产环境的更新工作。主要涉及服务的启停、版本备份、客户化参数、新版本部署以及失败后的版本回退等流程。

(7)生产环境：指银行对外部客户提供金融服务的环境。

(8)部署目录：每个应用版本的执行码在生产环境的服务器上放置的文件目录。

下面结合图1，对本申请实施例提供的一种跨版本的版本更新方法进行介绍。参见图1，该图是本申请提供的一种跨版本的版本更新方法的流程图，该方法可以包括以下步骤101-105。

S101：获取多个增量版本的多个版本包。

在一次投产变更窗口中，会更新多个增量版本的版本包，获取在一个自动化部署任务下(即一次投产变更窗口中)需要更新的多个增量版本分别对应的版本包。

其中，增量版本的版本包包括更新内容，更新内容是增量版本在依赖版本基础上进行更新的内容。

S102：获取多个增量版本间的依赖关系。

其中，依赖关系用于描述多个版本包更新的先后顺序，例如，基线版本的标识为XXX_SP01，三个增量版本的标识可以分别为XXX_SP02、XXX_SP03和XXX_SP04。由此，可以看出，三个增量版本的依赖关系是先基于XXX_SP02的版本包进行更新，然后基于XXX_SP03的版本包进行更新，最后基于XXX_SP04的版本包进行更新。

作为一种可能的实现方式，在编写增量版本时，可以为多个增量版本赋予具有更新顺序关系的标识，从而可以获取多个增量版本的版本标识；根据多个增量版本的版本标识确定多个增量版本间的依赖关系。其中，依赖版本标识用于标识增量版本对应的依赖版本。由上述可知，XXX_SP02、XXX_SP03和XXX_SP04具有依赖关系。

作为一种可能的实现方式，可以预先将多个增量版本间的依赖关系存储至数据库或文件中，以便从数据库或文件中获取多个增量版本间的依赖关系。其中，数据库可以为MySQL数据库、关系型数据库Oracle、非关系型数据库Elasticsearch等具备存储记录信息功能的数据库，文件可以为件txt、缓存Redis等具备存储记录信息功能的文件，本申请对数据库和文件不做具体限定。

S103：根据依赖关系合并多个版本包包括的更新内容，得到合并版本内容。

由于第一次更新可能删除文件2.java，在第二次更新又新增了文件2.java，两次更新虽然文件的名字一样，但可能内容不一样，若颠倒了两次更新的顺序，可能会删除第二次更新所需的文件2.java，基于此，可以根据依赖关系合并多个版本包包括的更新内容，得到合并版本内容。

作为一种可能的实现方式，可以根据依赖关系依次解压多个版本包包括的更新内容到业务系统的部署目录下，并在部署目录下合并解压后的多个版本包得到合并版本内容。由此，可以直接将每个增量版本的更新内容直接部署到部署目录下，在部署目录下完成合并，从而可以直接在部署目录下实现版本更新。

作为一种可能的实现方式，可以根据依赖关系依次解压多个版本包包括的更新内容到预设目录下，并在预设目录下合并解压后的多个版本包得到合并版本内容。以便后续可以从预设目标下获取合并版本内容，并将合并版本内容部署至业务系统的部署目录下，以基于合并版本内容实现多个增量版本的更新。其中，预设目录可以是非部署目录的任一存储位置。例如，依次解压XXX_SP02、XXX_SP03、XXX_SP04到预设目录下，初步合并三个版本包的内容，得到合并版本内容，并将合并版本内容部署到部署目录下。由此，先将多个版本在临时工作目录(预设目录)合并完成后，再部署到部署目录下，可以节省多个增量版本的版本包合并的时间，进一步加快更新的时间。

S104：停止业务系统的服务，并备份基线版本的版本包。

其中，基线版本是基于依赖关系获得的。停止业务系统的服务，以便进行后续更新，为基线版本的版本包进行备份，以便后续进行回溯等操作。

S105：基于合并版本内容和基线版本实现多个增量版本的更新。

由此，可以在基线版本的版本包的基础上，利用合并版本内容进行更新，进而实现多个增量版本的更新。从而，完成多个版本包的自动合并和客户化，降低了时间成本和人工操作风险，大幅度提升自动化部署效率，降低了对外停业时间窗口。

由上述技术方案可知，获取多个增量版本的多个版本包，该多个增量版本的多个版本包对应于本次更新对应的变更窗口中需要更新的多个更新内容。获取多个增量版本间的依赖关系，该依赖关系用于描述多个版本包更新的先后顺序。根据依赖关系合并多个版本包包括的更新内容，得到合并版本内容。停止业务系统的服务，并备份基线版本，基于合并版本内容和基线版本实现多个增量版本的更新。由此，通过将多个版本包包括的内容预先进行合并，得到合并版本内容，再基于合并版本内容进行统一的版本更新，无需为每个版本建立部署任务，避免复操作等问题，降低了时间成本和人工操作风险，大幅度提升自动化部署效率，缩短了投产变更窗口，进而降低了业务系统的维护时间。

作为一种可能的实现方式，本申请实施例提供一种S103，即根据依赖关系合并多个版本包包括的更新内容，得到合并版本内容的具体实施方式，具体参见S1031-S1034。

S1031：获取多个版本包分别包括的新增文件清单和旧文件删除清单。

需要和说明的是，版本包除了包括更新内容，还包括新增文件清单和旧文件删除清单。故可以获取多个版本包分别包括的新增文件和旧文件删除清单。作为一种可能的实现方式，将依赖关系、新增文件清单和删除文件清单分开三个文件存储。作为一种可能的实现方式，还可以采用其他存储介质存储或者采用同一个文件存储上述信息。本申请对此不做具体限定。

其中，新增文件中包括在依赖版本的版本包的基础上新增的内容以及修改的内容。旧文件删除清单包括在依赖版本的版本包的基础上删除的内容。

S1032：基于依赖关系，将多个版本包中除最后一个版本包外的所有版本包顺序依次作为第一版本包，执行迭代操作，所述迭代操作包括：将第一版本包包括的旧文件删除清单增加至初始旧文件删除清单；对比初始旧文件删除清单和第二版本包包括的新增文件清单，得到目标文件的标识，从初始旧文件删除清单中删除目标文件的标识，得到更新后的初始旧文件删除清单。

其中，目标文件的标识用于标识在所述初始旧文件删除清单中且在所述第二版本包括的新增文件清单中的文件，第二版本包是所述第一版本包的下一个版本包。下面举例进行说明。

根据依赖关系，能够确定出多个新增文件清单和旧文件删除清单之间的顺序关系。从而进行多次迭代。

第一次：将第1个版本包包括的旧文件删除清单作为初始旧文件删除清单，将初始旧文件删除清单与第2个版本包包括的新增文件清单比较，得到目标文件的标识，即在初始旧文件删除清单中执行删除操作并在第二版本包包括的新增文件清单中执行新增操作的、且属于第二版本包包括的新增文件清单的文件。将目标文件从初始旧文件删除清单中删除，得到更新后的初始旧文件删除清单。

第二次：将第2个版本包括的旧文件删除清单增加至初始旧文件删除清单(即前述更新后的初始旧文件删除清单)，比较初始旧文件删除清单与第3个版本包包括的新增文件清单，得到目标文件的标识，从初始旧文件删除清单中删除目标文件的标识，得到更新后的初始旧文件删除清单。

直至多个版本包中倒数第二个版本包作为第一版本包，得到更新后的初始旧文件删除清单。例如，若包括n个版本包，则需要迭代n-1次。

例如，XXX_SP02中删除文件2.java，XXX_SP04中新增文件2.java，则文件2.java为目标文件。

S1033：将最后一个版本包包括的旧文件删除清单增加至初始旧文件删除清单，得到目标旧文件删除清单。

继续以前述为例，将第n个版本包包括的旧文件删除清单增加至n-1次迭代完成后得到的初始旧文件删除清单，从而得到目标旧文件删除清单。

由于目标文件先执行删除操作，后执行新增操作，若混淆顺序，会导致文件删除错误，从而导致更新出错。故可以找到目标文件，将其才能够初始旧文件清单中删除，得到目标旧文件删除清单。

由此，通过完成多个版本包中的旧文件删除清单和新增文件清单的自动对比和整合，依次解析每个增量版本包中的旧文件删除清单和新增文件清单，通过对比此次待部署增量版本中的旧文件删除清单和新增文件清单，去除掉先删除后又增加的文件(目标文件)，避免多删文件的情况。最终，形成本次部署任务需要删除的目标旧文件删除清单。作为一种可能的实现方式，目标旧文件删除清单可以为delete.txt。从而确保精确删除旧文件，保证不误删新增文件。实现了在保证精准度的前提下，提升版本合并后的旧文件清理效率。

S1034：根据目标旧文件删除清单和多个版本包包括的更新内容，得到合并版本内容。

将多个版本包包括的更新内容进行合并后，并从中删除目标旧文件删除清单中包括的文件，得到合并版本内容。

由此，本申请实施例支持在一个自动化部署任务中实施多个增量版本的部署工作，最大程度上降低人工重复操作复杂度，降低人工操作风险，提升自动化部署效率。

为了使本申请实施例提供的技术方案更加清楚，下面结合图2以一个实例对本申请实施例提供的跨版本的版本更新方法进行说明。

在图2中，基线版本XXX_SP01包括的内容为文件1.java、文件2.java、文件3.java和文件Config.property。增量版本XXX_SP02在基线版本的基础上，修改了文件1.java，以及删除了文件2.java。增量版本XXX_SP03在基线版本的基础上，修改了文件3.java和文件Config.property，以及新增了文件Test.log。增量版本XXX_SP04在基线版本的基础上，修改了文件1.java和文件Config.property，新增了文件2.java，以及删除了文件3.java。

相关技术中，可能会采用以下两种方式进行版本更新。

方案一：依次为每个增量版本的版本包创建部署任务，执行多次自动部署操作。

方案二：采用手工合并版本的方式，将多个增量版本手工完成合并和客户化，通过自动分发系统，完成版本的分发部署。

但是上述方案存在以下问题：

1.重复执行多个部署流程，存在重复操作，部署耗时成倍增长。

2.需要人工干预，导致自动化部署流程中断。

3.人工干预时，存在手工操作失误的风险，并且需要人工干预，自动部署效率较低。

基于此，本申请实施例提供了一种基于依赖关系进行自动合并的方式。具体参见S1-S7。

S1：获取XXX_SP02的版本包、XXX_SP03的版本包和XXX_SP04的版本包。

增量版本的版本包中包括更新内容，还可以包括以下标识文件：依赖版本清单、新增文件清单和旧文件删除清单。上述三个标识文件都是基于依赖版本的全量版本包生成的，用于标识此次增量版本包针对现有的依赖版本的所有变更内容和依赖关系。

S2：获取多个增量版本XXX_SP02、XXX_SP03和XXX_SP04间的依赖关系，即依次更新XXX_SP02、XXX_SP03和XXX_SP04。

本次投产变更窗口中涉及的软件包都上传到自动化部署系统中，系统中可以展示出各个增量版本的依赖关系。创建自动化部署任务时，可以选择最新的增量版本。比如：目前基线版本为XXX_SP01，本次共涉及XXX_SP02、XXX_SP03、XXX_SP04三个增量版本包，选择XXX_SP04作为最新的增量版本即可。作为一种可能的实现方式，还可以选择XXX_SP03作为最新的增量版本，则此次投产变更窗口中不更新XXX_SP04版本。

S3：基于依赖关系，将多个版本包中除最后一个版本包外的所有版本包顺序依次作为第一版本包，执行迭代操作，所述迭代操作包括：将第一版本包包括的旧文件删除清单增加至初始旧文件删除清单；对比初始旧文件删除清单和第二版本包包括的新增文件清单，得到目标文件的标识，从初始旧文件删除清单中删除目标文件的标识，得到更新后的初始旧文件删除清单。

S4：将最后一个版本包包括的旧文件删除清单增加至初始旧文件删除清单，得到目标旧文件删除清单。

根据图2可以得到目标文件为XXX_SP02。

S5：根据目标旧文件删除清单和多个版本包包括的更新内容，得到合并版本内容。

继续以图2为例，得到的合并版本内容为修改文件1.java、文件2.java和文件Config.property，删除文件3.java，新增文件Test.log。

具体地，S3-S7的步骤可以在部署目录下执行，即根据版本包的依赖关系，依次解压XXX_SP02、XXX_SP03、XXX_SP04到部署目录下，依次解析每个增量版本包中的旧文件删除清单和新增文件清单，通过对比此次待部署增量版本中的旧文件删除清单和新增文件清单，去除掉先删除后又增加的文件，避免多删文件的情况。最终，形成本次部署任务需要删除的目标新增文件清单。

S6：停止业务系统的服务，并备份基线版本的版本包。

S7：将合并版本内容部署到业务系统的部署目录下，基于合并版本内容和基线版本实现多个增量版本的更新。

至此，完成了一个部署任务部署多个增量版本的操作，并保证旧文件可以准确清理。

本申请实施例除了提供的跨版本的版本更新方法外，还提供了跨版本的版本更新装置，如图3所示，所述装置包括：第一获取单元301、第二获取单元302、合并单元303、准备单元304和更新单元305；

所述第一获取单元301，用于获取多个增量版本的多个版本包，所述增量版本的版本包包括更新内容；

所述第二获取单元302，用于获取所述多个增量版本间的依赖关系，所述依赖关系用于描述所述多个版本包更新的先后顺序；

所述合并单元303，用于根据所述依赖关系合并所述多个版本包包括的更新内容，得到合并版本内容；

所述准备单元304，用于停止业务系统的服务，并备份基线版本的版本包，所述基线版本是基于所述依赖关系获得的；

所述更新单元305，用于基于所述合并版本内容和所述基线版本实现所述多个增量版本的更新。

作为一种可能的实现方式，所述增量版本的版本包还包括新增文件清单和旧文件删除清单；所述合并单元303，具体用于：

获取所述多个版本包分别包括的新增文件清单和旧文件删除清单；

基于所述依赖关系，将所述多个版本包中除最后一个版本包外的所有版本包顺序依次作为第一版本包，执行以下步骤：

将所述第一版本包包括的旧文件删除清单增加至初始旧文件删除清单；对比所述初始旧文件删除清单和第二版本包包括的新增文件清单，得到目标文件的标识，从所述初始旧文件删除清单中删除所述目标文件的标识，得到更新后的初始旧文件删除清单；所述目标文件的标识用于标识在所述初始旧文件删除清单中且在所述第二版本包括的新增文件清单中的文件，所述第二版本包是所述第一版本包的下一个版本包；

将所述最后一个版本包包括的旧文件删除清单增加至所述初始旧文件删除清单，得到目标旧文件删除清单；

根据所述目标旧文件删除清单和所述多个版本包包括的更新内容，得到合并版本内容。

作为一种可能的实现方式，所述合并单元303，具体用于：

根据所述依赖关系依次解压所述多个版本包包括的更新内容到所述业务系统的部署目录下，并在所述部署目录下合并解压后的所述多个版本包得到合并版本内容。

作为一种可能的实现方式，所述合并单元303，具体用于：

根据所述依赖关系依次解压所述多个版本包包括的更新内容到预设目录下，并在所述预设目录下合并解压后的所述多个版本包得到合并版本内容；

所述基于所述合并版本内容实现所述多个增量版本的更新，包括：

从所述预设目标下获取所述合并版本内容；

将所述合并版本内容部署至所述业务系统的部署目录下，以基于所述合并版本内容实现所述多个增量版本的更新。

作为一种可能的实现方式，所述第二获取单元302，具体用于：

从数据库或文件中获取所述多个增量版本间的依赖关系。

作为一种可能的实现方式，所述第二获取单元302，具体用于：

获取所述多个增量版本的依赖版本标识；

根据所述多个增量版本的依赖版本标识确定所述多个增量版本间的依赖关系。

由上述技术方案可知，获取多个增量版本的多个版本包，该多个增量版本的多个版本包对应于本次更新对应的变更窗口中需要更新的多个更新内容。获取多个增量版本间的依赖关系，该依赖关系用于描述多个版本包更新的先后顺序。根据依赖关系合并多个版本包包括的更新内容，得到合并版本内容。停止业务系统的服务，并备份基线版本，基于合并版本内容和基线版本实现多个增量版本的更新。由此，通过将多个版本包包括的内容预先进行合并，得到合并版本内容，再基于合并版本内容进行统一的版本更新，无需为每个版本建立部署任务，避免复操作等问题，降低了时间成本和人工操作风险，大幅度提升自动化部署效率，缩短了投产变更窗口，进而降低了业务系统的维护时间。

本申请实施例还提供了一种计算机设备，参见图4，该图示出了本申请实施例提供的一种计算机设备的结构图，如图4所示，所述设备包括处理器410以及存储器420：

所述存储器410用于存储程序代码，并将所述程序代码传输给所述处理器；

所述处理器420用于根据所述程序代码中的指令执行上述实施例提供的任一种跨版本的版本更新方法。

本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质用于存储计算机程序，所述计算机程序于执行上述实施例提供的任一种跨版本的版本更新方法。

本申请实施例还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述方面的各种可选实现方式中提供的跨版本的版本更新方法。

需要说明的是，本发明提供的一种跨版本的版本更新方法和相关装置可用于分布式领域或金融领域。上述仅为示例，并不对本发明提供的一种跨版本的版本更新方法和相关装置的应用领域进行限定。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“对应于”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

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

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

Claims (10)

1.一种跨版本的版本更新方法，其特征在于，所述方法包括：

获取多个增量版本的多个版本包，所述增量版本的版本包包括更新内容；

获取所述多个增量版本间的依赖关系，所述依赖关系用于描述所述多个版本包更新的先后顺序；

根据所述依赖关系合并所述多个版本包包括的更新内容，得到合并版本内容；

停止业务系统的服务，并备份基线版本的版本包，所述基线版本是基于所述依赖关系获得的；

基于所述合并版本内容和所述基线版本实现所述多个增量版本的更新。

2.根据权利要求1所述的方法，其特征在于，所述增量版本的版本包还包括新增文件清单和旧文件删除清单；所述根据所述依赖关系合并所述多个版本包包括的更新内容，得到合并版本内容，包括：

获取所述多个版本包分别包括的新增文件清单和旧文件删除清单；

基于所述依赖关系，将所述多个版本包中除最后一个版本包外的所有版本包顺序依次作为第一版本包，执行迭代操作，所述迭代操作包括：将所述第一版本包包括的旧文件删除清单增加至初始旧文件删除清单；对比所述初始旧文件删除清单和第二版本包包括的新增文件清单，得到目标文件的标识，从所述初始旧文件删除清单中删除所述目标文件的标识，得到更新后的初始旧文件删除清单；所述目标文件的标识用于标识在所述初始旧文件删除清单中且在所述第二版本包括的新增文件清单中的文件，所述第二版本包是所述第一版本包的下一个版本包；

将所述最后一个版本包包括的旧文件删除清单增加至所述初始旧文件删除清单，得到目标旧文件删除清单；

根据所述目标旧文件删除清单和所述多个版本包包括的更新内容，得到合并版本内容。

3.根据权利要求1所述的方法，其特征在于，所述根据所述依赖关系合并所述多个版本包包括的更新内容，得到合并版本内容，包括：

根据所述依赖关系依次解压所述多个版本包包括的更新内容到所述业务系统的部署目录下，并在所述部署目录下合并解压后的所述多个版本包得到合并版本内容。

4.根据权利要求1所述的方法，其特征在于，所述根据所述依赖关系合并所述多个版本包包括的更新内容，得到合并版本内容，包括：

根据所述依赖关系依次解压所述多个版本包包括的更新内容到预设目录下，并在所述预设目录下合并解压后的所述多个版本包得到合并版本内容；

所述基于所述合并版本内容实现所述多个增量版本的更新，包括：

从所述预设目标下获取所述合并版本内容；

将所述合并版本内容部署至所述业务系统的部署目录下，以基于所述合并版本内容实现所述多个增量版本的更新。

5.根据权利要求1所述的方法，其特征在于，所述获取所述多个增量版本间的依赖关系，包括：

从数据库或文件中获取所述多个增量版本间的依赖关系。

6.根据权利要求1所述的方法，其特征在于，所述获取所述多个增量版本间的依赖关系，包括：

获取所述多个增量版本的依赖版本标识；

根据所述多个增量版本的依赖版本标识确定所述多个增量版本间的依赖关系。

7.一种跨版本的版本更新装置，其特征在于，所述装置包括：第一获取单元、第二获取单元、合并单元、准备单元和更新单元；

所述第一获取单元，用于获取多个增量版本的多个版本包，所述增量版本的版本包包括更新内容；

所述第二获取单元，用于获取所述多个增量版本间的依赖关系，所述依赖关系用于描述所述多个版本包更新的先后顺序；

所述合并单元，用于根据所述依赖关系合并所述多个版本包包括的更新内容，得到合并版本内容；

所述准备单元，用于停止业务系统的服务，并备份基线版本的版本包，所述基线版本是基于所述依赖关系获得的；

所述更新单元，用于基于所述合并版本内容和所述基线版本实现所述多个增量版本的更新。

8.一种计算机设备，其特征在于，所述设备包括处理器以及存储器：

所述存储器用于存储程序代码，并将所述程序代码传输给所述处理器；

所述处理器用于根据所述程序代码中的指令执行权利要求1-6任意一项所述的方法。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质用于存储计算机程序，所述计算机程序用于执行权利要求1-6任意一项所述的方法。

10.一种计算机程序产品，其特征在于，包括计算机程序或指令；当所述计算机程序或指令被处理器执行时，执行权利要求1-6任意一项所述的方法。

Images