升级方法、系统、可读存储介质与流程

1.本发明涉及软件升级技术领域，尤其涉及一种升级软件的容器版本的技术。


背景技术：

2.在软件领域中，软件指运行业务逻辑代码的可执行二进制包，容器指作用于上述软件的一种元软件，所述软件运行在所述容器。
3.现有技术中的软件升级，往往侧重于对软件本身版本的升级，当新的容器发布后，则需要开发者人工手动对软件所依赖的容器进行升级，使软件运行在新版本容器上，使用新版本容器的相应功能，此方案升级效率低。


技术实现要素：

4.本发明针对现有技术中的需要人工手动对各软件进行容器版本升级的缺点，提供了升级技术，能够自动判定是否能进行容器版本升级，并在判定能进行容器版本升级时自动升级并发布，加快升级效率。
5.为了解决上述技术问题，本发明通过下述技术方案得以解决：
6.一种升级方法，包括以下步骤：
7.获取待升级软件的依赖数据，获得第一依赖数据，待升级软件指需要对容器版本进行升级的软件；
8.基于目标容器对待升级软件进行容器版本升级，生成测试软件；
9.获取测试软件的依赖数据，获得第二依赖数据；
10.将所述第一依赖数据与所述第二依赖数据相比对，比对成功时，对所述测试软件进行回归测试，获得测试结果，当测试结果为通过时，发布所述测试软件。
11.当比对失败或测试不通过时表示待升级软件与目标容器不适配，此时放弃升级，避免影响软件的正常运行。
12.本申请实际用于自动筛选能够进行容器版本升级的软件，并对其进行容器版本升级后发布。
13.作为一种可实施方式：
14.当监听到所述目标容器进行版本变更时，基于预设的拉取规则拉取版本变更前发布的业务软件，将所得业务软件作为待升级软件。
15.作为一种可实施方式：
16.获取目标软件，提取所述目标软件的容器版本；
17.获取目标容器的版本，当其高于所述容器版本时，判定所述目标软件为待升级软件。
18.作为一种可实施方式：
19.获取待发布软件，基于所述待发布软件获得目标软件。
20.作为一种可实施方式，获取待升级软件的依赖数据，获得第一依赖数据后还包括
依赖变更检测步骤，具体步骤为：
21.获取待升级软件所对应的历史测试软件，当历史测试软件的容器版本与目标容器的版本一致时，提取所述历史测试软件的依赖数据，获得第三依赖数据；
22.基于所述第三依赖数据与所述第一依赖数据判断待升级软件的依赖是否发生变更，当未发生变更时，获取历史测试软件的测试结果；
23.当历史测试软件的测试结果为测试通过时，待升级软件基于目标容器进行容器版本升级，生成升级软件并发布。
24.作为一种可实施方式：
25.第一依赖数据包括至少一个第一依赖组件及其版号；
26.第二依赖数据包括至少一个第二依赖组件及其版号；
27.当第一依赖组件缺少与其相对应的第二依赖组件、或第一依赖组件的版号大于相对应的第二依赖组件的版号时，判定比对失败。
28.本发明还提出一种升级系统，包括：
29.第一获取模块，用于获取待升级软件的依赖数据，获得第一依赖数据；
30.升级模块，用于基于目标容器对待升级软件进行容器版本升级，生成测试软件；
31.第二获取模块，还用于获取测试软件的依赖数据，获得第二依赖数据；
32.验证模块，用于将所述第一依赖数据与所述第二依赖数据相比对，比对成功时，对所述测试软件进行回归测试，获得测试结果，当测试结果为通过时，发布所述测试软件。
33.作为一种可实施方式，还包括触发模块，其包括第一触发单元和第二触发单元；
34.所述第一触发单元，用于当监听到所述目标容器进行版本变更时，基于预设的拉取规则拉取版本变更前发布的业务软件，将所得业务软件作为待升级软件；
35.所述第二触发单元，用于获取目标软件，提取所述目标软件的容器版本，还用于获取目标容器的版本，当其高于所述容器版本时，判定所述目标软件为待升级软件。
36.作为一种可实施方式，还包括变更检测模块，其包括：
37.提取单元，用于获取待升级软件所对应的历史测试软件，当历史测试软件的容器版本与目标容器的版本一致时，提取所述历史测试软件的依赖数据，获得第三依赖数据；
38.检测单元，用于基于所述第三依赖数据与所述第一依赖数据判断待升级软件的依赖是否发生变更，当未发生变更时，获取历史测试软件的测试结果；
39.升级单元，当历史测试软件的测试结果为测试通过时，待升级软件基于目标容器进行容器版本升级，生成升级软件并发布。
40.本发明还提出一种可读存储介质，其存储有计算机程序，该程序被处理器执行时实现上述任意一项所述方法的步骤。
41.本发明由于采用了以上技术方案，具有显著的技术效果：
42.本发明通过比对第一依赖数据和第二依赖数据，从而知悉软件进行容器升级后的依赖变更情况，以检测能够进行容器版本升级的软件，还对升级后的测试软件进行回归测试，对其逻辑正确性进行校验，以保证软件的质量。
43.本发明能够对目标容器的版本升级前所发布的业务软件进行容器版本的升级，使其容器版本能及时升级至最新版本。
44.本发明能够在软件日常迭代过程中自动、无感的进行容器升级，升级效率高。
45.本发明能够利用测试软件及相应的测试结果作为下一次升级过程中的参考依据，从而避免重复的比对和测试，加快升级速度。
附图说明
46.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
47.图1是实施例1所公开升级方法的工作流程示意图；
48.图2是实施例2所公开升级方法的工作流程示意图；
49.图3是实施例3所公开升级系统的模块连接示意图；
50.图4是实施例4所公开升级系统的模块连接示意图。
具体实施方式
51.下面结合实施例对本发明做进一步的详细说明，以下实施例是对本发明的解释而本发明并不局限于以下实施例。
52.实施例1、一种升级方法，包括以下步骤：
53.s100、获取待升级软件的依赖数据，获得第一依赖数据；
54.待升级软件特指需要对容器版本进行升级的业务软件；
55.s200、基于目标容器对待升级软件进行容器版本升级，生成测试软件；
56.目标容器指最新版本的容器；
57.s300、获取测试软件的依赖数据，获得第二依赖数据；
58.s400、将所述第一依赖数据与所述第二依赖数据相比对，比对成功时，对所述测试软件进行回归测试，获得测试结果，当测试结果为通过时，发布所述测试软件。
59.当步骤s400中对比失败或测试结果为不通过时，直接发布待升级软件。
60.在实际使用过程中，可将s400中产生的比对数据和测试数据反馈给对应开发者，以便于开发者基于比对数据和测试数据对其软件的代码进行优化，使其于目标容器相适配。
61.以java软件为例，使用容器对其封装，使其运行在容器之中，容器通过maven管理组件库依赖，maven是一个项目管理工具，其包含依赖管理系统(dependency management system)。java软件对容器的版本很敏感，因为，容器版本的变化，意味着所有组件库依赖版本的变化，这可能会导致java软件的运行出现问题。随着容器版本的升级，其将增加新功能，java软件如果想使用上述新功能，就必须升级其所依赖的容器版本；
62.对软件所依赖的容器版本进行升级，不只是对容器的版本号进行修改，容器的版本变更将导致组件库依赖版本变更，从而导致java软件所依赖的组件间接升级、降级、甚至缺失，进而出现jar包冲突导致对应java软件无法启动或正常运行。
63.由于无法提前预知jar包冲突，故现今在新的容器版本发布后，由开发者手工修改该软件所依赖的容器版本，获得容器版本升级后的软件，并对容器版本升级后的软件进行运行，以检测是否存在jar包冲突，当运行正常时发布该软件(容器版本升级后的软件)，否
则发布原软件(容器版本升级后的软件)，后续开发者可根据jar包冲突情况对软件进行优化升级，使其能够在更新后的容器框架中正常运行。
64.由上可知，现今人工对软件所对应的容器版本进行升级的方案需要开发者对其软件进行一一检测，基于检测结果为软件进行容器版本升级，效率低，人工成本高，且无法快速、稳定、正确的推进新版本容器在软件中的应用，
65.本实施例通过比对第一依赖数据和第二依赖数据，从而知悉软件进行容器升级后的依赖变更情况，当第一依赖数据与对应第二依赖数据相适配时，初步确定对容器版本进行升级；本实施例还对容器版本升级后的软件(即测试软件)进行回归测试，对其逻辑正确性进行校验，以保证软件的质量。
66.进一步地，待升级软件的获取方法包括以下两种方式：
67.方法1：当监听到所述目标容器进行版本变更时，基于预设的拉取规则拉取版本变更前发布的业务软件，将所得业务软件作为待升级软件，如图1监听触发部分所示。
68.目标容器为最新版本的容器，其版本发生变化，表示有新版本的容器进行发布；对目标容器的版本变化进行监听，此为现有技术，本领域技术人员可基于现有已公开的mqtt技术监听容器的新版本发布实现，故不对其进行详细介绍；
69.本领域技术人员可根据实际需要自行设置拉取规则，如拉取最近发布的10个软件或拉取一天内发布的软件。
70.方法2：从目标软件中获取待升级软件：
71.提取所述目标软件的版本数据，所述版本数据包括容器版本，即，目标软件所依赖的容器的版本；
72.获取目标容器的版本，即最新容器的版本，当其高于所述容器版本时，表示目标软件所依赖的容器的版本交底，需要进行容器版本升级，判定所述目标软件为待升级软件。
73.目标软件可以为用户手动选择需要升级的软件，或待发布软件，本实施例中将待发布软件作为目标软件。
74.如图1虚线部分所示，基于用户的操作对业务软件进行发布时，本实施例所提出的升级方法被触发，此时将待发布的业务软件作为目标软件按照上述步骤进行容器版本升级。
75.在实际使用过程中，可拦截待发布的业务软件进行容器版本升级后进行发布，还可备份待发布的业务软件，获得相应的备份软件，对原业务软件执行发布操作，对备份软件，将其作为目标软件进行容器版本升级，直至其容器版本升级成功进行发布后，以升级容器版本的测试软件更新原业务软件，即，在自动、无感的对业务软件进行容器版本升级时，不影响原业务软件的发布，避免因升级用时过长(如回归测试用时较长)，对业务软件的发布造成影响。
76.在实际使用过程中，本领域技术人员可选择上述任意一种方法获取待升级软件，或同时采用上述两种方法获取待升级软件。
77.实施例2、其在实施例1的基础上增加依赖变更检测步骤，即，于实施例1中步骤s100和步骤200之间增加步骤a依赖变更检测步骤，其余均等同于实施例1，步骤a依赖变更检测步骤具体为：
78.a1、获取待升级软件所对应的历史测试软件，当历史测试软件的容器版本与目标
容器的版本一致时，提取所述历史测试软件的依赖数据，获得第三依赖数据；
79.历史测试软件为对应软件在先的测试软件。
80.历史测试软件可为空，历史测试软件为空时，判定版本不一致；
81.当版本不一致时，跳过依赖变更检测步骤，执行步骤s200，按照实施例1中步骤s200至步骤s400进行升级。
82.a2、基于所述第三依赖数据与所述第一依赖数据判断待升级软件的依赖是否发生变更，当未发生变更时，获取历史测试软件的测试结果；
83.将待升级软件基于目标容器进行容器版本升级后发布，否则，执行步骤s200，按照实施例1中步骤s200至步骤s400进行升级。
84.a3、当历史测试软件的测试结果为测试通过时，待升级软件基于目标容器进行容器版本升级，生成升级软件并发布。
85.当历史测试软件的容器版本与目标容器的容器版本一致时，且当所述第三依赖数据与所述第一依赖数据一致时，历史测试软件的测试结果可以作为是否升级待升级软件的容器版本的依据，在历史测试软件的测试结果为测试通过时，待升级软件所对应的测试软件也将测试通过，故可直接将待升级软件基于目标容器进行容器版本升级，同理，历史测试软件的测试结果为测试不通过时，亦可直接判定不进行升级，直接发布待升级软件。
86.本实施例通过对依赖变更检测步骤的设计，当待升级软件所对应的依赖未发生变化，且其历史版本所对应的软件执行过步骤s200至步骤s400时，无需在本次升级过程中重复进行依赖比对和回归测试等步骤，大大解决升级时间。
87.进一步地：
88.第一依赖数据包括至少一个第一依赖组件及其版号；
89.第二依赖数据包括至少一个第二依赖组件及其版号；
90.当第一依赖组件缺少与其相对应的第二依赖组件、或第一依赖组件的版号大于相对应的第二依赖组件的版号时，判定比对失败。
91.即，步骤s400中，目标容器的依赖数据相对于待升级软件的依赖数据存在组件版本缺失、降级等情况时，则认为如升级容器版本将会出现无法启动或正常运行的情况，此时判定比对失败，反之，如果没有出现组件版本缺失、降级等情况，即可认为可以进行版本升级，此时判定比对成功。
92.依赖组件间的对比属于现有技术，本领域技术人员知悉相比对的依赖组件的获取方式即可轻易实现，故本实施例中不对具体的比对步骤进行详细介绍。
93.本实施例中，步骤s400对所述测试软件进行回归测试，获得测试结果的具体步骤为：利用jenkins(现有已公开的开源自动化服务器)执行回归测试，获得相应的测试数据，所述测试数据包括覆盖率和成功率。
94.获取预设的合格覆盖率和合格成功率，当覆盖率大于等于合格覆盖率，且成功率大于等于合格成功率，判定测试通过，否则，判定测试不通过。
95.以一个具体的案例对本实施例所公开的升级方法进行详细介绍：
96.1、发布容器新版本：
97.发布x2版本的容器后，其为最新版本的容器，故将其作为目标容器；
98.此时监听到目标容器版本的变化，按照预设的拉取规则从devops平台中拉取最近
发布的10个不同的业务软件，将所得业务软件作为待升级软件；
99.依次对各待升级软件进行以下容器框架升级，以升级一个待升级软件的容器框架为例进行详细介绍：
100.获取所述待升级软件的maven依赖数据，获得相应的第一依赖数据，maven依赖数据为组件版本的数组集合。
101.对所述待升级软件的容器版本进行修改，如将其由x1更改为x2，获得相应的测试软件，实现对待升级软件的容器版本升级，本案例中基于dom操作maven xml配置文件自动实现获取测试软件的maven依赖数据，获得相应的第二依赖数据，本案例中通过执行mvn dependency list命令实现对该maven依赖数据的获取。
102.对上述两个maven依赖数据进行比较，即，比较所述第一依赖数据和所述第二依赖数据，如果出现所依赖的组件版本降级或缺失的情况，放弃升级，否则，对测试软件执行回归测试，本实施例中自动将测试软件提交jenkins执行回归测试。
103.获得相应的覆盖率和合格率，当覆盖率大于等于合格覆盖率，且成功率大于等于合格成功率，判定测试通过，否则，判定测试不通过。
104.测试通过时，向相应的decops平台发布测试软件，完成对容器框架的升级。
105.本案例中还将所得测试软件更新历史测试软件，并记录其测试结果，以便于对应业务软件下一次容器升级时进行依赖变更检测。
106.2、发布软件：
107.参照图2，图2中实线流程表示软件按照时间顺序进行迭代的过程，虚线流程表示开发者发布新版本的软件时，对该软件的容器框架进行升级的过程。
108.开发人员向decops平台发布日常迭代的软件，触发本实施例所提出的升级步骤，例如可按照以下步骤进行升级：
109.执行发布步骤，备份并发布待发布软件，获得备份软件；
110.获取备份软件的容器版本，并将其与目标容器的版本进行对比，如容器版本和目标容器的版本均为x2时，终止升级步骤，参照图2，a软件的容器版本为x1，小于目标容器的版本x2时，继续升级步骤。
111.实际中软件具有软件编号、软件版本和容器版本；基于软件编号查询该软件所对应历史测试软件，并获取历史测试软件的容器版本；
112.当历史测试软件的容器版本与目标容器的版本不一致时，如开发者发布的a软件的软件版本v1时，其无历史测试软件，缺少可供参考的测试结果，故按照步骤s200至步骤s400所公开的步骤进行升级，发布测试通过时的测试软件；
113.如历史测试软件的容器版本为x1，小于目标容器的版本x2，其并不能为备份软件的容器版本升级到x2提供参考，故需生成容器版本为x2的测试软件，重新进行依赖比对和回归测试，并将所生成的测试软件作为历史测试软件，为下一次升级提供参考。
114.当历史测试软件的容器版本与目标容器的版本一致时，获取历史测试软件和备份容器的依赖数据，并将所得依赖数据进行比对，当两个软件的依赖数据一致时，说明其依赖并未发生变更，此时依赖数据一致，所要升级的容器版本相符，故历史测试软件的测试结果能够给当前升级以参考，故当历史测试的测试结果为通过时，可直接将备份软件的容器版本修改至目标容器的版本，实现对容器版本的升级。
115.如图2中开发者发布软件版本为v2，容器版本为x1的软件时，其需要进行容器升级，由于历史测试软件(软件版本v1、容器版本x2)已经通过测试，此时软件版本v1与软件版本v2的依赖数据没有发生变化，即可直接参考历史测试软件的测试结果，修改该软件的容器版本，生成相应的升级软件后发布。
116.综上，本实施例所公开的升级方法能够在软件日常迭代过程中自动、无感的进行容器升级，升级效率高，能够快速、稳定、正确的推进容器在业务代码中的应用，即，将最新的技术成果快速应用到生产环境，提高开发者的效率和应用程序的性能；
117.软件日常迭代具有一定的间隔时长，当目标容器的版本发生变化前刚发布的业务软件不会在短时间内进行升级更新，导致其无法及时应用新版本的容器，本实施例通过对拉取规则的设计，在目标容器进行版本变更时，不仅对后续需发布的业务软件进行容器版本的升级，还对目标容器的版本升级前所发布的业务软件进行容器版本的升级，使其容器版本能及时升级至最新版本。
118.实施例3、一种升级系统，如图3所示，包括：
119.第一获取模块100，用于获取待升级软件的依赖数据，获得第一依赖数据；
120.升级模块200，用于基于目标容器对待升级软件进行容器版本升级，生成测试软件；
121.第二获取模块300，还用于获取测试软件的依赖数据，获得第二依赖数据；
122.验证模块400，用于将所述第一依赖数据与所述第二依赖数据相比对，比对成功时，对所述测试软件进行回归测试，获得测试结果，当测试结果为通过时，发布所述测试软件。
123.进一步地，还包括触发模块500，其包括第一触发单元和第二触发单元；
124.所述第一触发单元，用于当监听到所述目标容器进行版本变更时，基于预设的拉取规则拉取版本变更前发布的业务软件，将所得业务软件作为待升级软件；
125.所述第二触发单元，用于获取目标软件，提取所述目标软件的容器版本，还用于获取目标容器的版本，当其高于所述容器版本时，判定所述目标软件为待升级软件。
126.本实施例为实施例1所对应的装置实施例，由于其与实施例1基本相似，所以描述的比较简单，相关之处参见实施例1的部分说明即可。
127.实施例4、如图4所示，在实施例3的基础上增加变更检测模块600，其余均等同于实施例3；
128.变更检测模块600包括：
129.提取单元，用于获取待升级软件所对应的历史测试软件，当历史测试软件的容器版本与目标容器的版本一致时，提取所述历史测试软件的依赖数据，获得第三依赖数据；
130.检测单元，用于基于所述第三依赖数据与所述第一依赖数据判断待升级软件的依赖是否发生变更，当未发生变更时，获取历史测试软件的测试结果；
131.升级单元，当历史测试软件的测试结果为测试通过时，待升级软件基于目标容器进行容器版本升级，生成升级软件并发布。
132.本实施例为实施例2所对应的装置实施例，由于其与实施例1基本相似，所以描述的比较简单，相关之处参见实施例2的部分说明即可。
133.实施例5、一种可读存储介质，其存储有计算机程序，该程序被处理器执行时实现
实施例1或实施例2任意一项所述方法的步骤。
134.本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。
135.本领域内的技术人员应明白，本发明的实施例可提供为方法、装置、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd
‑
rom、光学存储器等)上实施的计算机程序产品的形式。
136.本发明是参照根据本发明的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
137.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
138.这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
139.需要说明的是：
140.说明书中提到的“一个实施例”或“实施例”意指结合实施例描述的特定特征、结构或特性包括在本发明的至少一个实施例中。因此，说明书通篇各个地方出现的短语“一个实施例”或“实施例”并不一定均指同一个实施例。
141.尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。
142.此外，需要说明的是，本说明书中所描述的具体实施例，其功能模块所取名称等可以不同。凡依本发明专利构思所述的构造、特征及原理所做的等效或简单变化，均包括于本发明专利的保护范围内。本发明所属技术领域的技术人员可以对所描述的具体实施例做各种各样的修改或补充或采用类似的方式替代，只要不偏离本发明的结构或者超越本权利要求书所定义的范围，均应属于本发明的保护范围。