System upgrading method and device, computer device and computer readable storage medium

Abstract

The application is suitable for the field of internet technology and digital medical treatment, discloses a system upgrading method and device, computer equipment and computer readable storage medium, relates to the field of internet, and can save the packaging time by improving the system upgrading process, improving the system function verification strength, and using the preset plug-in script to package the multiple branch codes multiple times, thereby reducing the time cost of system online. The method comprises the following steps: in response to the packaging command triggered by the user, pulling the multiple branch codes, the multiple branch codes being the multiple old version codes corresponding to the target system indicated by the packaging command; based on the preset plug-in script, upgrading the codes of the multiple branch codes, and packaging the multiple branch codes to obtain a target file; pushing the target file to the target system for deployment, and checking the system function of the target file upgraded in the target system; when the verification result indicates that the system function runs normally, completing the upgrading of the target system.

Description

Technical Field

[0001] This application relates to the fields of Internet technology and digital healthcare, and in particular to a system upgrade method, apparatus, computer equipment, and computer-readable storage medium. Background Technology

[0002] With the continuous development of internet technology, internet companies need to operate and maintain anywhere from dozens to hundreds or even thousands of systems. When a system experiences a vulnerability, such as a vulnerability in log4j, a vulnerability in Spring, or a vulnerability in Fastjson, it can have a certain impact on the company.

[0003] In related technologies, for events with extremely high security vulnerability coefficients, such as fixing vulnerabilities, it is necessary to quickly modify, verify, and deploy them online. Developers go through a series of processes, including pulling branches, modifying code to upgrade the JAR package version number, submitting code, packaging code, deploying the new package, testing and verification, pre-release verification, and canary rollout, before finally deploying the entire system online.

[0004] In the process of developing this application, the applicant discovered that the relevant technology has at least the following problems:

[0005] Due to the large number of systems and the lengthy system upgrade and deployment process, even minor code modifications require going through all the above-mentioned procedures and taking at least 1-2 days to successfully go live, resulting in low efficiency and slow speed for the entire system upgrade. Summary of the Invention

[0006] In view of this, this application provides a system upgrade method, apparatus, computer device, and computer-readable storage medium. The main purpose is to solve the problem that the current system has too many components, the packaging and deployment process is too long, and even if a small part of the code is modified, it is necessary to go through the above process and spend at least 1-2 days to successfully go online, resulting in low efficiency and slow speed of the entire vulnerability repair.

[0007] According to a first aspect of this application, a system upgrade method is provided, the method comprising:

[0008] In response to the user triggering a packaging command, multiple branch codes are pulled, and the multiple branch codes are multiple old versions of code corresponding to the target system indicated by the packaging command;

[0009] Based on a preset plugin script, the code of the multiple branches is upgraded and packaged to obtain the target file;

[0010] The target file is pushed to the target system for deployment, and the system functions upgraded by the target file in the target system are randomly checked and verified.

[0011] When the verification results indicate that the system functions normally, the upgrade of the target system is completed.

[0012] According to a second aspect of this application, a system upgrade apparatus is provided, the apparatus comprising:

[0013] The pull module is used to pull multiple branch codes in response to a packaging command triggered by the user. The multiple branch codes are multiple old versions of code corresponding to the target system indicated by the packaging command.

[0014] The packaging module is used to upgrade the code of the multiple branches based on a preset plugin script, and package the multiple branches to obtain the target file;

[0015] The push module is used to push the target file to the target system for deployment and to conduct spot checks to verify the system functions upgraded by the target file in the target system;

[0016] The verification module is used to complete the upgrade of the target system when the verification result indicates that the system functions normally.

[0017] According to a third aspect of this application, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described in any of the first aspects above.

[0018] According to a fourth aspect of this application, a computer-readable storage medium is provided, on which a computer program is stored, wherein the computer program, when executed by a processor, implements the steps of the method described in any one of the first aspects above.

[0019] By employing the above technical solution, this application provides a system upgrade method, apparatus, computer equipment, and computer-readable storage medium. First, in response to a user-triggered packaging command, multiple branch codes are retrieved. Then, based on a preset plugin script, the multiple branch codes are upgraded and packaged to obtain a target file. Next, the target file is pushed to the target system for deployment, and the upgraded system functionality of the target file is verified. When the verification result indicates that the system functionality is operating normally, the upgrade of the target system is completed. By adopting a packaging mechanism that triggers multiple packages at once using a preset plugin script, multiple branch codes are packaged, and after generating the target file, it is deployed to the target system for verification. This verifies the relevant functions of the target system and determines whether the target file has successfully upgraded the target system. This saves packaging time, reduces the time cost of system upgrades, and enhances the verification of system functionality, indirectly ensuring that the upgraded version is harmless to system functionality.

[0020] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0021] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0022] Figure 1 This illustration shows a schematic flowchart of a system upgrade method provided in an embodiment of this application;

[0023] Figure 2A This illustration shows a schematic flowchart of a system upgrade method provided in an embodiment of this application;

[0024] Figure 2B This illustration shows a schematic flowchart of a system upgrade method provided in an embodiment of this application;

[0025] Figure 3A This paper shows a schematic diagram of the structure of a system upgrade device provided in an embodiment of this application;

[0026] Figure 3B This paper shows a schematic diagram of the structure of a system upgrade device provided in an embodiment of this application;

[0027] Figure 4 A schematic diagram of the device structure of a computer device provided in an embodiment of this application is shown. Detailed Implementation

[0028] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete, and will fully convey the scope of the present application to those skilled in the art.

[0029] This application provides a system upgrade method, such as... Figure 1 As shown, the method includes:

[0030] 101. In response to the user triggering the packaging command, pull multiple branch codes. The multiple branch codes are multiple old versions of code corresponding to the target system indicated by the packaging command.

[0031] In this embodiment, to determine which system needs upgrading, the user triggers a packaging command on the target system. The packaging platform provided by this application responds to the packaging command, identifies the target system, and retrieves multiple branch codes from the target system. In specific implementation, this solution can be applied to medical upgrade systems. Responding to a packaging upgrade command initiated by the target medical subsystem, it retrieves multiple branch codes from the target medical subsystem to upgrade the system. It should be noted that the branch codes are old versions of code stored in the target system. For example, if the target system undergoes a code upgrade (JAR package upgrade) monthly, and this upgrade is for the July version, then the old versions of code from June, May, April, March, and February need to be retrieved separately. Furthermore, the number of branches retrieved can be the default number set by the packaging platform, or it can be set by the user, i.e., relevant personnel, based on the actual application situation. This application does not specifically limit the number of branches retrieved.

[0032] 102. Based on the preset plugin script, upgrade the code of multiple branches and package the code of multiple branches to obtain the target file.

[0033] In this embodiment, considering that building only one package at a time is very time-consuming, a pre-defined plugin script, fast-upgrade-version.sh, is provided. Relevant personnel will pre-write the lightweight pre-defined plugin script, fast-upgrade-version.sh, and embed it into the packaging process. Using this pre-defined plugin script, multiple branches of code are upgraded and packaged simultaneously. Finally, the packaged sub-target files are aggregated to obtain the target file.

[0034] 103. Push the target file to the target system for deployment, and conduct spot checks to verify the system functions upgraded by the target file in the target system.

[0035] Next, the target files are pushed to the target system for deployment. Continuing with the target medical subsystem as an example, if target medical subsystem A is verifying the code of the [Medical System Engineering Code 0401 branch], the default plugin script `fast-upgrade-version.sh` will pull the code from the five most recent versions of the [Medical System Engineering Code 0401 branch] branch, package them, and push them to target medical subsystem A. After deployment, the target files are randomly checked to verify whether they have successfully upgraded the corresponding system functions in the target medical subsystem.

[0036] 104. When the verification results indicate that the system functions normally, complete the upgrade of the target system.

[0037] In this embodiment of the application, when the verification result indicates that the target file is running normally, it means that the target file upgrade jar package does not affect the operation of the target system, and thus the upgrade of the target system can be completed.

[0038] The method provided in this application first responds to a user-triggered packaging command to retrieve multiple branch codes. Then, based on a preset plugin script, it upgrades the code on the multiple branch codes and packages them to obtain a target file. Next, it pushes the target file to the target system for deployment and performs spot checks to verify the upgraded system functionality. When the verification result indicates that the system functionality is running normally, the upgrade of the target system is completed. By employing a packaging mechanism that uses a preset plugin script to trigger multiple packaging operations at once, multiple branch codes are packaged, and after generating the target file, it is deployed to the target system for verification. This verifies the relevant functions of the target system and determines whether the target file has successfully upgraded the target system. This saves packaging time, reduces the time cost of system upgrades, and enhances the verification of system functionality, indirectly ensuring that the upgraded version is harmless to system functionality.

[0039] This application provides a system upgrade method, such as... Figure 2A As shown, the method includes:

[0040] 201. In response to the user triggering the Jenkins packaging tool on the target system, the Jenkins packaging tool is invoked to pull multiple branch codes from the preset database.

[0041] With the continuous development of internet technology, internet companies need to operate and maintain anywhere from dozens to hundreds or even thousands of systems. When a system experiences a vulnerability, such as a vulnerability in log4j, Spring, or Fastjson, it can have a significant impact on the company. Currently, for fixing vulnerabilities with extremely high security risk, rapid modification and verification before deployment are crucial. Developers go through a series of processes, including pulling branches, modifying code to upgrade JAR package versions, committing code, packaging code, deploying the new package, testing and verification, pre-release verification, and canary rollout, before finally deploying the entire system.

[0042] However, the applicant recognized that due to the large number of systems, the system upgrade and launch process was too long. Even with minor code modifications, it was necessary to go through all the above-mentioned processes, which would take at least 1-2 days to successfully launch the system, resulting in low efficiency and slow speed of the entire system upgrade.

[0043] Therefore, this application provides a system upgrade method, apparatus, computer equipment, and computer-readable storage medium. First, in response to a user-triggered packaging command, multiple branch codes are retrieved. Then, based on a preset plugin script, the multiple branch codes are upgraded and packaged to obtain a target file. Next, the target file is pushed to the target system for deployment, and the upgraded system functionality of the target file in the target system is verified. When the verification result indicates that the system functionality is operating normally, the upgrade of the target system is completed. By employing a packaging mechanism of one-trigger-multiple-packaging using a preset plugin script, multiple branch codes are packaged, and after generating the target file, it is deployed to the target system for verification. This verifies the relevant functions of the target system and determines whether the target file has successfully upgraded the target system. This saves packaging time, reduces the time cost of system upgrades, and enhances the verification of system functionality, indirectly ensuring that the upgraded version is harmless to system functionality. In specific implementation, this solution can be applied to medical upgrade systems. In response to a packaging upgrade command initiated by the target medical subsystem, multiple branch codes of the target medical subsystem are retrieved, packaged, and after generating the target file, it is deployed to the target medical subsystem for system upgrade.

[0044] In practical applications, to determine which system needs upgrading, the user triggers the Jenkins packaging tool on the target system to generate a packaging command. The packaging platform responds to the packaging command, identifies the target system, and retrieves branch code from multiple target systems in a pre-defined database.

[0045] Specifically, considering that older versions of code generated from historical system upgrades are stored in a pre-defined database for easy retrieval and backtracking, this application reads all branch codes corresponding to the target system from the pre-defined database. The upgrade times corresponding to all branch codes are read separately, and all branch codes are sorted according to the chronological order of their upgrade times. Then, the preset number of branch codes input by the user is determined, and from the preset number of branch codes, the preset number of branch codes are retrieved from the end to the beginning, resulting in multiple branch codes.

[0046] For example, if the target system undergoes a monthly code upgrade (JAR package upgrade), and this upgrade is for the July version, then all branch code is read from the preset database. The branch code is then arranged by month from January to June, and the branch code for June, May, April, March, and February is retrieved sequentially from the end of the month, resulting in multiple branch codes. It should be noted that the branch code is the old version code stored in the target system. The number of branch codes retrieved can use the default retrieval number of the packaging platform, or it can be set by the user (i.e., relevant personnel) based on the actual application situation. This application does not impose a specific limit on the number of branch codes retrieved.

[0047] Through the above steps, each system can independently call the target packaging tool for system upgrades, and multiple systems can be upgraded in parallel, saving a lot of communication and development manpower costs, shortening system upgrade time, and improving system upgrade efficiency.

[0048] 202. Obtain the preset plugin script, embed the preset plugin script into the packaging tool, and use the preset plugin script to process the code of multiple branches separately to generate multiple container groups.

[0049] In this embodiment, considering that building only one package at a time is very time-consuming, a pre-defined plugin script, fast-upgrade-version.sh, is provided. Relevant personnel will pre-write the lightweight pre-defined plugin script, fast-upgrade-version.sh, and embed it into the packaging process. Using this pre-defined plugin script, multiple packaging operations can be achieved by leveraging the original single-package trigger mechanism. Specifically, after detecting the packaging command, code processing is performed on multiple branches to generate multiple pod container groups. It should be noted that a container group is the smallest deployable unit in Kubernetes, representing an independent running instance of an application in Kubernetes. This instance may consist of a single container or several tightly coupled containers.

[0050] 203. Query the project code in each container group, upgrade the project code according to the preset upgrade content, and package it to obtain the target file.

[0051] Furthermore, the project code is queried in each container group, and the code is upgraded and packaged according to the preset upgrade content to obtain the target file. In actual application, developers may modify some code in the project code; in this case, the modified content can be used as the preset upgrade content. Next, the packaging platform queries the project code in the container group, reads the code content stored in the project code, and determines the main pom file.

[0052] In the main pom file, the code is upgraded using preset upgrade content. In an optional implementation, the packaging platform can determine the code to be modified based on information such as addresses or pointers input by the developers, and replace the modified code with the preset upgrade content to complete the code upgrade. Then, the corresponding JAR package version number is modified, triggering the packaging command set in the container group to package the branch code, resulting in the sub-target file.

[0053] By repeating the upgrade packaging steps described in step 203, the code of multiple container groups is modified and packaged to obtain multiple sub-target files. Finally, the upgrade system aggregates the multiple sub-target files to obtain the target file.

[0054] 204. Push the target file to the target system for deployment, and conduct spot checks to verify the upgraded system functions of the target file in the target system. When the verification result indicates that the system functions are operating normally, proceed to step 205 below. When the verification result indicates that the system functions are operating abnormally, proceed to step 206 below.

[0055] Next, the target file is pushed to the target system for deployment. After deployment, the testing and verification phase begins. Specifically, the system functions upgraded by the target file are determined, the system functions are run, and the running status of the system functions is tested and verified, generating verification results. In practice, the testing and verification phase involves relevant testers specifically verifying the upgraded JAR package of the target file.

[0056] When the verification result indicates that the target file is running normally, the jar package upgrade can be considered successful. The upgraded jar package has no unexpected impact on the existing system functions, and the subsequent upgrade process for the target system can be completed, which is to execute step 205 below.

[0057] When the verification result indicates that the target file is running abnormally, a prompt message is generated to indicate that the upgrade has failed. The prompt message is sent to the display terminal for display, so that the user can upgrade the system again based on the prompt message, that is, to execute the following step 206.

[0058] 205. When the verification results indicate that the target file is running normally, perform pre-release verification and gray-scale pilot testing of the upgraded system functions of the target file, and then launch the upgraded system functions of the target file.

[0059] If the pre-release verification and canary rollout verification systems function normally, the upgraded system functions will be deployed online. In the actual verification process, if there are no API conflicts, after packaging and deployment using Jenkins, and after 1-2 hours of verification without errors, pre-release verification, canary rollout, and production release can generally be carried out. The entire process takes approximately 2-3 hours, greatly shortening the system upgrade time and improving system upgrade efficiency.

[0060] Additionally, if the pre-release verification or gray-scale traffic redirection verification system malfunctions, it will also generate a prompt message indicating upgrade failure. This prompt message will be sent to a demonstration terminal for display, allowing users to re-upgrade the system based on the message. It should be noted that the demonstration terminal can be a computer, tablet, or other device with display capabilities; this application does not specifically limit the type of demonstration terminal.

[0061] The system platform provided in this application enables hundreds of systems to be upgraded in parallel with almost no development intervention, saving a lot of communication and development manpower costs. After direct testing and regression verification, hundreds of systems can be released and launched in just half a day to quickly resolve security vulnerabilities.

[0062] 206. When the verification result indicates that the target file is running abnormally, generate a prompt message to indicate that the upgrade has failed, and send the prompt message to the display terminal for display so that the user can upgrade the system again based on the prompt message.

[0063] In this embodiment, when the verification result indicates that the target file is running abnormally, a prompt message indicating upgrade failure is generated. The prompt message may return the reason for the failure or only return the failure result; this application does not specifically limit the content of the prompt message. Furthermore, the prompt message is sent to a display terminal for display, so that the user, i.e., the developer, can determine the reason for the failure after receiving the reminder message. After resolving the relevant issues, the packaging tool is re-triggered to complete the system upgrade operation.

[0064] In summary, such as Figure 2B As shown, the method provided in this application can process system upgrade requests for each system in parallel, with each system first entering the packaging and deployment phase. Specifically, in the packaging and deployment phase, multiple versions of branch code are pulled using the packaging platform provided in this application, generating multiple container groups. The project code is queried within each container group to determine the main pom file, and code upgrades are performed within the main pom file. This triggers the packaging command in the container group to package each branch code, resulting in multiple sub-target files, which are then sent to the target system for deployment. Next, a testing and verification phase is initiated to verify the upgraded system functionality of the target system. After successful verification, pre-release verification, canary rollout, and finally, deployment and launch are performed, completing the upgrade of the target system.

[0065] The method provided in this application first responds to a user-triggered packaging command to retrieve multiple branch codes. Then, based on a preset plugin script, it upgrades the code on the multiple branch codes and packages them to obtain a target file. Next, it pushes the target file to the target system for deployment and performs spot checks to verify the upgraded system functionality. When the verification result indicates that the system functionality is running normally, the upgrade of the target system is completed. By employing a packaging mechanism that uses a preset plugin script to trigger multiple packaging operations at once, multiple branch codes are packaged, and after generating the target file, it is deployed to the target system for verification. This verifies the relevant functions of the target system and determines whether the target file has successfully upgraded the target system. This saves packaging time, reduces the time cost of system upgrades, and enhances the verification of system functionality, indirectly ensuring that the upgraded version is harmless to system functionality.

[0066] Furthermore, as Figure 1 To specifically implement the method, this application provides a system upgrade device, such as... Figure 3A As shown, the device includes: a pull module 301, a packaging module 302, a push module 303, and a verification module 304.

[0067] The pull module 301 is used to pull multiple branch codes in response to a packaging command triggered by the user. The multiple branch codes are multiple old version codes corresponding to the target system indicated by the packaging command.

[0068] The packaging module 302 is used to upgrade the code of the multiple branches based on a preset plugin script, and package the multiple branches to obtain the target file;

[0069] The push module 303 is used to push the target file to the target system for deployment and to conduct spot checks to verify the system functions upgraded by the target file in the target system;

[0070] The verification module 304 is used to complete the upgrade of the target system when the verification result indicates that the system functions normally.

[0071] In a specific application scenario, the pull module 301 is used to respond to the user triggering the Jenkins packaging tool on the target system, call the Jenkins packaging tool, read all branch codes corresponding to the target system from a preset database; read the upgrade time corresponding to each of the branch codes, sort the branch codes according to the order of the upgrade time; determine the preset number input by the user, and pull the preset number of branch codes from the last to the first from the last of the branch codes to obtain the multiple branch codes.

[0072] In a specific application scenario, the packaging module 302 is used to obtain the preset plugin script, embed the preset plugin script into the packaging tool; use the preset plugin script to process the multiple branch codes respectively, generating multiple container groups; query the project code in each container group, upgrade the project code according to the preset upgrade content, and package it to obtain sub-target files; traverse the multiple container groups, modify the code of each container group and package it to obtain multiple sub-target files; aggregate the multiple sub-target files to obtain the target file.

[0073] In a specific application scenario, the packaging module 302 is used to query the project code in the container group, read the code content stored in the project code, and determine the main pom file; in the main pom file, the code is upgraded using the preset upgrade content, and the corresponding version number is modified; the packaging command set in the container group is triggered to package the branch code to obtain the sub-target file.

[0074] In a specific application scenario, the push module 303 is used to determine the system function upgraded by the target file in the target system, run the system function, test and verify the running status of the system function, and generate the verification result.

[0075] In specific application scenarios, the verification module 304 is used to perform pre-release verification and gray-scale traffic redirection on the system function when the verification result indicates that the system function is operating normally; if the pre-release verification and gray-scale traffic redirection verify that the system function is operating normally, then the system function of the target file upgrade is launched online, and the upgrade of the target system is completed.

[0076] In specific application scenarios, such as Figure 3B As shown, the device further includes a generation module 305.

[0077] The generation module 305 is used to generate a prompt message indicating upgrade failure when the verification result indicates that the target system is malfunctioning, and send the prompt message to the display terminal for display, so that the user can re-upgrade the system based on the prompt message.

[0078] The apparatus provided in this application embodiment can first respond to a user-triggered packaging command to pull multiple branch codes. Then, based on a preset plugin script, it upgrades the code of the multiple branch codes and packages them to obtain a target file. Next, it pushes the target file to the target system for deployment and randomly checks and verifies the upgraded system functionality of the target file in the target system. When the verification result indicates that the system functionality is running normally, the upgrade of the target system is completed. By employing a packaging mechanism that uses a preset plugin script to trigger multiple packaging operations at once, multiple branch codes are packaged, and after generating the target file, it is deployed to the target system for verification. This verifies the relevant functions of the target system and determines whether the target file has successfully upgraded the target system. This saves packaging time, reduces the time cost of system upgrades, and increases the verification of system functionality, indirectly ensuring that the upgraded version is harmless to system functionality.

[0079] It should be noted that other corresponding descriptions of the functional units involved in the system upgrade device provided in this application embodiment can be found by referring to... Figure 1 and Figures 2A to 2B The corresponding description in [the document] will not be repeated here.

[0080] In an exemplary embodiment, see Figure 4 The invention also provides a device comprising a communication bus, a processor, a memory, and a communication interface, and may further include an input / output interface and a display device, wherein the various functional units can communicate with each other via the bus. The memory stores a computer program, and the processor executes the program stored in the memory to perform the system upgrade method described in the above embodiments.

[0081] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the system upgrade method.

[0082] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented in hardware or by using software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) and includes several instructions to cause a computer device (such as a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0083] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of a preferred embodiment, and the modules or processes shown in the drawings are not necessarily essential for implementing this application.

[0084] Those skilled in the art will understand that the modules in the apparatus of the implementation scenario can be distributed within the apparatus of the implementation scenario as described, or they can be located in one or more apparatuses different from this implementation scenario, with corresponding changes. The modules of the above-described implementation scenario can be combined into one module, or they can be further divided into multiple sub-modules.

[0085] The serial numbers in this application are for descriptive purposes only and do not represent the superiority or inferiority of the implementation scenario.

[0086] The above disclosures are only a few specific implementation scenarios of this application. However, this application is not limited to these. Any variations that can be conceived by those skilled in the art should fall within the protection scope of this application.

Claims

1. A system upgrade method, characterized in that, include: In response to the user triggering a packaging command, multiple branch codes are pulled, and the multiple branch codes are multiple old versions of code corresponding to the target system indicated by the packaging command; Based on a preset plugin script, the code of the multiple branches is upgraded and packaged to obtain the target file; The target file is pushed to the target system for deployment, and the system functions upgraded by the target file in the target system are randomly checked and verified. When the verification results indicate that the system functions normally, the upgrade of the target system is completed; The process of upgrading the code of the multiple branches based on a preset plugin script and packaging the multiple branches to obtain a target file includes: Obtain the preset plugin script and embed the preset plugin script into the packaging tool; The preset plugin script is used to process the code of the multiple branches respectively, generating multiple container groups; wherein, each container group is used to upgrade and package the code of one branch corresponding to the multiple branches; In each of the container groups, the project code is queried, and according to the preset upgrade content, the project code is upgraded and packaged to obtain a sub-target file; The code of each container group is modified and packaged to obtain multiple sub-target files. The multiple sub-target files are aggregated to obtain the target file.

2. The method according to claim 1, characterized in that, The response to the user triggering a packaging command, pulling multiple branch codes, includes: In response to the user triggering the Jenkins packaging tool on the target system, the Jenkins packaging tool is invoked to read all branch code corresponding to the target system from a preset database; Read the upgrade time corresponding to each of the branch codes, and sort the branch codes according to the order of the upgrade times; Determine the preset number of branches input by the user, and pull the preset number of branches from the back to the front of all the branches to obtain the multiple branches.

3. The method according to claim 1, characterized in that, The process involves querying the project code in each container group, upgrading the project code according to preset upgrade content, and packaging it to obtain sub-target files, including: Query the project code in the container group, read the code content stored in the project code, and determine the main pom file; In the main pom file, the code is upgraded using the preset upgrade content, and the corresponding version number is modified; The packaging command set in the container group is triggered to package the branch code and obtain the sub-target file.

4. The method according to claim 1, characterized in that, The random inspection and verification of the system functions upgraded by the target file in the target system includes: determining the system functions upgraded by the target file in the target system, running the system functions, testing and verifying the running status of the system functions, and generating the verification results.

5. The method according to claim 1, characterized in that, When the verification result indicates that the system is functioning normally, the upgrade of the target system is completed, including: When the verification result indicates that the system function is operating normally, the system function is pre-released for verification and then subjected to gray-scale deployment. If the pre-release verification and gray-scale traffic verification systems function normally, the system functions for upgrading the target file will be launched, completing the upgrade of the target system.

6. The method according to claim 1, characterized in that, After pushing the target file to the target system for deployment and randomly verifying the system functions upgraded by the target file in the target system, the method further includes: When the verification result indicates that the target system is malfunctioning, a prompt message is generated to indicate that the upgrade has failed. The prompt message is then sent to the display terminal for display, so that the user can perform the system upgrade again based on the prompt message.

7. A system upgrade device, characterized in that, include: The pull module is used to pull multiple branch codes in response to a packaging command triggered by the user. The multiple branch codes are multiple old versions of code corresponding to the target system indicated by the packaging command. The packaging module is used to upgrade the code of the multiple branches based on a preset plugin script, and package the multiple branches to obtain the target file; The push module is used to push the target file to the target system for deployment and to conduct spot checks to verify the system functions upgraded by the target file in the target system; The push module is further configured to: obtain the preset plugin script; embed the preset plugin script into a packaging tool; process the multiple branch codes using the preset plugin script to generate multiple container groups; wherein each container group is used to upgrade and package a corresponding branch code in the multiple branch codes; query the project code in each container group, upgrade and package the project code according to the preset upgrade content to obtain sub-target files; traverse the multiple container groups, modify and package the code in each container group to obtain multiple sub-target files; aggregate the multiple sub-target files to obtain the target file; and a verification module is configured to complete the upgrade of the target system when the verification result indicates that the system function is running normally.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images