CN115309426A - 系统升级方法、装置、计算机设备及计算机可读存储介质 - Google Patents

Abstract

本申请适用于互联网技术及数字医疗领域，公开了一种系统升级方法、装置、计算机设备及计算机可读存储介质，涉及互联网领域，通过改善系统升级流程，能够在提高系统功能验证力度的同时，采用预设插件脚本对多个分支代码进行多次打包，节省了打包时间，进而降低系统上线的时间成本。所述方法包括：响应于使用方触发打包命令，拉取多个分支代码，多个分支代码为打包命令指示的目标系统对应的多个旧版本代码；基于预设插件脚本，对多个分支代码进行代码升级，并打包多个分支代码，得到目标文件；推送目标文件至目标系统下部署，抽查验证目标文件在目标系统中升级的系统功能；当验证结果指示系统功能运行正常时，完成对目标系统的升级。

Description

系统升级方法、装置、计算机设备及计算机可读存储介质

技术领域

本申请涉及互联网技术及数字医疗领域，特别是涉及一种系统升级方法、装置、计算机设备及计算机可读存储介质。

背景技术

随着互联网技术的不断发展，互联网公司需要运营维护少则几十个系统，多则成百上千个系统。当系统出现漏洞事件，如log4j的漏洞事件、spring的漏洞事件、fastjson漏洞事件，会对公司造成一定程度的影响。

相关技术中，对于修复漏洞这种极高安全漏洞系数的事件，需要做到快速修改并验证上线的，开发人员通过拉取分支、修改代码升级jar包版本号、提交代码、打包代码、部署新包、测试验证、预发验证、灰度引流、经历这一系列的流程最终全部上线。

在实现本申请的过程中，申请人发现相关技术至少存在以下问题：

由于系统数量过多，系统升级上线流程过长，即使进行小部分的代码修改，也需要经历上述全部流程内容，花费至少1-2天的时间才能够成功上线，导致整个系统升级的效率低、速度慢。

发明内容

有鉴于此，本申请提供了一种系统升级方法、装置、计算机设备及计算机可读存储介质，主要目的在于解决目前系统数量过多，打包部署上线流程过长，即使进行小部分的代码修改，也需要经历上述全部流程内容，花费至少1-2天的时间才能够成功上线，导致整个漏洞修复的修复效率低、速度慢的问题。

依据本申请第一方面，提供了一种系统升级方法，该方法包括：

响应于使用方触发打包命令，拉取多个分支代码，所述多个分支代码为所述打包命令指示的目标系统对应的多个旧版本代码；

基于预设插件脚本，对所述多个分支代码进行代码升级，并打包所述多个分支代码，得到目标文件；

推送所述目标文件至所述目标系统下部署，抽查验证所述目标文件在所述目标系统中升级的系统功能；

当验证结果指示所述系统功能运行正常时，完成对所述目标系统的升级。

依据本申请第二方面，提供了一种系统升级装置，该装置包括：

拉取模块，用于响应于使用方触发打包命令，拉取多个分支代码，所述多个分支代码为所述打包命令指示的目标系统对应的多个旧版本代码；

打包模块，用于基于预设插件脚本，对所述多个分支代码进行代码升级，并打包所述多个分支代码，得到目标文件；

推送模块，用于推送所述目标文件至所述目标系统下部署，抽查验证所述目标文件在所述目标系统中升级的系统功能；

验证模块，用于当验证结果指示所述系统功能运行正常时，完成对所述目标系统的升级。

依据本申请第三方面，提供了一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现上述第一方面中任一项所述方法的步骤。

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

借由上述技术方案，本申请提供的一种系统升级方法、装置、计算机设备及计算机可读存储介质，本申请首先响应于使用方触发打包命令，拉取多个分支代码。随后，基于预设插件脚本，对多个分支代码进行代码升级，并打包多个分支代码，得到目标文件。接下来，推送目标文件至目标系统下部署，抽查验证目标文件在目标系统中升级的系统功能。当验证结果指示系统功能运行正常时，完成对目标系统的升级。通过采用预设插件脚本的一次触发多次打包的打包机制，对多个分支代码进行打包，生成目标文件后部署至目标系统进行验证，验证目标系统的相关功能，判断目标文件是否成功升级目标系统，既节省了打包时间，降低系统升级的时间成本，又提高了对系统功能的验证力度，间接保证了升级后的版本对系统功能无损无害。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本申请的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本申请实施例提供的一种系统升级方法流程示意图；

图2A示出了本申请实施例提供的一种系统升级方法流程示意图；

图2B示出了本申请实施例提供的一种系统升级方法流程示意图；

图3A示出了本申请实施例提供的一种系统升级装置的结构示意图；

图3B示出了本申请实施例提供的一种系统升级装置的结构示意图；

图4示出了本申请实施例提供的一种计算机设备的装置结构示意图。

具体实施方式

下面将参照附图更详细地描述本申请的示例性实施例。虽然附图中显示了本申请的示例性实施例，然而应当理解，可以以各种形式实现本申请而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本申请，并且能够将本申请的范围完整的传达给本领域的技术人员。

本申请实施例提供了一种系统升级方法，如图1所示，该方法包括：

101、响应于使用方触发打包命令，拉取多个分支代码，多个分支代码为打包命令指示的目标系统对应的多个旧版本代码。

在本申请实施例中，为了能够确定是哪个系统需要升级，本申请由使用方在需要升级的目标系统触发打包命令，由本申请提供的打包平台响应于打包命令，确定目标系统，拉取目标系统的多个分支代码。在具体的实施过程中，本方案可以适用于医疗升级系统，响应于目标医疗子系统发起的打包升级命令，拉取目标医疗子系统的多个分支代码，对目标医疗子系统进行系统升级。需要说明的是，分支代码为目标系统存储的旧版本代码，例如，目标系统每月进行一次代码升级，也就是jar包升级，本次升级为七月份版本升级，此时需要分别拉取六月份、五月份、四月份、三月份、二月份对应的旧版本代码。另外，拉取的数量可以采用打包平台默认的拉取数量，也可以由使用方，即相关工作人员根据实际应用情况进行设置，本申请对分支代码的拉取数量不进行具体限定。

102、基于预设插件脚本，对多个分支代码进行代码升级，并打包多个分支代码，得到目标文件。

在本申请实施例中，考虑到原来一次只能打一个包非常浪费时间，故本申请设置有预设插件脚本fast-upgrade-version.sh。相关工作人员会预先编写好轻量级的预设插件脚本fast-upgrade-version.sh，并将预设插件脚本嵌入到打包环节中。采用预设插件脚本，同时对多个分支代码进行代码升级、打包。最终将打包得到的子目标文件进行聚合，得到目标文件。

103、推送目标文件至目标系统下部署，抽查验证目标文件在目标系统中升级的系统功能。

进一步地，将目标文件推送至目标系统下部署。依旧以目标医疗子系统为例，A目标医疗子系统正在验证【医疗系统工程代码0401分支】的代码，那么预设插件脚本fast-upgrade-version.sh就会拉取【医疗系统工程代码0401分支】最近5个版本的分支代码进行打包，并推送至A目标医疗子系统中去。部署完成后对目标文件进行抽查验证，确定目标文件是否在目标医疗子系统中成功升级对应的系统功能。

104、当验证结果指示系统功能运行正常时，完成对目标系统的升级。

在本申请实施例中，当验证结果指示目标文件运行正常时，说明目标文件升级jar包对目标系统的运行不产生影响，进而可以完成对目标系统的升级。

本申请实施例提供的方法，可以首先响应于使用方触发打包命令，拉取多个分支代码。随后，基于预设插件脚本，对多个分支代码进行代码升级，并打包多个分支代码，得到目标文件。接下来，推送目标文件至目标系统下部署，抽查验证目标文件在目标系统中升级的系统功能。当验证结果指示系统功能运行正常时，完成对目标系统的升级。通过采用预设插件脚本的一次触发多次打包的打包机制，对多个分支代码进行打包，生成目标文件后部署至目标系统进行验证，验证目标系统的相关功能，判断目标文件是否成功升级目标系统，既节省了打包时间，降低系统升级的时间成本，又提高了对系统功能的验证力度，间接保证了升级后的版本对系统功能无损无害。

本申请实施例提供了一种系统升级方法，如图2A所示，该方法包括：

201、响应于使用方在目标系统触发Jenkins打包工具，调用Jenkins打包工具，在预设数据库中拉取多个分支代码。

随着互联网技术的不断发展，互联网公司需要运营维护少则几十个系统，多则成百上千个系统。当系统出现漏洞事件，如log4j的漏洞事件、spring的漏洞事件、fastjson漏洞事件，会对公司造成一定程度的影响。目前，对于修复漏洞这种极高安全漏洞系数的事件，需要做到快速修改并验证上线的，开发人员通过拉取分支、修改代码升级jar包版本号、提交代码、打包代码、部署新包、测试验证、预发验证、灰度引流、经历这一系列的流程最终全部上线。

但是申请人认识到，由于系统数量过多，系统升级上线流程过长，即使进行小部分的代码修改，也需要经历上述全部流程内容，花费至少1-2天的时间才能够成功上线，导致整个系统升级的效率低、速度慢。

因此，本申请提供的一种系统升级方法、装置、计算机设备及计算机可读存储介质，本申请首先响应于使用方触发打包命令，拉取多个分支代码。随后，基于预设插件脚本，对多个分支代码进行代码升级，并打包多个分支代码，得到目标文件。接下来，推送目标文件至目标系统下部署，抽查验证目标文件在目标系统中升级的系统功能。当验证结果指示系统功能运行正常时，完成对目标系统的升级。通过采用预设插件脚本的一次触发多次打包的打包机制，对多个分支代码进行打包，生成目标文件后部署至目标系统进行验证，验证目标系统的相关功能，判断目标文件是否成功升级目标系统，既节省了打包时间，降低系统升级的时间成本，又提高了对系统功能的验证力度，间接保证了升级后的版本对系统功能无损无害。在具体的实施过程中，本方案可以适用于医疗升级系统，响应于目标医疗子系统发起的打包升级命令，拉取目标医疗子系统的多个分支代码进行打包，生成目标文件后部署至目标医疗子系统进行系统升级。

在实际应用过程中，为了能够确定是哪个系统需要升级，本申请由使用方在需要升级的目标系统触发Jenkins打包工具，生成打包命令。打包平台响应于打包命令，确定目标系统，在预设数据库中拉取多个目标系统的分支代码。

具体地，考虑到系统历史升级产生的旧版本代码会被存储至预设数据库，便于后续的查询与回溯，故本申请在预设数据库中读取目标系统对应的全部分支代码。分别读取全部分支代码对应的升级时间，将全部分支代码按照升级时间的先后顺序进行排序。进而确定使用方输入的预设数目，在全部分支代码中，从后向前拉取预设数目的分支代码，得到多个分支代码。

例如，目标系统每月进行一次代码升级，也就是jar包升级，本次升级为七月份版本升级，此时，在预设数据库中读取全部的分支代码，将分支代码按照月份排列成一月版本至六月版本，从后向前分别拉取六月份、五月份、四月份、三月份、二月份对应的分支代码，得到多个分支代码。需要说明的是，分支代码为目标系统存储的旧版本代码，拉取的数量可以采用打包平台默认的拉取数量，也可以由使用方，即相关工作人员根据实际应用情况进行设置，本申请对分支代码的拉取数量不进行具体限定。

通过上述步骤，每个系统都可以单独调用目标打包工具进行系统升级，多个系统并行系统升级，省去了大量的沟通成本和开发人力成本，缩短系统升级时间，提高系统升级效率。

202、获取预设插件脚本，将预设插件脚本嵌入打包工具，采用预设插件脚本对多个分支代码分别进行代码处理，生成多个容器组。

在本申请实施例中，考虑到原来一次只能打一个包非常浪费时间，故本申请设置有预设插件脚本fast-upgrade-version.sh。相关工作人员会预先编写好轻量级的预设插件脚本fast-upgrade-version.sh，并将预设插件脚本嵌入到打包环节中。采用预设插件脚本，利用原来的一次打包触发机制，实现多次打包。具体地，在检测到打包命令后，对多个分支代码进行代码处理，生成多个pod容器组。需要说明的是容器组是Kubernetes中最小的可部署单元，代表了Kubernetes中一个独立的应用程序运行实例，该实例可能由单个容器或者几个紧耦合在一起的容器组成。

203、在每个容器组中查询工程代码，根据预设升级内容，对工程代码进行代码升级并打包，得到目标文件。

进一步地，在每个容器组中查询工程代码，根据预设升级内容，对工程代码进行代码升级并打包，得到目标文件。在实际应用过程中，开发人员可能会对工程代码中的部分代码内容进行修改，此时可以将修改的内容作为预设升级内容。接下来，打包平台在容器组中查询工程代码，读取工程代码中存储的代码内容，确定主pom文件。

在主pom文件中，采用预设升级内容进行代码升级。在可选的实施过程中，打包平台可以根据开发人员输入的地址或指针等能确定代码位置的信息，确定待修改代码的内容，采用预设升级内容对待修改代码内容进行替换，完成代码升级。再修改对应的jar包版本号，触发容器组中设置的打包命令，对分支代码进行打包，得到子目标文件。

通过重复步骤203中描述的升级打包步骤，对多个容器组进行代码修改并打包，得到多个子目标文件，最终，升级系统将多个子目标文件进行聚合，得到目标文件。

204、推送目标文件至目标系统下部署，抽查验证目标文件在目标系统中升级的系统功能，当验证结果指示系统功能运行正常时，执行下述步骤205，当验证结果指示系统功能运行异常时，执行下述步骤206。

接下来，将目标文件推送至目标系统下部署，在部署完成后进入测试抽查验证环节。具体地，在目标系统中确定目标文件升级的系统功能，运行系统功能，以及测试验证系统功能的运行状态，生成验证结果。实际上，在测试抽查验证环节，是由相关测试人员对目标文件升级的jar包进行专门验证。

当验证结果指示目标文件运行正常时，可以认为jar包升级成功，升级的jar包对现有系统功能没有意外的影响，进而完成后续对目标系统的升级流程，也就是执行下述步骤205。

当验证结果指示目标文件运行异常时，生成用于指示升级失败的提示信息，将提示信息发送至展示终端进行展示，以使使用方基于提示信息重新进行系统升级，也就是执行下述步骤206。

205、当验证结果指示目标文件运行正常时，对目标文件升级的系统功能进行预发验证、灰度引流，将目标文件升级的系统功能上线。

若预发验证、灰度引流验证系统功能运行正常，则将目标文件升级的系统功能上线。在实际验证过程中，如果不存在API冲突，利用Jenkins打包+部署后，经过1-2小时的验证无误，基本上就可以进行预发验证、灰度引流、产线发布。前后大概持续2-3小时的时间耗时，极大程度上缩短了系统升级时间，提高了系统升级效率。

另外，若预发验证、灰度引流验证系统功能运行异常，同样生成用于指示升级失败的提示信息。将提示信息发送至展示终端进行展示，以使使用方基于提示信息重新进行系统升级。需要说明的是，展示终端可以是电脑、平板等具备显示功能的设备，本申请对展示终端不进行具体限定。

本申请提供的系统平台能够使几百个系统并行系统升级，几乎不需要开发的介入，省去了大量的沟通成本和开发人力成本，直接测试回归验证无误就可以在短短半天之内将上百个系统发布上线，快速解决安全漏洞问题。

206、当验证结果指示目标文件运行异常时，生成用于指示升级失败的提示信息，将提示信息发送至展示终端进行展示，以使使用方基于提示信息重新进行系统升级。

在本申请实施例中，当验证结果指示目标文件运行异常时，生成用于指示升级失败的提示信息。提示信息可以返回失败原因或仅返回失败结果，本申请对提示信息的内容不进行具体限定。进一步地，将提示信息发送至展示终端进行展示，以使使用方，也就是开发人员在接收到提醒信息后，确定失败原因。在解决相关问题后，重新触发打包工具完成系统升级操作。

综上所述，如图2B所示，本申请提供的方法，可以将每个系统的系统升级请求并行处理，每个系统都要先进入打包部署环节。具体地，在打包部署环节，通过本申请提供的打包平台拉取多个版本的分支代码，生成多个容器组。在每个容器组中查询工程代码，确定工程代码的主pom文件，在主pom文件中进行代码升级。进而触发容器组中的打包命令对每个分支代码进行打包，得到多个子目标文件，将多个子目标文件发送至目标系统进行部署。接下来，进入测试抽查验证环节，对目标系统升级的系统功能进行验证，在验证无误后，进行预发验证、灰度引流直至最终发布上线，完成目标系统的升级。

本申请实施例提供的方法，可以首先响应于使用方触发打包命令，拉取多个分支代码。随后，基于预设插件脚本，对多个分支代码进行代码升级，并打包多个分支代码，得到目标文件。接下来，推送目标文件至目标系统下部署，抽查验证目标文件在目标系统中升级的系统功能。当验证结果指示系统功能运行正常时，完成对目标系统的升级。通过采用预设插件脚本的一次触发多次打包的打包机制，对多个分支代码进行打包，生成目标文件后部署至目标系统进行验证，验证目标系统的相关功能，判断目标文件是否成功升级目标系统，既节省了打包时间，降低系统升级的时间成本，又提高了对系统功能的验证力度，间接保证了升级后的版本对系统功能无损无害。

进一步地，作为图1所述方法的具体实现，本申请实施例提供了一种系统升级装置，如图3A所示，所述装置包括：拉取模块301、打包模块302、推送模块303、验证模块304。

该拉取模块301，用于响应于使用方触发打包命令，拉取多个分支代码，所述多个分支代码为所述打包命令指示的目标系统对应的多个旧版本代码；

该打包模块302，用于基于预设插件脚本，对所述多个分支代码进行代码升级，并打包所述多个分支代码，得到目标文件；

该推送模块303，用于推送所述目标文件至所述目标系统下部署，抽查验证所述目标文件在所述目标系统中升级的系统功能；

该验证模块304，用于当验证结果指示所述系统功能运行正常时，完成对所述目标系统的升级。

在具体的应用场景中，该拉取模块301，用于响应于所述使用方在所述目标系统触发Jenkins打包工具，调用所述Jenkins打包工具，在预设数据库中读取所述目标系统对应的全部分支代码；分别读取所述全部分支代码对应的升级时间，将所述全部分支代码按照所述升级时间的先后顺序进行排序；确定所述使用方输入的预设数目，在所述全部分支代码中，从后向前拉取所述预设数目的分支代码，得到所述多个分支代码。

在具体的应用场景中，该打包模块302，用于获取所述预设插件脚本，将所述预设插件脚本嵌入打包工具；采用所述预设插件脚本对所述多个分支代码分别进行代码处理，生成多个容器组；在每个所述容器组中查询工程代码，根据预设升级内容，对所述工程代码进行代码升级并打包，得到子目标文件；遍历所述多个容器组，对所述多个容器组中的每个容器组进行代码修改并打包，得到多个子目标文件；将所述多个子目标文件进行聚合，得到所述目标文件。

在具体的应用场景中，该打包模块302，用于在所述容器组中查询工程代码，读取所述工程代码中存储的代码内容，确定主pom文件；在所述主pom文件中，采用所述预设升级内容进行代码升级，并修改对应的版本号；触发所述容器组中设置的打包命令，对所述分支代码进行打包，得到所述子目标文件。

在具体的应用场景中，该推送模块303，用于在所述目标系统中确定所述目标文件升级的所述系统功能，运行所述系统功能，以及测试验证所述系统功能的运行状态，生成所述验证结果。

在具体的应用场景中，该验证模块304，用于当所述验证结果指示所述系统功能运行正常时，对所述系统功能进行预发验证、灰度引流；若所述预发验证、灰度引流验证所述系统功能运行正常，则将所述目标文件升级的系统功能上线，完成对所述目标系统的升级。

在具体的应用场景中，如图3B所示，所述装置还包括：生成模块305。

该生成模块305，用于当所述验证结果指示所述目标系统运行异常时，生成用于指示升级失败的提示信息，将所述提示信息发送至展示终端进行展示，以使所述使用方基于所述提示信息重新进行系统升级。

本申请实施例提供的装置，可以首先响应于使用方触发打包命令，拉取多个分支代码。随后，基于预设插件脚本，对多个分支代码进行代码升级，并打包多个分支代码，得到目标文件。接下来，推送目标文件至目标系统下部署，抽查验证目标文件在目标系统中升级的系统功能。当验证结果指示系统功能运行正常时，完成对目标系统的升级。通过采用预设插件脚本的一次触发多次打包的打包机制，对多个分支代码进行打包，生成目标文件后部署至目标系统进行验证，验证目标系统的相关功能，判断目标文件是否成功升级目标系统，既节省了打包时间，降低系统升级的时间成本，又提高了对系统功能的验证力度，间接保证了升级后的版本对系统功能无损无害。

需要说明的是，本申请实施例提供的一种系统升级装置所涉及各功能单元的其他相应描述，可以参考图1和图2A至图2B中的对应描述，在此不再赘述。

在示例性实施例中，参见图4，还提供了一种设备，该设备包括通信总线、处理器、存储器和通信接口，还可以包括输入输出接口和显示设备，其中，各个功能单元之间可以通过总线完成相互间的通信。该存储器存储有计算机程序，处理器，用于执行存储器上所存放的程序，执行上述实施例中的系统升级方法。

一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现所述的系统升级方法的步骤。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可以通过硬件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施场景所述的方法。

本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本申请所必须的。

本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本申请序号仅仅为了描述，不代表实施场景的优劣。

以上公开的仅为本申请的几个具体实施场景，但是，本申请并非局限于此，任何本领域的技术人员能思之的变化都应落入本申请的保护范围。

Claims (10)

1.一种系统升级方法，其特征在于，包括：

响应于使用方触发打包命令，拉取多个分支代码，所述多个分支代码为所述打包命令指示的目标系统对应的多个旧版本代码；

基于预设插件脚本，对所述多个分支代码进行代码升级，并打包所述多个分支代码，得到目标文件；

推送所述目标文件至所述目标系统下部署，抽查验证所述目标文件在所述目标系统中升级的系统功能；

当验证结果指示所述系统功能运行正常时，完成对所述目标系统的升级。

2.根据权利要求1所述的方法，其特征在于，所述响应于使用方触发打包命令，拉取多个分支代码，包括：

响应于所述使用方在所述目标系统触发Jenkins打包工具，调用所述Jenkins打包工具，在预设数据库中读取所述目标系统对应的全部分支代码；

分别读取所述全部分支代码对应的升级时间，将所述全部分支代码按照所述升级时间的先后顺序进行排序；

确定所述使用方输入的预设数目，在所述全部分支代码中，从后向前拉取所述预设数目的分支代码，得到所述多个分支代码。

3.根据权利要求1所述的方法，其特征在于，所述基于预设插件脚本，对所述多个分支代码进行代码升级，并打包所述多个分支代码，得到目标文件，包括：

获取所述预设插件脚本，将所述预设插件脚本嵌入打包工具；

采用所述预设插件脚本对所述多个分支代码分别进行代码处理，生成多个容器组；

在每个所述容器组中查询工程代码，根据预设升级内容，对所述工程代码进行代码升级并打包，得到子目标文件；

遍历所述多个容器组，对所述多个容器组中的每个容器组进行代码修改并打包，得到多个子目标文件；

将所述多个子目标文件进行聚合，得到所述目标文件。

4.根据权利要求3所述的方法，其特征在于，所述在每个所述容器组中查询工程代码，根据预设升级内容，对所述工程代码进行代码升级并打包，得到子目标文件，包括：

在所述容器组中查询工程代码，读取所述工程代码中存储的代码内容，确定主pom文件；

在所述主pom文件中，采用所述预设升级内容进行代码升级，并修改对应的版本号；

触发所述容器组中设置的打包命令，对所述分支代码进行打包，得到所述子目标文件。

5.根据权利要求1所述的方法，其特征在于，所述抽查验证所述目标文件在所述目标系统中升级的系统功能，包括：在所述目标系统中确定所述目标文件升级的所述系统功能，运行所述系统功能，以及测试验证所述系统功能的运行状态，生成所述验证结果。

6.根据权利要求1所述的方法，其特征在于，所述当验证结果指示所述系统功能运行正常时，完成对所述目标系统的升级，包括：

当所述验证结果指示所述系统功能运行正常时，对所述系统功能进行预发验证、灰度引流；

若所述预发验证、灰度引流验证所述系统功能运行正常，则将所述目标文件升级的系统功能上线，完成对所述目标系统的升级。

7.根据权利要求1所述的方法，其特征在于，所述推送所述目标文件至所述目标系统下部署，抽查验证所述目标文件在所述目标系统中升级的系统功能之后，所述方法还包括：

当所述验证结果指示所述目标系统运行异常时，生成用于指示升级失败的提示信息，将所述提示信息发送至展示终端进行展示，以使所述使用方基于所述提示信息重新进行系统升级。

8.一种系统升级装置，其特征在于，包括：

拉取模块，用于响应于使用方触发打包命令，拉取多个分支代码，所述多个分支代码为所述打包命令指示的目标系统对应的多个旧版本代码；

打包模块，用于基于预设插件脚本，对所述多个分支代码进行代码升级，并打包所述多个分支代码，得到目标文件；

推送模块，用于推送所述目标文件至所述目标系统下部署，抽查验证所述目标文件在所述目标系统中升级的系统功能；

验证模块，用于当验证结果指示所述系统功能运行正常时，完成对所述目标系统的升级。

9.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至7中任一项所述方法的步骤。

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

Images