Patch deployment method, deployment device, and readable storage medium

Abstract

The present invention proposes a patch deployment method, a deployment device, and a readable storage medium. The patch deployment method includes: obtaining an original patch and determining the corresponding multiple microservices; splitting the original patch into multiple patches corresponding to multiple microservices; deploying the multiple patches to multiple microservices to obtain corresponding multiple deployment patches; verifying any one of the multiple deployment patches; based on a successful verification, converting any one of the deployment patches into a solidified patch; and performing a patch rollback operation based on a failed verification. Through the patch deployment method of the present invention, the development model and the deployment model are separated, and different roles perceive different parts of patch management in a complex cloud-native environment, which greatly reduces the complexity and difficulty of patch management for cloud-native applications.

Description

Technical Field

[0001] The present invention relates to the technical field of enterprise digital cloud platforms, and in particular to a patch deployment method, a patch deployment device, and a readable storage medium. Background Art

[0002] In the context of cloud-native applications, the complex operations and maintenance environment has led to increasingly complex business functions such as patch version management, patch splitting and merging, patch deployment, and patch rollback. Traditional patch management is no longer suitable for the multi-environment, multi-service, multi-image, multi-role, and multi-user scenarios inherent in cloud-native applications. Summary of the Invention

[0003] The present invention aims to solve at least one of the technical problems existing in the prior art or related art.

[0004] To this end, one aspect of the present invention is to propose a patch deployment method.

[0005] Another aspect of the present invention is to provide a patch deployment device.

[0006] Another aspect of the present invention provides a readable storage medium.

[0007] In view of this, according to one aspect of the present invention, a patch deployment method is proposed, including: obtaining an original patch and determining the corresponding multiple microservices; splitting the original patch into multiple patches corresponding to the multiple microservices; deploying the multiple patches to the multiple microservices to obtain the corresponding multiple deployed patches; verifying any one of the multiple deployed patches; based on a successful verification, converting any one of the deployed patches into a solidified patch; based on a failed verification, performing a patch rollback operation.

[0008] The patch deployment method provided by the present invention first obtains the original state patch, which is a patch compression package compiled by developers in the current development environment according to business needs. Then, by performing patch analysis on the original state patch, the corresponding multiple microservices in the cloud native context are determined. Then, by splitting the original state patch into multiple patches corresponding to multiple microservices, and deploying the multiple patches to multiple microservices, the monomer architecture of the original state patch is automatically converted into the microservice architecture in the cloud native context, and the state of the patch is correspondingly converted from the original state to the deployed state. Finally, any patch in the deployed state (deployed state patch) is verified. If the verification is successful, that is, when the corresponding microservice startup patch takes effect, the state of this any patch is converted from the deployed state to the solidified state; if the verification fails, the patch rollback operation is performed, and the current version of the patch library version is rolled back to the patch library version before the patch is applied (deployed). Through the patch deployment method of the present invention, the development model and deployment model of the business system are separated. On the one hand, the details of the cloud native microservice can be shielded from the developers. The developers only need to focus on the business logic of their own field. On the other hand, different roles perceive different parts of patch management in a complex cloud native environment, greatly reducing the complexity and difficulty of patch management in cloud native applications.

[0009] Different roles can be divided into developers, operation and maintenance personnel, testers, and users.

[0010] The patch deployment method according to the present invention may also have the following technical features:

[0011] In the above technical solution, the patch deployment method further includes: creating a mirror version according to multiple solidified patches corresponding to multiple deployed patches.

[0012] In this technical solution, after the deployed patch passes the verification, it is converted into a solidified patch, and the solidified patch can be used to make an image. Multiple solidified patches that are deployed and take effect at one time can be solidified into a new image version. Of course, it is also possible to quickly make a new image version by pulling a patch library of a specified version based on constraints such as the environment and the online time window. Through the technical solution of the present invention, the patch testing scenario can be divided into patch pulling, patch deployment, and patch verification with patches as the management dimension according to the characteristics of customer patch management in the delivery state, as well as the differences in the environment and the online time window. The online environment uses the image as the management dimension, and by pulling a patch library of a specified version, the image can be quickly made online, rolled back, etc., to maintain a stable online environment, thereby reducing the complexity of the patch deployment strategy under the multi-environment characteristics for testers and reducing the complexity of patch version management under the multi-mirror characteristics for operation and maintenance personnel.

[0013] In any of the above technical solutions, after the step of deploying multiple patches to multiple microservices, the method further includes: generating corresponding patch deployment records.

[0014] In this technical solution, the original patch is analyzed to determine the corresponding microservices. The original patch is then split into multiple patches corresponding to the microservices. These patches are then deployed to the microservices, and a patch deployment record is generated. This deployment record is used for troubleshooting and problem location, thus reducing the complexity of patch version management for operations and maintenance personnel in the multi-image environment.

[0015] In any of the above technical solutions, the step of determining the corresponding multiple microservices specifically includes: determining the corresponding patch directory based on the original patch code; determining the business scenario associated with the original patch according to the patch directory; and determining multiple microservices according to the business scenario.

[0016] This technical solution analyzes the business scenarios involved in the original patch, specifically by analyzing the patch directory structure of the original patch. Each business scenario corresponds to a microservice, thereby determining the multiple microservices corresponding to the original patch. Through the technical solution of the present invention, the original patch of a monolithic architecture is automatically converted to a microservice architecture in a cloud-native context, thereby enabling patch management in a multi-user environment with different user scenarios.

[0017] In any of the above technical solutions, the step of splitting the original patch into multiple patches corresponding to multiple microservices specifically includes: splitting and merging the original patch according to multiple preset patch rules associated with the business scenario to obtain multiple patches corresponding to multiple microservices.

[0018] This technical solution uses multiple pre-set patch rules associated with business scenarios. Each pre-set patch rule includes logic for splitting functional module services and deployment logic based on variables such as resource file paths. This allows the original patch to be split into multiple functional modules. Since each microservice can contain multiple functional modules, and different microservices may contain the same functional modules depending on business needs, multiple functional modules can be merged to generate multiple patches corresponding to multiple microservices.

[0019] The preset patch rules may be pre-set before the software is released.

[0020] In any of the above technical solutions, any one of the multiple preset patch rules is used to define the functional modules and associated image versions included in any one of the multiple microservices.

[0021] In this technical solution, each business scenario corresponds to a microservice. Implementing a business scenario typically requires multiple functional modules, so a microservice typically contains multiple functional modules. Each of the multiple pre-set patch rules defines a microservice, specifically the functional modules involved and the associated image versions. Therefore, based on the multiple pre-set patch rules associated with the business scenario, the original patch can be split and merged to obtain multiple patches corresponding to multiple microservices.

[0022] In any of the above technical solutions, the step of verifying any deployment-state patch among multiple deployment-state patches specifically includes: restarting the instance corresponding to any microservice among multiple microservices; pulling any corresponding deployment-state patch according to the environment of any microservice and copying it to the specified directory of the instance; based on the successful startup of the instance, any deployment-state patch takes effect.

[0023] In this technical solution, the corresponding instance of any microservice is restarted and, based on the deployment environment of the microservice, the corresponding deployment-state patch is pulled to the instance's designated directory. If the microservice instance successfully starts, the deployment patch is considered effective and converted to a fixed-state patch. If the microservice fails to start successfully, verification fails, and the corresponding patch is withdrawn, returning to the pre-deployment version state.

[0024] In any of the above technical solutions, before obtaining the original patch, the patch deployment method further includes: receiving the original patch compiled and generated by the user based on business needs, and storing the original patch.

[0025] In this embodiment, (development) users only need to compile and generate original patches in the current environment according to business needs, and upload them to the deployment system of the business system. The deployment system receives the original patches and stores them.

[0026] According to another aspect of the present invention, a patch deployment device is provided, comprising: a memory storing a program; and a processor implementing the patch deployment method according to any of the above technical solutions when executing the program.

[0027] The patch deployment device provided by the present invention implements the steps of the patch deployment method of any of the above technical solutions when the processor executes the program. Therefore, the patch deployment device includes all the beneficial effects of the patch deployment method of any of the above technical solutions.

[0028] According to another aspect of the present invention, a readable storage medium is provided, on which a program is stored. When the program is executed by a processor, the patch deployment method according to any of the above technical solutions is implemented.

[0029] The readable storage medium provided by the present invention implements the steps of the patch deployment method of any of the above technical solutions when the program is executed by the processor, so the readable storage medium includes all the beneficial effects of the patch deployment method of any of the above technical solutions.

[0030] Additional aspects and advantages of the invention will become apparent from the description which follows, or may be learned by practice of the invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the following description of the embodiments with reference to the accompanying drawings, in which:

[0032] Figure 1 A schematic diagram showing a flow chart of a patch deployment method according to a first embodiment of the present invention is shown;

[0033] Figure 2 A schematic flow chart showing a patch deployment method according to a second embodiment of the present invention is shown;

[0034] Figure 3 A schematic diagram showing a flow chart of a patch deployment method according to a third embodiment of the present invention is shown;

[0035] Figure 4 A schematic flow chart showing a patch deployment method according to a fourth embodiment of the present invention is shown;

[0036] Figure 5 A schematic diagram showing a flow chart of a patch deployment method according to a fifth embodiment of the present invention is shown;

[0037] Figure 6 A schematic diagram of a process for verifying any one of a plurality of deployed patches is shown in an embodiment of the present invention;

[0038] Figure 7 A schematic block diagram showing a patch deployment apparatus according to an embodiment of the present invention is shown;

[0039] Figure 8 A schematic block diagram showing a patch deployment device according to a specific embodiment of the present invention is shown;

[0040] Figure 9 A schematic diagram showing the association relationship between business entities in a specific embodiment of the present invention;

[0041] Figure 10 A schematic diagram of patch state transition in a specific embodiment of the present invention is shown;

[0042] Figure 11 A schematic diagram showing the patch directory structure and the conversion between the original state and the deployed state according to a specific embodiment of the present invention is shown. DETAILED DESCRIPTION

[0043] In order to more clearly understand the above-mentioned objects, features and advantages of the present invention, the present invention is further described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that the embodiments of the present invention and the features therein can be combined with each other without conflict.

[0044] In the following description, many specific details are set forth to facilitate a full understanding of the present invention. However, the present invention may also be implemented in other ways different from those described herein. Therefore, the scope of protection of the present invention is not limited to the specific embodiments disclosed below.

[0045] According to an embodiment of one aspect of the present invention, a patch deployment method is provided.

[0046] Example 1: Figure 1 The following is a flow chart of a patch deployment method according to a first embodiment of the present invention. The patch deployment method includes:

[0047] Step 102: Obtain the original patch and determine the corresponding multiple microservices;

[0048] Step 104: Split the original patch into multiple patches corresponding to multiple microservices;

[0049] Step 106: deploy the multiple patches to the multiple microservices to obtain the corresponding multiple deployed patches;

[0050] Step 108: verify any deployed patch among the multiple deployed patches;

[0051] Step 110: If the verification succeeds, any deployed patch is converted to a solidified patch; if the verification fails, a patch rollback operation is performed.

[0052] The patch deployment method provided in this embodiment first obtains the original patch, which is a compressed patch package compiled by developers in the current development environment according to business needs. Then, by performing patch analysis on the original patch, the multiple microservices corresponding to it in the cloud native context are determined. Then, by splitting the original patch into multiple patches corresponding to multiple microservices, and deploying multiple patches to multiple microservices, the monomer architecture of the original patch is automatically converted into the microservice architecture in the cloud native context, and the state of the patch is correspondingly converted from the original state to the deployed state. Finally, any patch in the deployed state (deployed state patch) is verified. If the verification is successful, that is, when the corresponding microservice startup patch takes effect, the state of this any patch is converted from the deployed state to the solidified state; if the verification fails, the patch rollback operation is performed to roll back the current version of the patch library to the patch library version before patching (before deployment). Through the patch deployment method of this embodiment, the development model and deployment model of the business system are separated. On the one hand, the details of cloud-native microservices can be shielded from developers, and developers only need to focus on the business logic of their own fields. On the other hand, different roles perceive different parts of patch management in a complex cloud-native environment, greatly reducing the complexity and difficulty of patch management of cloud-native applications.

[0053] Example 2: Figure 2 A schematic flow chart of a patch deployment method according to a second embodiment of the present invention is shown. The patch deployment method includes:

[0054] Step 202: Obtain the original patch and determine the corresponding multiple microservices;

[0055] Step 204: Split the original patch into multiple patches corresponding to multiple microservices;

[0056] Step 206: Deploy the multiple patches to the multiple microservices to obtain the corresponding multiple deployed patches.

[0057] Step 208: verify any deployed patch among the multiple deployed patches;

[0058] Step 210: If the verification succeeds, any deployed patch is converted to a solidified patch; if the verification fails, a patch rollback operation is performed;

[0059] Step 212: Create an image version based on the multiple fixed-state patches corresponding to the multiple deployed-state patches.

[0060] In this embodiment, after the deployed patch passes the verification, it is converted into a solidified patch, and the solidified patch can be used to make an image. Multiple solidified patches that are deployed and take effect at one time can be solidified into a new image version. Of course, it is also possible to quickly make a new image version by pulling a patch library of a specified version based on constraints such as different environments and different online time windows. Through the embodiments of the present invention, the patch testing scenario can be divided into patch pulling, patch deployment, and patch verification with patches as the management dimension according to the characteristics of customer patch management in the delivery state, different environments, and different online time windows. The online environment uses the image as the management dimension, and the specified version of the patch library can be pulled to quickly make and launch the image, roll back the deployment, etc., to maintain a stable online environment, reduce the complexity of the patch deployment strategy under the multi-environment characteristics for testers, and reduce the complexity of patch version management under the multi-image characteristics for operation and maintenance personnel.

[0061] Example 3, Figure 3 A schematic flow chart of a patch deployment method according to a third embodiment of the present invention is shown. The patch deployment method includes:

[0062] Step 302: Obtain the original patch and determine the corresponding patch directory based on the original patch code;

[0063] Step 304: Determine the business scenario associated with the original patch based on the patch catalog;

[0064] Step 306: Determine multiple corresponding microservices based on the associated business scenarios;

[0065] Step 308: Split the original patch into multiple patches corresponding to multiple microservices;

[0066] Step 310: Deploy multiple patches to multiple microservices, obtain multiple corresponding deployed patches, and generate corresponding patch deployment records;

[0067] Step 312: verify any deployed patch among the multiple deployed patches;

[0068] Step 314: If the verification succeeds, any deployed patch is converted to a solidified patch; if the verification fails, a patch rollback operation is performed;

[0069] Step 316: Create an image version based on the multiple fixed-state patches corresponding to the multiple deployed-state patches.

[0070] In this embodiment, the original patch is analyzed to determine the corresponding microservices. The original patch is split into multiple patches corresponding to the microservices, and the multiple patches are deployed to the microservices. A patch deployment record is generated. The deployment record is used for troubleshooting and problem location, thus reducing the complexity of patch version management in the multi-image feature for operations and maintenance personnel.

[0071] In this embodiment, the business scenarios involved in the original patch are analyzed, specifically, by analyzing the patch directory structure of the original patch. Each business scenario corresponds to a microservice, thereby determining the multiple microservices corresponding to the original patch. Through this embodiment of the present invention, the original patch of the monolithic architecture is automatically converted to a microservice architecture in a cloud-native context, thereby enabling patch management in a multi-user environment with different user scenarios.

[0072] Example 4: Figure 4 A schematic flow chart of a patch deployment method according to a fourth embodiment of the present invention is shown. The patch deployment method includes:

[0073] Step 402: Obtain the original patch and determine the corresponding patch directory based on the original patch code;

[0074] Step 404: Determine the business scenario associated with the original patch based on the patch catalog;

[0075] Step 406: Determine multiple corresponding microservices based on the associated business scenarios;

[0076] Step 408: Split and merge the original patches according to multiple preset patch rules associated with the business scenarios to obtain multiple patches corresponding to multiple microservices.

[0077] Step 410: deploy multiple patches to multiple microservices, obtain multiple corresponding deployed patches, and generate corresponding patch deployment records;

[0078] Step 412: verify any deployed patch among the multiple deployed patches;

[0079] Step 414: If the verification succeeds, any deployed patch is converted to a solidified patch; if the verification fails, a patch rollback operation is performed.

[0080] Step 416: Create an image version based on the multiple solidified patches corresponding to the multiple deployed patches.

[0081] In this embodiment, multiple preset patch rules are associated with business scenarios. Each preset patch rule includes logic for splitting functional module services and deployment logic based on variables such as resource file paths. This allows the original patch to be split into multiple functional modules. Since each microservice can contain multiple functional modules, and different microservices may contain the same functional modules due to business needs, multiple functional modules can be merged to obtain multiple patches corresponding to multiple microservices.

[0082] The preset patch rules may be pre-set before the software is released.

[0083] In one embodiment of the present invention, a plurality of preset patch rules are used to define the functional modules and associated image versions included in any microservice among a plurality of microservices.

[0084] In this embodiment, each business scenario corresponds to a microservice. Implementing a business scenario typically requires multiple functional modules, so a microservice typically includes multiple functional modules. Each of the multiple pre-set patch rules defines a microservice, specifically the functional modules involved and the associated image versions. Therefore, based on the multiple pre-set patch rules associated with the business scenario, the original patch can be split and merged to obtain multiple patches corresponding to multiple microservices.

[0085] Example 5, Figure 5 The flowchart of the patch deployment method according to the fifth embodiment of the present invention is shown. The verification method includes:

[0086] Step 502: Receive the original patch generated by the user based on the business requirements and store the original patch;

[0087] Step 504: Obtain the original patch and determine the corresponding patch directory based on the original patch code;

[0088] Step 506: Determine the business scenario associated with the original patch based on the patch catalog;

[0089] Step 508: Determine multiple corresponding microservices based on the associated business scenarios;

[0090] Step 510: Split and merge the original patches according to multiple preset patch rules associated with the business scenarios to obtain multiple patches corresponding to multiple microservices.

[0091] Step 512: Deploy the multiple patches to the multiple microservices, obtain the corresponding multiple deployed patches, and generate corresponding patch deployment records;

[0092] Step 514: verify any deployed patch among the multiple deployed patches;

[0093] Step 516: If the verification succeeds, any deployed patch is converted to a solidified patch; if the verification fails, a patch rollback operation is performed;

[0094] Step 518: Create an image version based on the multiple solidified patches corresponding to the multiple deployed patches.

[0095] In this embodiment, (development) users only need to compile and generate original patches in the current environment according to business needs, and upload them to the deployment system of the business system. The deployment system receives the original patches and stores them.

[0096] Example 6, Figure 6 The following is a flow chart showing a method for verifying any one of multiple deployed patches according to an embodiment of the present invention. The verification method includes:

[0097] Step 602: Restart the instance corresponding to any microservice among the multiple microservices;

[0098] Step 604: Pull any deployment state patch corresponding to any microservice environment and copy it to the specified directory of the instance;

[0099] Step 606: Based on the successful startup of the instance, any deployment state becomes effective.

[0100] In this embodiment, the corresponding instance of any microservice is restarted and, based on the deployment environment of the microservice, the corresponding deployment-state patch is pulled to the instance's designated directory. If the microservice instance successfully starts, the deployment patch is considered effective and the deployment-state patch is converted to a fixed-state patch. If the microservice fails to start successfully, verification fails, and the corresponding patch is rolled back, returning to the pre-deployment state.

[0101] According to another embodiment of the present invention, a patch deployment device is provided.

[0102] Example 1: Figure 7 A schematic block diagram of a patch deployment apparatus 700 according to an embodiment of the present invention is shown, wherein the patch deployment apparatus 700 comprises: a memory 702 storing a program; and a processor 704 executing the program to implement the patch deployment method according to any of the above embodiments.

[0103] The patch deployment apparatus 700 provided in this embodiment implements the steps of the patch deployment method of any of the above embodiments when the processor 704 executes the program. Therefore, the patch deployment apparatus 700 includes all the beneficial effects of the patch deployment method of any of the above embodiments.

[0104] A specific embodiment provides a patch deployment device. This device primarily uses Git as a patch version management tool, mapping patch management to underlying Git operations. Patch deployment is mapped to Git commits, patch rollbacks are mapped to Git rollbacks, and creating a mirror image of a specific version is mapped to pulling patches of a specific tag version. The patch splitting, analysis, and deployment logic are based on the business logic of business microservices.

[0105] Based on the characteristics of customer patch management in the delivery state, different environments, and different online time windows, patch application scenarios are mainly divided into the following: the test environment uses patches as the management dimension for patch pulling, patch deployment, and patch verification; the online environment uses images as the management dimension. By pulling the patch library of a specified version, you can quickly create and launch images, roll back deployments, and maintain a stable online environment.

[0106] Related concepts

[0107] Patch: A collection of patch files based on a specific code version, targeting a defect or adding new features;

[0108] Configuration file: environment variables that vary depending on the environment;

[0109] Image: A relatively stable version of the service code.

[0110] Service: Configuration file + service image + patch version form an independent deployment and operation unit in the microservice environment;

[0111] Deployment record (deployrecord): A record of a patch deployment in an environment by associating it with a user scenario;

[0112] Patch library: A library of patches submitted in a certain order to form a specific time node.

[0113] User scenario: A set of rules that determine the patch splitting and deployment behavior;

[0114] Patch rules (rules): determine the rules of patch management behavior, affecting patch splitting, merging, deployment, and effectiveness, etc.

[0115] Environment: Configuration file + multiple services (image + patch version). The environment is a runtime environment formed by the configuration file plus multiple services.

[0116] Business operation explanation:

[0117] Patch submission (commit): Based on a specific code version, the patch file is submitted to the patch library to form a new version of the patch library;

[0118] Patch analysis (analyze): Split and merge patches based on module-based service splitting logic and deployment logic based on variables such as resource file paths;

[0119] Patch deployment (deploy): The runtime service obtains a specific version of the patch library and takes effect at runtime;

[0120] Patch rollback: roll back the current version of the patch library to the version before the patch was applied;

[0121] Make an image (makeimage): solidify the patch library of a specific version and the current image into a new image version.

[0122] Figure 8 The schematic diagram of the patch deployment device according to a specific embodiment of the present invention is shown. The patch deployment device includes: a patch management module, a file management module, a code repository management module, a patch deployment module, an image management module, and a service module.

[0123] The core part is the patch management module, which includes all user interactions and the core patch management process, and is mainly responsible for uploading, downloading, deleting, analyzing, deploying, and rolling back patches; the file management module is mainly responsible for the storage operation of the original patch file; the code repository management is responsible for the version management of the patch, and the various operations of the user on the patch are mapped to the operations on the code repository. After the user analyzes the patch through the patch management service, the user's deployment of the patch corresponds to the submission operation of the code repository, and the revocation of the patch corresponds to the rollback of the code in the code repository; the patch deployment module is mainly responsible for pulling patches according to environment variables, deleting patches, and other operations. Business services mainly use the patch deployment module to deploy and take effect patches. The image service mainly uses the patch deployment module to pull patches to create different image versions.

[0124] Figure 9A schematic diagram illustrating the business entity association relationships in a specific embodiment of the present invention is shown. An environment consists of a set of runtime services, a set of configuration files, and a patch library. An independently running service consists of a specific version of an image, a set of environment-specific configuration files, and a set of patches related to the services in that environment. After patches are analyzed and deployed in a certain order, a versioned patch library is formed. After a patch is deployed according to multiple rules associated with multiple user scenarios selected during deployment, it is split into patches involving multiple services and deployed, forming a patch deployment record. A user scenario can be associated with multiple rules, and each rule determines patch management behavior.

[0125] Figure 10 The figure shows a schematic diagram of patch status transition in a specific embodiment of the present invention, which mainly illustrates several different states of the patch under different business operations.

[0126] 1. Original patch. This patch is compiled into a zip archive by developers or R&D personnel in a development environment based on business needs. The patch structure lacks dimensions like the service environment, separating the development model from the deployment model of the business system. Therefore, traditional ERP developers can be shielded from the details of the cloud-native microservices in the deployment model, allowing them to focus solely on the business logic within their domain. Once a developer creates a patch and uploads it to the patch management system, their responsibilities are fulfilled.

[0127] 2. Analyze patches. Taking the NC Cloud system as an example, Figure 11 This section demonstrates the typical patch directory structure and the transition between the original and deployed states, using the NC Cloud system as an example. Different business systems can define different patch directory structures through configuration rules. Analytical patches primarily refer to original patches, which, based on associated user business scenarios, influence the patch directory structure and patch lifecycle according to patch rules. This adds dimensions such as environment, service, and time to the patch. It's worth noting that core patches must be deployed by all microservices. Patch analysis is typically performed by environmental operations personnel.

[0128] A typical patch rule is as follows: a product contains multiple patch rules. Each rule can define which modules the microservice contains and which associated image versions are effective.

[0129] 3. Deployment state patch. The original state patch is analyzed according to the patch rules. The user then selects the environment and user scenario for deployment (which actually corresponds to a commit push in GIT). The patch status is then converted from analysis state to deployment state, and a patch deployment record is generated. The microservices involved in the patch are restarted. The main process for patch deployment to take effect is as follows:

[0130] Step 1: Restart the business service;

[0131] Step 2: Execute the patch management status startup script;

[0132] Step 3: Pull the patch for the specified environment;

[0133] Step 4: Copy the core patch to the specified directory;

[0134] Step 5: Copy the service patch to the specified directory;

[0135] Step 6: The service starts and the patch takes effect.

[0136] 4. Solidified patches. After a deployed patch is tested by testers, if the patch verification fails, the patch rollback process is used to roll back the environment to the state before the patch was deployed. If the verification succeeds, the patch is marked as solidified (success). Based on the launch window for the production environment, all solidified patches are tagged in the patch repository and mirrored.

[0137] This embodiment provides a patch management device for cloud-native applications, which separates the development model and the deployment model. Different roles perceive different parts of patch management in a complex cloud-native environment, greatly reducing the complexity and difficulty of patch management for cloud-native applications.

[0138] Based on the characteristics of customer patch management in the delivery state, different environments, and different online time windows, patch application scenarios are mainly divided into the following: the test environment uses patches as the management dimension for patch pulling, patch deployment, and patch verification; the online environment uses images as the management dimension. By pulling the patch library of a specified version, you can quickly create and launch images, roll back deployments, and maintain a stable online environment.

[0139] According to another aspect of the present invention, a readable storage medium is provided, on which a program is stored. When the program is executed by a processor, the patch deployment method according to any of the above embodiments is implemented.

[0140] The readable storage medium provided by the present invention implements the steps of the patch deployment method of any of the above embodiments when the program is executed by a processor. Therefore, the readable storage medium includes all the beneficial effects of the patch deployment method of any of the above embodiments.

[0141] The patch deployment method, patch deployment device, and readable storage medium provided by various embodiments of the present invention can implement patch management in a multi-user environment under different user scenarios, thereby achieving the following objectives:

[0142] Shield developers from the patch splitting and merging logic under the multi-service feature;

[0143] Reduces the complexity of patch version management under the multi-image feature for operation and maintenance personnel;

[0144] Reduce the complexity of patch deployment strategies in multiple environments for testers;

[0145] Provides support for features such as multi-user scenarios and multiple patch management strategies.

[0146] In this specification, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance, unless otherwise expressly specified or limited. Terms such as "connect," "install," and "fix" should be interpreted broadly. For example, "connect" can refer to a fixed connection, a detachable connection, or an integral connection; and can be directly connected or indirectly connected through an intermediary. Those skilled in the art will understand the specific meanings of these terms in the present invention based on specific circumstances.

[0147] Throughout this specification, terms such as "one embodiment," "some embodiments," and "specific embodiments" mean that the specific features, structures, materials, or characteristics described in conjunction with that embodiment or example are included in at least one embodiment or example of the present invention. In this specification, schematic representations of these terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

[0148] The foregoing description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Those skilled in the art will readily appreciate that various modifications and variations of the present invention are possible. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention are intended to be within the scope of protection of the present invention.

Claims

1. A patch deployment method, characterized in that: include: Get the original patch and determine the corresponding microservices; Splitting the original patch into multiple patches corresponding to the multiple microservices; Deploy the multiple patches to the multiple microservices to obtain corresponding multiple deployed patches; Verifying any deployed patch among the multiple deployed patches; Upon successful verification, any deployed patch is converted into a solidified patch; Perform patch rollback in case of verification failure; The original patch is a compressed patch package compiled by developers in the current development environment according to business needs; The patch deployment method further includes: Creating an image version according to the multiple solidified patches corresponding to the multiple deployed patches; After the step of deploying the plurality of patches to the plurality of microservices, the method further includes: Generate corresponding patch deployment records; The step of determining the corresponding multiple microservices specifically includes: Determine a corresponding patch directory based on the original patch code; Determining a business scenario associated with the original patch according to the patch catalog; Determine the multiple microservices according to the business scenario; Each of the business scenarios corresponds to one of the microservices, thereby determining a plurality of the microservices corresponding to the original patch; The step of splitting the original patch into multiple patches corresponding to the multiple microservices specifically includes: Splitting and merging the original patches according to multiple preset patch rules associated with the business scenario to obtain multiple patches corresponding to the multiple microservices; The preset patch rules include the splitting logic of functional module services and the deployment logic based on resource file paths; The splitting and merging of the original patches according to the plurality of preset patch rules associated with the business scenario to obtain a plurality of patches corresponding to the plurality of microservices specifically includes: According to multiple preset patch rules associated with the business scenario, the original patch is split into multiple functional modules, and the multiple functional modules are merged through deployment logic based on resource file paths to obtain multiple patches corresponding to the multiple microservices.

2. The patch deployment method according to claim 1, characterized in that: Any one of the multiple preset patch rules is used to define the functional modules and associated image versions included in any one of the multiple microservices.

3. The patch deployment method according to claim 2, characterized in that: The step of verifying any deployed patch among the multiple deployed patches specifically includes: Restarting an instance corresponding to any microservice among the multiple microservices; Pull the corresponding deployment state patch according to the environment of any microservice and copy it to the specified directory of the instance; Based on the successful startup of the instance, any deployment-state patch takes effect.

4. The patch deployment method according to claim 3, wherein: Before obtaining the original patch, the method further includes: The original patch generated by the user based on business requirements is received, and the original patch is stored.

5. A patch deployment device, characterized in that: include: a memory storing a program; A processor, wherein when executing the program, the processor implements the patch deployment method according to any one of claims 1 to 4.

6. A readable storage medium having a program stored thereon, characterized in that: When the program is executed by a processor, the patch deployment method according to any one of claims 1 to 4 is implemented.

Images