Automatic upgrading system of server component, readable medium and electronic equipment

Abstract

The invention relates to the technical field of computers, and discloses an automatic upgrading system of a server component, a readable medium and electronic equipment. The system comprises an upgrade change module, a test deployment module, a test verification module, a component release module and a result detection module, sub-code branch creation and automatic code reconstruction can be performed in a dependency mode, and a sidecar process is determined in a sidecar mode; creating and deploying a test environment to perform functional test and code verification; after that, the code merging request is initiated in the dependency mode to request to merge the update of the sub-code branches into the main code branch, or online gray release is gradually performed to full release in the sidecar mode, and the result detection of the component upgrade progress is performed, so that the compatibility and stability of the component upgrade can be comprehensively detected and verified, and the reliability of the component upgrade is improved. And moreover, codes do not need to be modified manually in the whole process, the automation degree is high, and high-efficiency and low-cost centralized closed-loop component upgrading is realized.

Description

Technical Field

[0001] The embodiments of the present disclosure relate to the field of computer technology, and more specifically, relate to an automatic upgrade system for server components, a computer-readable medium, and an electronic device. Background Art

[0002] This section is intended to provide a background or context to the embodiments of the disclosure that are recited in the claims, and no description herein is admitted to be prior art by inclusion in this section.

[0003] In the microservice architecture, with the continuous expansion of application scale, the gradual deepening of detailed splitting and the further development of business, the cost of systematic and large-scale upgrades is high and time-consuming. At present, the abstract syntax tree of source code can be built through the OpenRewrite open source framework to batch reconstruct source code and automatically change code versions.

[0004] The above solution only assists at the nodes where the code is changed. However, whether the code changes in the application upgrade can be implemented stably still needs further verification, resulting in limited reduction in cost and time consumption. In addition, when facing large-scale and complex application upgrades, there are certain risks in its stability and compatibility. Summary of the invention

[0005] In this context, embodiments of the present disclosure are intended to provide a method for automatically upgrading a server component, an apparatus for automatically upgrading a server component, a computer-readable medium, and an electronic device.

[0006] According to a first aspect of an embodiment of the present disclosure, there is provided an automated upgrade system for server-side components, which may include: an upgrade change module for creating a sub-code branch based on a main code branch of a server-side application in response to a component upgrade request in a dependency mode, and calling an automated upgrade plug-in corresponding to a target version to reconstruct the sub-code branch; the automated upgrade plug-in corresponding to the target version is configured with an upgrade rule for upgrading the component to the target version; or, an upgrade change module for determining a sidecar process corresponding to a component of a target version in response to a component upgrade request in a sidecar mode; a test deployment module for creating a first test environment and deploying the sub-code branch in the first test environment in a dependency mode; or, a test deployment module for creating a second test environment and deploying the sidecar process in the second test environment in a sidecar mode; a test verification module for Triggering automated test cases in the test environment or the second test environment to perform functional testing, and perform code verification based on continuous integration; a component release module, which is used to initiate a code merge request with the main code branch based on the sub-code branch when the functional test and code verification pass in the dependency mode; or, a component release module, which is used to perform an online grayscale release of the sidecar process when the functional test and code verification pass in the sidecar mode, and to perform an online full release of the sidecar process when the grayscale release passes; a result detection module, which is used to detect the component dependency version of the main code branch and the component dependency version of the online environment in the dependency mode to determine the component upgrade progress; or, a result detection module, which is used to perform an exception verification after the grayscale release of the sidecar process and the full release of the sidecar process in the sidecar mode to determine the component upgrade progress.

[0007] In an optional embodiment of the present disclosure, the upgrade change module is further used to perform dependency analysis on the reconstructed sub-code branch in dependency mode to determine the components of the target version that the server application depends on.

[0008] In an optional embodiment of the present disclosure, the result detection module is also used to perform an online rollback in the sidecar mode when the exception verification of the grayscale release fails, record the result of the exception verification, and terminate the component upgrade progress; or, the result detection module is also used to perform an online rollback in the sidecar mode when the exception verification of the full release fails, record the result of the exception verification, and terminate the component upgrade progress.

[0009] In an optional embodiment of the present disclosure, the system also includes: a component management module, which is used to manage the release of the original version of the component in the component repository, and to classify the original version of the component, and the classification management includes at least one of the following: classification management based on risk identification; classification management based on version compatibility between components.

[0010] In an optional embodiment of the present disclosure, the component management module also generates a component upgrade request for the original version with risks based on the classification management based on risk identification.

[0011] In an optional embodiment of the present disclosure, the component management module is also used to determine the target version of the component upgrade request in the original version compatible between components based on the classification management of version compatibility between components, and when the original version compatible between components does not include the online running version of the component, generate a corresponding component upgrade request for the original version compatible between components.

[0012] In an optional embodiment of the present disclosure, the system also includes an upgrade task module for generating a component upgrade request in response to selecting an upgrade range for a component to a target version; the component upgrade range includes a source version range of the component, a separately selected server-side application, and at least one of all server-side applications that depend on the component.

[0013] In an optional embodiment of the present disclosure, the upgrade task module is further used to determine the component pre-upgrade range based on the component upgrade range when the component upgrade range is greater than or equal to the predetermined range, and the component pre-upgrade range is smaller than the component upgrade range; the upgrade task module is further used to generate a component pre-upgrade request based on the component pre-upgrade range, so that the upgrade change module, the test deployment module, the test verification module, the component release module and the result detection module perform the component pre-upgrade within the component pre-upgrade range in response to the component pre-upgrade request; the upgrade task module is further used to generate a component upgrade request based on the component upgrade range when there is no abnormality in the component pre-upgrade.

[0014] In an optional embodiment of the present disclosure, the upgrade task module is also used to execute a retry strategy corresponding to the abnormal failure when any of the upgrade change module, test deployment module, test verification module, component release module and result detection module fails abnormally.

[0015] In an optional embodiment of the present disclosure, the upgrade task module is also used to schedule tasks for at least one of the upgrade change module, the test deployment module, the test verification module, the component release module and the result detection module; or, the upgrade task module is also used to perform task statistics for at least one of the upgrade change module, the test deployment module, the test verification module, the component release module and the result detection module.

[0016] In an optional embodiment of the present disclosure, at least one of the upgrade change module, test deployment module, test verification module, component release module and result detection module performs current limiting during execution; or, at least one of the upgrade change module, test deployment module, test verification module, component release module and result detection module releases resource occupation at the end of execution.

[0017] In an optional embodiment of the present disclosure, the upgrade change module, the test deployment module, the test verification module, the component release module and the result detection module adopt a message notification mechanism based on the message middleware and support idempotent consumption.

[0018] In an optional embodiment of the present disclosure, at least one of the upgrade change module, the test deployment module, the test verification module, the component release module and the result detection module supports independent extension based on hook technology.

[0019] In an optional embodiment of the present disclosure, at least one of the upgrade change module, the test deployment module, the test verification module, the component release module and the result detection module supports visualization of the execution process and execution exceptions.

[0020] According to a second aspect of the embodiments of the present disclosure, there is provided a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements a module of the automatic upgrade system of any of the above-mentioned server-side components.

[0021] According to a third aspect of an embodiment of the present disclosure, there is provided an electronic device, comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute a module of an automated upgrade system for any of the above-mentioned server-side components by executing the executable instructions.

[0022] According to the automatic upgrade system of the server-side component of the embodiment of the present disclosure, the system includes an upgrade change module, a test deployment module, a test verification module, a component release module and a result detection module. In the dependency mode, it is possible to create a sub-code branch based on the main code branch in response to the component upgrade request, and call the automatic automatic upgrade plug-in on the sub-code branch for reconstruction, as well as automatically deploy the test environment and the sub-code branch, perform functional testing and code verification in the test environment, and after passing, initiate a sub-code merge request and determine the component upgrade progress based on the main code branch and the component dependency version of the online environment. In the sidecar mode, it is possible to determine the sidecar process corresponding to the component of the target version in response to the component upgrade request, and then perform functional testing and code verification through the automatic deployment of the test environment and the sidecar process, and after passing, the sidecar process is grayed out and fully released, and after the grayed out and fully released, abnormal verification is performed to determine the component upgrade progress. The system connects the full process nodes under different upgrade modes of the component through platformization, and realizes the automated construction and execution of the full process of component upgrade. In dependency mode, you can create sub-code branches and automate code refactoring, and in sidecar mode, determine the sidecar process; then create and deploy a test environment for functional testing and code verification; after passing, initiate a code merge request in dependency mode to request that the sub-code update be merged into the main code, or in sidecar mode, conduct an online grayscale release gradually to a full release, and perform a result test on the progress of component upgrades. The system can fully test and verify the compatibility and stability of component upgrades to ensure normal online operation, and the entire process does not require manual code modification, with a high degree of automation, to achieve efficient and low-cost centralized closed-loop component upgrades. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The above and other objects, features and advantages of the exemplary embodiments of the present disclosure will become readily understood by reading the detailed description below with reference to the accompanying drawings. In the accompanying drawings, several embodiments of the present disclosure are shown in an exemplary and non-limiting manner, in which:

[0024] Figure 1 One of the structural schematic diagrams of the automatic upgrade system of the server component according to the embodiment of the present disclosure is shown.

[0025] Figure 2 A schematic diagram of the structure of an automatic upgrade plug-in according to an embodiment of the present disclosure is shown.

[0026] Figure 3 A schematic diagram of component upgrade process execution in dependency mode of the automatic upgrade system of the server-side component according to an embodiment of the present disclosure is shown.

[0027] Figure 4A schematic diagram of component upgrade process execution in the sidecar mode of the automatic upgrade system of the server-side component according to an embodiment of the present disclosure is shown.

[0028] Figure 5 One of the page schematic diagrams of the automatic upgrade system of the server component according to the embodiment of the present disclosure is shown.

[0029] Figure 6 A second page schematic diagram of the automatic upgrade system of the server-side component according to an embodiment of the present disclosure is shown.

[0030] Figure 7 The second structural diagram of the automatic upgrade system of the server component according to the embodiment of the present disclosure is shown.

[0031] Figure 8 The third structural diagram of the automatic upgrade system of the server component according to the embodiment of the present disclosure is shown.

[0032] Fig. 9 A third page schematic diagram of the automatic upgrade system of the server-side component according to an embodiment of the present disclosure is shown.

[0033] Fig.10 A fourth structural diagram of the automatic upgrade system of the server-side component according to an embodiment of the present disclosure is shown.

[0034] Fig.11 A schematic diagram of a computer readable medium illustrating an embodiment of the present disclosure is shown.

[0035] Fig.12 A schematic diagram of an electronic device according to an embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0036] The principles and spirit of the present disclosure will be described below with reference to several exemplary embodiments. It should be understood that these embodiments are provided only to enable those skilled in the art to better understand and implement the present disclosure, and are not intended to limit the scope of the present disclosure in any way. On the contrary, these embodiments are provided to make the present disclosure more thorough and complete, and to fully convey the scope of the present disclosure to those skilled in the art.

[0037] Those skilled in the art will appreciate that the embodiments of the present disclosure may be implemented as a system, device, apparatus, method or computer program product. Therefore, the present disclosure may be specifically implemented in the following forms, namely: complete hardware, complete software (including firmware, resident software, microcode, etc.), or a combination of hardware and software.

[0038] According to an embodiment of the present disclosure, a method for automatically upgrading a server component, an apparatus for automatically upgrading a server component, a computer-readable medium, and an electronic device are provided.

[0039] In this document, any number of elements in the drawings is used for illustration rather than limitation, and any naming is used only for distinction and does not have any limiting meaning.

[0040] The principle and spirit of the present disclosure are explained in detail below with reference to several representative embodiments of the present disclosure.

[0041] Component refers to the JAR (Java Archive) package, which is essentially a compression package based on the ZIP standard. It can package and reuse classes to modularize the code.

[0042] Server applications refer to applications running on servers in a computer network, which can provide services to client applications. Server applications are usually used to process and respond to requests from clients, perform specific functions, and return results to clients. Their functions can be implemented by calling dependent components.

[0043] The scale of server-side applications is large and grows linearly. With the development of microservices, they are further split and refined. The construction and development of different businesses require the coordination of different manpower and system docking for application upgrades and maintenance, which is costly and inefficient. On this basis, it also leads to a long technology implementation cycle, high maintenance costs for multiple versions, and difficulty in overall promotion during large-scale application upgrades. There are also a lot of component version compatibility and stability risks.

[0044] To address the above issues, OpenRewrite can currently be used to perform code refactoring to assist component upgrades. However, this code refactoring cannot cope with complex large-scale application upgrades, and there are component version conflicts in the actual upgrade process, resulting in compatibility and stability risks in actual deployment and operation.

[0045] In the embodiments of the present disclosure, an automated upgrade system for server-side components is provided. The system connects the full-process nodes in different component upgrade modes through platformization to achieve automated construction and execution of the entire component upgrade process. In dependency mode, sub-code branches can be created and automated code refactoring can be performed, and in sidecar mode, the sidecar process can be determined; then a test environment is created and deployed for functional testing and code verification; after passing, a code merge request is initiated in dependency mode to request that the sub-code update be merged into the main code, or in sidecar mode, an online grayscale release is gradually released to a full release, and the progress of the component upgrade is detected. The system can comprehensively detect and verify the compatibility and stability of component upgrades to ensure normal online operation, and the entire process does not require manual code modification, with a high degree of automation, to achieve efficient and low-cost centralized closed-loop component upgrades.

[0046] After introducing the basic principles of the present invention, various non-limiting embodiments of the present invention are described in detail below.

[0047] Exemplary application scenarios

[0048] It should be noted that the following application scenarios are only shown to facilitate understanding of the spirit and principle of the present invention, and the embodiments of the present disclosure are not limited in this respect. On the contrary, the embodiments of the present disclosure can be applied to any applicable scenario.

[0049] The automated upgrade system for server-side components of the disclosed embodiment can be applied to a variety of application scenarios involving component upgrades, component risk management, and component release testing.

[0050] In one application scenario, the automated upgrade system based on the server-side component can perform large-scale and complex server-side application architecture upgrades, such as JDK (Java Development Kit) upgrades, computer room migration upgrades, and other scenarios.

[0051] In another application scenario, it may also involve component risk management, monitoring and maintaining the compatibility and stability of running components; or it may also involve component release testing. In the development of new functions and technologies, there may be problems with insufficient coverage of compatibility and stability testing scenarios. Based on the automatic upgrade system of the server-side component, a wide range of tests can be performed. The embodiments of the present disclosure do not specifically limit this.

[0052] Exemplary Systems

[0053] In combination with the above application scenarios, Figure 1 The automatic upgrade system of the server component according to the exemplary embodiment of the present disclosure is described.

[0054] like Figure 1 One of the structural schematic diagrams of the automatic upgrade system (hereinafter referred to as the system) 100 of the server-side component of the exemplary embodiment of the present disclosure may include an upgrade change module 101, a test deployment module 102, a test verification module 103, a component release module 104 and a result detection module 105.

[0055] In the embodiments of the present disclosure, based on the differences in actual deployment architectures, in order to adapt to different execution conditions and upgrade requirements, the system 100 provides component upgrade modes in dependency mode and sidecar mode. Among them, the dependency mode is aimed at the scenario where the server application implements functions based on the components that it depends on based on code calls; the sidecar mode is aimed at the scenario where the server application is decoupled from the components, in which the sidecar process is deployed next to the server application to expand the functions of the server application. The scenarios targeted by the dependency mode usually require code changes for upgrades, while the scenarios targeted by the sidecar mode have certain scalability, flexibility and reusability because the sidecar process is decoupled from the server application and can be independently deployed, upgraded and maintained, and shared among multiple server applications. However, there are compatibility and stability risks in the overall upgrade process. For this reason, the system 100 provided in the embodiments of the present disclosure can implement a centralized closed-loop component upgrade process in the dependency mode and the sidecar mode.

[0056] In the system 100 , the upgrade change module 101 is used to respond to a component upgrade request to a server application to start a component upgrade process.

[0057] In the disclosed embodiment, a component upgrade request refers to a request to upgrade a component corresponding to a server application to a target version. The requesting party may provide information about the server application, component, and target version, or the system 100 may provide information about different server applications and components to the requesting party, and the requesting party may select the server application, component, and target version, and then initiate a component upgrade request. In response to the component upgrade request, the upgrade change module 101 may determine the server application to be upgraded, as well as configuration information of the upgrade task, including the component to be upgraded, and the target version to which the component is to be upgraded.

[0058] Among them, the upgrade change module 101 is used to create a sub-code branch based on the main code branch of the server application in response to the component upgrade request in the dependency mode, and call the automatic upgrade plug-in corresponding to the target version to reconstruct the sub-code branch; the automatic upgrade plug-in corresponding to the target version is configured with upgrade rules for upgrading the component to the target version.

[0059] In the disclosed embodiment, the main code branch of the server application generally refers to the code branch of the stable version. The stable version can be the version in actual operation, and also the version to be upgraded corresponding to the component upgrade request. In the dependency mode, in response to the component upgrade request, the upgrade change module 101 can automatically create a sub-code branch based on the main code branch of the server application, and execute the component upgrade process based on the sub-code branch, which can avoid affecting the main code branch.

[0060] Furthermore, the automated upgrade plug-in is configured with an upgrade rule for upgrading the component to a specific version. The upgrade rule may be a rule for changing the code, and by executing the automated upgrade plug-in, the code can be automatically reconstructed to make it dependent on a component of a specific version. In the embodiment of the present disclosure, corresponding automated upgrade plug-ins may be preset based on different component versions, and when responding to a component upgrade request to upgrade to a target version, the automated upgrade plug-in of the target version is called to reconstruct the sub-code branch. At this point, the automated upgrade plug-in corresponding to the target version is configured with an upgrade rule for upgrading the component to the target version, and the reconstructed sub-code branch should depend on the component of the target version. In an optional embodiment of the present disclosure, OpenRewrite may be further developed, and different automated upgrade plug-ins for specific versions of components may be developed based on its code reconstructing function for invocation by the upgrade change module 101.

[0061] like Figure 2 The schematic diagram of the structure of the automatic upgrade plug-in of the exemplary embodiment of the present disclosure is shown. The automatic upgrade plug-in corresponding to a specific version can be pre-built and stored, and the target version of the component upgrade request can be pulled to perform subsequent code refactoring. The component upgrade request can correspond to multiple target versions, so that multiple different automatic upgrade plug-ins can be pulled, and different automatic upgrade plug-ins can execute different upgrade rules to perform code refactoring. Figure 2 In the figure, the automatic upgrade plug-in corresponding to specific versions 1, 2, etc. is shown, which is further developed and implemented based on OpenRewrite. Taking the automatic upgrade plug-in corresponding to the specific version 1 as an example, the configuration files, code files, etc. can be updated or corrected, and the dependencies of the components can also be updated. Specifically, the dependency update includes the update of the parent POM (Project Object Model), that is, in the case of no declaration of update of the child POM, the child POM is updated to the corresponding specific version 1 based on the update of the parent POM to update its defined dependencies; or, in the case of declaration, the dependent component is upgraded to the specific version 1, or in the case of declaration, the specific version 1 of the component is excluded. The function of the automatic upgrade plug-in can be designed and developed according to the actual component upgrade requirements, and the embodiments of the present disclosure do not impose specific restrictions on this.

[0062] In an optional embodiment of the present disclosure, the upgrade change module 101 is further used to perform dependency analysis on the reconstructed sub-code branch in dependency mode to determine the components of the target version that the server application depends on.

[0063] In an embodiment of the present disclosure, on the basis of calling the automatic upgrade plug-in corresponding to the target version to reconstruct the sub-code branch, branch verification can be performed on the sub-code branch to determine whether the sub-code has been reconstructed, and whether the reconstruction meets the component upgrade requirements, so as to avoid the situation where the automatic upgrade plug-in may call and execute errors that lead to the failure of the reconstruction of the sub-code branch. Specifically, a dependency analysis can be performed on the reconstructed sub-code branch to determine that the component on which the server application depends on the reconstructed sub-code branch is the target version corresponding to the component upgrade request. In an optional embodiment of the present disclosure, Maven can be used to perform dependency analysis on the reconstructed sub-code branch. Maven is a tool for project construction and dependency management. It can determine the components that the server application depends on based on dependency analysis, and then perform branch verification by determining whether the component version of the dependent component is the target version. Those skilled in the art can also choose other methods or tools to perform dependency analysis according to actual needs and deployment and implementation conditions. The embodiment of the present disclosure does not impose specific restrictions on this.

[0064] Alternatively, the upgrade change module 101 is used to determine the sidecar process corresponding to the target version of the component in response to a component upgrade request in the sidecar mode.

[0065] In the embodiment of the present disclosure, the components in the sidecar mode are deployed in the form of sidecar processes, and the server-side application is decoupled from the sidecar process, so that the upgrade of the component side has a low impact on the code of the server-side application. At this time, in response to the component upgrade request, it is sufficient to determine the sidecar process corresponding to the target version of the component. In an optional embodiment of the present disclosure, the sidecar process can be implemented with technologies such as Java Agent and Service Mesh, and the embodiment of the present disclosure does not specifically limit this.

[0066] In the system 100 , the test deployment module 102 is used to automatically create a test environment and perform deployment.

[0067] In the disclosed embodiment, the test environment may be created according to the online environment of the server application to implement compatibility and stability testing of the upgraded component version.

[0068] The test deployment module 102 is used to create a first test environment and deploy a sub-code branch in the first test environment in a dependency mode.

[0069] In the embodiment of the present disclosure, in the dependency mode, a first test environment that meets the testing requirements of the server application corresponding to the component upgrade request can be created, and a sub-code branch reconstructed by the upgrade change module 101 can be deployed in the first test environment. The sub-code branch represents the component of the target version that the server application depends on.

[0070] Alternatively, the test deployment module 102 is used to create a second test environment and deploy a sidecar process in the second test environment in the sidecar mode.

[0071] In the disclosed embodiment, in the sidecar mode, a second test environment that meets the testing requirements can be created based on the server application corresponding to the component upgrade request. The server application can be deployed in the second test environment. Further, a sidecar process corresponding to the target version of the component can be added to the second test environment to expand the functionality of the server application.

[0072] In the system 100, the test verification module 103 is used to trigger the automated test cases in the first test environment or the second test environment to perform functional testing, and to perform code verification based on continuous integration.

[0073] In the embodiment of the present disclosure, in the first test environment in the dependency mode, or in the second test environment in the sidecar mode, functional testing based on automated test cases and code verification based on continuous integration can be performed. Among them, functional testing can verify whether the business logic can be carried out smoothly and completely through the execution of automated test cases. In the embodiment of the present disclosure, there is no restriction on the source of automated test cases, which can be manually written and maintained based on test requirements, or can be built based on automated generation tools. In the case where the automated test cases cannot be triggered, manual testing can also be performed, and the embodiment of the present disclosure does not specifically limit this.

[0074] Furthermore, code verification based on continuous integration (CI) is automatically triggered by code changes to verify whether the changed code is correct. Generally, the component upgrade code changes in the dependency mode are large, and the necessity of code verification is higher. However, since there may be a small amount of code changes in the sidecar mode, there is also a certain demand for code verification.

[0075] In the system 100, the component publishing module 104 is used to publish the component upgrade online after passing the test.

[0076] The component publishing module 104 is used to initiate a code merge request with the main code branch based on the sub-code branch when the functional test and code verification are passed in the dependency mode.

[0077] In the embodiment of the present disclosure, in the dependency mode, when the sub-code branch is deployed in the first test environment after reconstruction and passes the functional test and code verification, it can be considered that it has passed the nodes of pre-upgrade change, environment deployment, test verification, etc. of component automatic upgrade. At this time, a code merge request to the main code branch can be initiated based on the sub-code branch to request the developer to merge the sub-code branch into the main code branch to implement the component upgrade on the main code branch.

[0078] Alternatively, the component release module 104 is used to perform an online grayscale release of the sidecar process when the functional test and code verification pass in the sidecar mode, and to perform an online full release of the sidecar process when the grayscale release passes.

[0079] In the disclosed embodiment, in the sidecar mode, the sidecar process corresponding to the target version of the component is deployed in the second test environment, and when it passes the functional test and code verification, it can be considered that it has passed the pre-upgrade change, environment deployment, test verification and other nodes of the component automatic upgrade. At this time, the sidecar process can be grayed out online, and the release scope can be gradually expanded to full release if the grayed out release passes.

[0080] In the system 100, the result detection module 105 is used to detect the results published by the components.

[0081] In the disclosed embodiment, a result detection module 105 is also configured to detect the working status of the component in the online environment during the component release process, so as to determine the progress of the component upgrade. When the component is fully released and there is no abnormality in the status detection, it can be determined that the component upgrade is completed and the component automatic upgrade process initiated in response to the component upgrade request is completed.

[0082] The result detection module is used to detect the component dependency version of the main code branch and the component dependency version of the online environment in dependency mode to determine the progress of component upgrades.

[0083] In the disclosed embodiment, after initiating a code merge request in dependency mode, the component dependency version of the main code branch can be detected. When the component dependency version of the main code branch is the target version corresponding to the component upgrade request, it is determined that the code merge is completed. Furthermore, the component dependency version of the server-side application in the online environment can also be detected offline. When the component dependency version of the online environment is the target version corresponding to the component upgrade request, it can be determined that the code merge is completed and has been released to the online environment, thereby determining that the process of automatic component upgrade is completed.

[0084] The result detection module is used to perform exception verification after the sidecar process is released in grayscale in sidecar mode, and to perform exception verification after the sidecar process is fully released to determine the progress of component upgrades.

[0085] In the disclosed embodiment, the sidecar process can be released in the sidecar mode. The grayscale release method can be used to first release to some machines in the online environment. If there are no abnormalities in the operation after the release, the release scope can be gradually expanded until the full release. For example, it can be released to one or more machines in a single cluster first, and then gradually expanded to all machines in a single cluster, multiple clusters, and all clusters, etc. Among them, the abnormal verification can be implemented by executing test cases online.

[0086] In an optional embodiment of the present disclosure, the result detection module 105 is also used to perform online rollback in the sidecar mode when the abnormal verification of the grayscale release fails, record the result of the abnormal verification, and terminate the component upgrade progress.

[0087] In an optional embodiment of the present disclosure, the result detection module 105 is also used to perform online rollback in the sidecar mode when the exception verification of the full release fails, record the result of the exception verification, and terminate the component upgrade progress.

[0088] In the disclosed embodiment, when a component release scheme from grayscale release to full release is adopted in the sidecar mode, during the release process, an exception verification can be performed each time the release scope is expanded, and the subsequent release process can be continued when the sidecar process runs correctly, until the full release determines that the component automatic upgrade process is completed; or, when the exception verification of grayscale release or full release fails, the released machine is rolled back online to return it to a version that can run normally, and the results of the exception verification are recorded for subsequent problem analysis and processing, and the component upgrade progress is terminated, ending the component automatic upgrade process.

[0089] In an optional embodiment of the present disclosure, at least one of the upgrade change module 101, the test deployment module 102, the test verification module 103, the component release module 104 and the result detection module 105 performs current limiting during execution.

[0090] In the disclosed embodiment, when the upgrade and change module 101, the test deployment module 102, the test verification module 103, the component release module 104 and the result detection module 105 execute the component automatic upgrade process, the execution process of at least one module is limited. When the server application is upgraded on a large scale, a large amount of resources need to be occupied for changes, deployment, verification and other work. Based on the example calculation that each server application occupies 2 cores and 4G memory, 1000 server applications need to occupy 2000 cores and 4000G memory, which may lead to resource shortage or even shortage. Therefore, by limiting the flow, it is possible to avoid the occupation of a large amount of resources by upgrade changes, environment deployment, test verification and other work, reasonably optimize resource utilization, and reduce the impact on other businesses.

[0091] In an optional embodiment of the present disclosure, at least one of the upgrade change module 101, the test deployment module 102, the test verification module 103, the component release module 104 and the result detection module 105 releases resource occupation when execution ends.

[0092] In the disclosed embodiment, when the upgrade change module 101, the test deployment module 102, the test verification module 103, the component release module 104 and the result detection module 105 execute the component automatic upgrade process, resource occupation can be released when at least one module is executed to avoid occupying excess resources after the execution is completed, resulting in low effective resource utilization and affecting other businesses. Among them, part of the resource occupation is released when the module executes the preceding node of the component automatic upgrade process, and all resource occupation can be released in time when the component automatic upgrade process ends. Furthermore, during the execution of the test deployment module 102, the cluster executing the test can be directly released at the end of each step of the test regardless of whether the test result is passed or not, so as to avoid excessive resource occupation during large-scale application upgrades. When the test result fails, the exception log can be completely saved for subsequent problem analysis and troubleshooting.

[0093] In an optional embodiment of the present disclosure, the upgrade change module 101, the test deployment module 102, the test verification module 103, the component release module 104 and the result detection module 105 adopt a message notification mechanism based on the message middleware and support idempotent consumption.

[0094] In the disclosed embodiment, a message notification mechanism is implemented between the upgrade change module 101, the test deployment module 102, the test verification module 103, the component release module 104 and the result detection module 105 in the system based on the message middleware, and the message is received and consumed through the message queue to realize the automatic flow, task routing and asynchronous execution of different task nodes such as upgrade change, test deployment, test verification, component release, etc. in the component automatic upgrade process. Furthermore, idempotent consumption can also be performed on the message, so that the effect produced by any multiple executions is the same as the effect produced by one execution, so as to avoid the impact of repeated consumption.

[0095] In an optional embodiment of the present disclosure, at least one of the upgrade change module 101, the test deployment module 102, the test verification module 103, the component release module 104 and the result detection module 105 supports independent extension based on the hook technology.

[0096] In the disclosed embodiment, the upgrade change module 101, the test deployment module 102, the test verification module 103, the component release module 104 and the result detection module 105 can independently support asynchronous notification extensions and call extensions based on hook technology. Hook technology is a message processing mechanism that can insert custom processing logic when a specific event occurs to modify or expand system functions. The task node of a single module in the component upgrade process in the system 100 can be divided into pre-processing, pre-hook, processing logic, post-hook, and post-processing. When receiving a message notification of the task node startup, the pre-processing, pre-hook to processing logic stage is performed. In this process, execution information can be recorded, including normal information or abnormal information. The processing logic can be executed normally or skipped according to the actual instructions. Information statistics can be performed from the processing logic to the post-hook and post-processing stages, and a startup message is sent to the module of the next task node according to the component upgrade process. Each stage of a single module can be independently extended to access the system 100 by services of other applications based on hook technology.

[0097] In an optional embodiment of the present disclosure, at least one of the upgrade change module 101, the test deployment module 102, the test verification module 103, the component release module 104 and the result detection module 105 supports visualization of the execution process and execution exceptions.

[0098] In the disclosed embodiment, in the component upgrade process of the upgrade change module 101, the test deployment module 102, the test verification module 103, the component release module 104 and the result detection module 105, the information of the execution process and execution exceptions can be collected, recorded and visualized, thereby reducing the cost of troubleshooting when the components are automatically upgraded.

[0099] like Figure 3 FIG. 1 is a schematic diagram showing the component upgrade process execution of the automatic upgrade system 100 of the server component in the dependency mode according to an exemplary embodiment of the present disclosure. In the dependency mode, Figure 3 As shown, upon receiving a component upgrade request of a target version, the upgrade change module 101 executes the following steps A11 to A13:

[0100] Step A11: Create a sub-code branch based on the main code branch of the server application.

[0101] Step A12: call the automatic upgrade plug-in of the target version to reconstruct the sub-code branch.

[0102] Step A13: Perform dependency analysis on the reconstructed sub-code branch to determine the components of the target version that the server application depends on on the sub-code branch.

[0103] At this time, the upgrade and change module 101 has been executed, and a message can be sent to notify the test deployment module 102 to execute the next task node, and then the test deployment module 102 executes the following steps A21 to A22.

[0104] Step A21: Create a first test environment.

[0105] Step A22: deploy the sub-code branch in the first test environment, and check to confirm that the deployment is successful.

[0106] At this point, the test deployment module 102 has completed execution and can send a message to notify the test verification module 103 to execute the next task node, and then the test deployment module 103 executes the following steps A31 to A32.

[0107] Step A31: triggering automated test cases in the first test environment to perform functional testing.

[0108] Step A32: Perform code verification based on continuous integration in the first test environment.

[0109] At this time, the test verification module 103 has been executed and can send a message to notify the component publishing module 104 to execute the next task node, and then the component publishing module 104 executes the following step A41.

[0110] Step A41: Initiate a code merge request to the main code branch based on the sub-code branch.

[0111] At this time, the component publishing module 104 has completed execution and can send a message to notify the result detection module 105 to execute the next task node, and then the result detection module 105 can execute the following steps A51 to A52.

[0112] Step A51: Detect the component dependency version of the main code branch to determine whether the code merge is complete.

[0113] Step A52: Detect component dependency versions of server applications in the online environment to determine component upgrade progress.

[0114] When the component dependency version of the detection server application is the target version when deployed in the online environment, the result detection module 105 is executed, and it is determined that the component upgrade process is completed. The sub-code branch can be deleted, and all resource occupation is released.

[0115] like Figure 4 FIG. 1 is a schematic diagram showing the component upgrade process execution of the automatic upgrade system 100 of the server component in the sidecar mode according to an exemplary embodiment of the present disclosure. Figure 4 As shown, upon receiving a component upgrade request of a target version, the upgrade change module 101 performs the following step B11:

[0116] Step B11: Determine the sidecar process corresponding to the component of the target version.

[0117] At this time, the upgrade and change module 101 has been executed, and a message can be sent to notify the test deployment module 102 to execute the next task node, and then the test deployment module 102 executes the following steps B21 to B22.

[0118] Step B21: Create a second test environment.

[0119] Step B22: deploy the sidecar process in the second test environment, and check to confirm that the deployment is successful.

[0120] At this point, the test deployment module 102 has completed execution and can send a message to notify the test verification module 103 to execute the next task node, and then the test deployment module 103 executes the following steps B31 to B32.

[0121] Step B31: triggering automated test cases in the second test environment to perform functional testing.

[0122] Step B32: Perform code verification based on continuous integration in the second test environment.

[0123] At this time, the test verification module 103 has been executed and can send a message to notify the component publishing module 104 to execute the next task node, and then the component publishing module 104 executes the following step B41.

[0124] Step B41: Perform a grayscale release of the sidecar process online.

[0125] At this time, the component publishing module 104 has completed execution and can send a message to notify the result detection module 105 to execute the next task node, and then the result detection module 105 can execute the following step A51.

[0126] Step A51: Perform exception verification after the sidecar process is released in grayscale.

[0127] At this time, the result detection module 105 has been executed and can send a message to notify the component publishing module 104 to execute the next task node, and then the component publishing module 104 can execute the following step A42.

[0128] Step A42: If the abnormal verification of the grayscale release passes, the sidecar process is fully released online.

[0129] At this time, the component publishing module 104 has completed execution and can send a message to notify the result detection module 105 to execute the next task node, and then the result detection module 105 can execute the following step A52.

[0130] Step A52: Perform exception verification after the sidecar process is fully released.

[0131] When the sidecar process deployed in the online environment passes the abnormal verification after the full release, the result detection module 105 is executed, and it is determined that the component upgrade process is completed, and all resource occupation can be released.

[0132] like Figure 5 One of the page schematic diagrams of the automatic upgrade system of the server-side component of the exemplary embodiment of the present disclosure is shown. It can be seen that this page is a visual display of the "upgrade progress" in the component upgrade process of the X city computer room migration drill in the dependency mode. In the selection bar, you can also select the visual display of information such as "upgrade report", "task configuration", and "upgrade confirmation".

[0133] Furthermore, the server-side application can be divided according to the development team to which it belongs. In the development team options, development team 1 includes 1 server-side application, and its total upgrade progress is 82%; development team 2 includes 3 server-side applications, and its total upgrade progress is 82%; development team 3 includes 6 server-side applications, and its total upgrade progress is 82%; development team 4 includes 4 server-side applications, and its total upgrade progress is 73%. When there are multiple development teams, you can search for the team name in the search bar to locate the corresponding development team option. The server-side application options can be displayed by expanding the corresponding development team options, such as expanding the development team 1 option to display the corresponding server-side application 1 option.

[0134] The upgrade progress of "all" upgrade tasks is displayed in the details display area of ​​the page, and the options of "view method rewrite list" and "view operation log" are provided for the requester or other operation and maintenance parties to view specific code change records and operation log records. Further, the execution status of each node is briefly displayed through the display of task flow, including creating branches, version upgrades, test deployment, test verification, code merging, merge detection, etc., wherein the creation of branches includes but is not limited to the operation of creating sub-code branches in response to component upgrade requests, the version upgrade execution includes but is not limited to the operation of calling the automatic upgrade plug-in to refactor the code of the sub-code branch, the test deployment execution includes but is not limited to the operation of creating a test environment and deploying sub-code branches, the test verification execution includes but is not limited to the operation of functional testing and code verification of sub-code branches, the code merge execution includes but is not limited to the operation of initiating a code merge request to merge to the main code branch, and the merge detection execution includes but is not limited to the operation of detecting the component dependency version of the main code branch. The above nodes may be executed separately by different modules in the system, or they may be executed in sequence by the same module. The execution status of each node may include the number of completions, the number of failures, in progress, not started, closed, etc., and the current task node is indicated in the merge detection by referring to this page.

[0135] In the details display area of ​​the page, the server applications are displayed in separate lines by application name, and the task status of the server application is displayed in the same line. Taking server application 1 as an example, its total progress is 82%, the total execution time is 1h38m, the current process node is merging the main code branch detection, the current number of retries is 3, and the execution summary indicates that the server application 1 "main code branch detection failed, please merge the code" to initiate a code merge request. Different operation options are also provided for server application 1 in the same line, including "retry", that is, re-merge detection, "skip", that is, no longer merge detection, and "restart", that is, re-pull the sub-code branch from the main code branch to start the component upgrade process. Other server applications can be deduced in this way.

[0136] On this basis, batch operation options of "retry all", "pause all" and "continue all" are also provided for all server applications.

[0137] like Figure 6 The second page schematic diagram of the automatic upgrade system of the server component of the exemplary embodiment of the present disclosure is shown. Figure 5 Based on the selection of the application name of the service order application, a visual display of the detailed data of each process node of the server application in the upgrade task can be provided. The detailed data includes success status, change details, failure log, failure reason, retry interval, maximum number of retries, current number of retries, R&D operation instructions, etc.

[0138] Taking server application 1 as an example, after selection, brief status information of each node is displayed in the form of task flow, including branch creation, version upgrade, test deployment, test verification, successful code merge, failed merge check, and online check and resource release that have not started.

[0139] On this basis, selecting any node can visualize its detailed data. Taking the version upgrade node as an example, after selecting it, it will show that the execution is successful, and the task node operation information includes "Create a sub-code branch and execute the upgrade", the start and end time "2024-02-25 09:52:43-2024-02-25 10:02:59", the number of executions is 2 times, and the name and Git address of the sub-code branch, etc., as well as specific change details, including file name, change type, and the option to view diff (difference).

[0140] like Figure 7 The second structural diagram of the automatic upgrade system (hereinafter referred to as the system) 700 of the server-side component of the exemplary embodiment of the present disclosure may include an upgrade change module 701, a test deployment module 702, a test verification module 703, a component release module 704, a result detection module 705 and a component management module 706.

[0141] In the embodiment of the present disclosure, the upgrade change module 701, the test deployment module 702, the test verification module 703, the component release module 704 and the result detection module 705 in the system 700 may correspond to the relevant descriptions of the upgrade change module 101, the test deployment module 102, the test verification module 103, the component release module 104 and the result detection module 105 in the aforementioned system 100, and will not be repeated here to avoid repetition.

[0142] In the system 700, the component management module 706 is used to control the release of the original version of the component in the component repository, and to classify and manage the original version of the component.

[0143] In the disclosed embodiment, the component warehouse is used to store original versions of components, which may include different original versions of different components. The components released to the component warehouse can be applied to the expansion and upgrade of server-side applications in the R&D process. The system 700 can also control the release of the original versions of components in the component warehouse, such as performing quality inspection on the original versions of components based on the test verification function of the system 700, or performing stability and compatibility risk tests on different original versions of different components, etc., and combining the collaboration of the modules of the system 700 to systematically and platformize the release of the original versions of components.

[0144] In the embodiment of the present disclosure, on the basis of the original version release control of the component, the original version of the component can also be classified and managed. The rules for classifying the original version can be set by those skilled in the art according to actual business needs.

[0145] In an optional embodiment of the present disclosure, category management may include category management based on risk identification.

[0146] Among them, risk identification can be based on the risk represented by the test verification results of the component when there are multiple original versions of the component. For example, the original versions of the component include version 1.0 and version 2.0. Version 1.0 was developed earlier and has relatively simple functions, but it has been tested and verified to be stable and has a lower risk, so it can be classified as a stable version; version 2.0 was developed later and has more diverse functions, but it has been tested and verified to have a probability of crashing during operation, and has a higher risk, so it can be classified as a risky version.

[0147] In an optional embodiment of the present disclosure, the classification management may include classification management of version compatibility between components.

[0148] Among them, based on the fact that the server-side application is extended by multiple components, there are also compatibility risks between different versions of components. For example, the original version of component a may include version a 1.0 and version a 2.0, and the original version of component b may include version b1.0 and version b 2.0. When version a 1.0 and version b 1.0 are stable and compatible, version a 2.0 may conflict with version b 1.0 and fail to run normally. Unified version management based on compatibility between components can distinguish the combination of original versions of different components that have conflicts and can run normally, and realize classification management.

[0149] In an optional embodiment of the present disclosure, the component management module 706 also generates a component upgrade request for the original version with risks based on the classification management based on risk identification.

[0150] In the disclosed embodiments, the classification management of the original version based on risk identification can be further applied to the generation of component upgrade requests to further improve the automation level and upgrade effect of component automatic upgrades. For example, when the target version corresponding to the component upgrade request is classified as a risk version, a risk reminder of the target version can be provided to the requester, and a method for triggering a component upgrade request corresponding to a stable version can be provided; or, when the original version of the component is classified as a risk version, the component running version of the server-side application in the online environment can be analyzed, and a component upgrade request can be generated for the risky running version to automatically trigger the component upgrade process. The risk reminder of the running version can also be provided to the operator of the server-side application, and a method for triggering a component upgrade request corresponding to a stable version can be provided. On this basis, insight into the risk version is achieved, and the component automatic upgrade process is linked to perform component risk management.

[0151] In an optional embodiment of the present disclosure, the component management module 706 is also used to determine the target version of the component upgrade request in the original version compatible between components based on the classification management of version compatibility between components, and when the original version compatible between components does not include the online running version of the component, generate a corresponding component upgrade request for the original version compatible between components.

[0152] In the disclosed embodiments, the classification management of the original version based on the compatibility of versions between components can be further applied in the generation of component upgrade requests to further improve the degree of automation and upgrade effect of automatic component upgrades. For example, the original version compatible between components of the target version corresponding to the component upgrade request can be determined based on the classification management of the compatibility of versions between components. The original version compatible between components refers to the original version compatible with the target version among multiple components of the server-side application. When the original version compatible with the target version between components does not include the online running version of the component of the server-side application, a corresponding component upgrade request can be generated for the original version compatible with the target version between components to upgrade different components of the server-side application to corresponding versions compatible with the target version in one process.

[0153] like Figure 8 The structural diagram of the automatic upgrade system (hereinafter referred to as the system) 800 of the server-side component of the exemplary embodiment of the present disclosure shown may include an upgrade change module 801, a test deployment module 802, a test verification module 803, a component release module 804, a result detection module 805 and an upgrade task module 806.

[0154] In the embodiment of the present disclosure, the upgrade change module 801, the test deployment module 802, the test verification module 803, the component release module 804 and the result detection module 805 in the system 800 may correspond to the relevant descriptions of the upgrade change module 101, the test deployment module 102, the test verification module 103, the component release module 104 and the result detection module 105 in the aforementioned system 100, and will not be repeated here to avoid repetition.

[0155] In the system 800, the upgrade task module 806 is used for the management and statistics of component upgrade tasks.

[0156] In an optional embodiment of the present disclosure, the upgrade task module 806 generates a component upgrade request in response to selecting an upgrade scope for a component to a target version; the component upgrade scope includes a source version range of the component, a separately selected server-side application, and at least one of all server-side applications that depend on the component.

[0157] In the disclosed embodiment, the server application, component, original version and other information can be provided to the requester, and the requester's selection of the component to the upgrade range can be received to generate a corresponding component upgrade request. The source version range of the component in the component upgrade range includes all versions of the component request to be upgraded to the target version.

[0158] For example, the component a of server application 1 is version a1.0, the component a of server application 2 is version a2.0, the component a of server application 3 is version a1.0, and the component a of server application 4 is version a3.0. At this time, the target version is version a4.0 of component a, and the component upgrade range is version a1.0 and version a2.0, then the component upgrade request indicates that the component a of server applications 1, 2, and 3 is upgraded to version a4.0.

[0159] A server application that is selected individually means that only the components of the server application are upgraded to the target version.

[0160] For example, the target version is version a4.0 of component a, and the component upgrade scope is server application 3, then the component upgrade request indicates that component a of server application 3 is upgraded to version a4.0.

[0161] All server-side applications that depend on the component, indicating that all server-side applications that depend on the component are upgraded to the target version.

[0162] For example, if the target version is version a4.0 of component a, and the component upgrade scope is all server applications that depend on component a, then the component upgrade request indicates that component a of server applications 1, 2, 3, and 4 is upgraded to version a4.0.

[0163] like Fig. 9 The third page schematic diagram of the automatic upgrade system of the server-side component of the exemplary embodiment of the present disclosure is shown. The page provides selection items for the component upgrade range, wherein the "Component" column provides selection of components, the "Source Version Range" provides selection of source versions, the "Target Version" column provides selection of target versions, and the "Component Type" provides selection of component file types. On this basis, the "Add" option and the "Delete" option for the component upgrade range are also provided. This page supports the setting of Jar package source and target version, and can be precisely controlled to avoid incorrect upgrades.

[0164] In an optional embodiment of the present disclosure, the upgrade task module 806 is also used to determine the component pre-upgrade range based on the component upgrade range when the component upgrade range is greater than or equal to the predetermined range, and the component pre-upgrade range is smaller than the component upgrade range; the upgrade task module 806 is also used to generate a component pre-upgrade request based on the component pre-upgrade range, so that the upgrade change module 801, the test deployment module 802, the test verification module 803, the component release module 804 and the result detection module 805 perform the component pre-upgrade within the component pre-upgrade range in response to the component pre-upgrade request; the upgrade task module 806 is also used to generate a component upgrade request based on the component upgrade range when there is no abnormality in the component pre-upgrade.

[0165] In the disclosed embodiment, based on the selection of the component upgrade range, when the component upgrade range is greater than or equal to the predetermined range, the upgrade can be considered as a large-scale upgrade, and then a component pre-upgrade request can be generated for the server-side application within the component pre-upgrade range, and the upgrade change module 801, the test deployment module 802, the test verification module 803, the component release module 804 and the result detection module 805 respond to the component pre-upgrade request to perform the component pre-upgrade within the component pre-upgrade range, so as to detect the compatibility and stability problems of the components in the large-scale upgrade in advance, and promote the large-scale upgrade of the component upgrade range when there is no abnormality in the component pre-upgrade to ensure the accuracy and promotion efficiency of the upgrade. Among them, the size of the predetermined range can be expressed according to the number of server-side applications involved, and can be set based on the actual hardware configuration, upgrade requirements, etc., and the component pre-upgrade range is smaller than the component upgrade range, so that the component pre-upgrade is carried out in a small range, reducing the cost of investigation.

[0166] In an optional embodiment of the present disclosure, the upgrade task module 806 is also used to execute the retry strategy corresponding to the abnormal failure when any one of the upgrade change module 801, the test deployment module 802, the test verification module 803, the component release module 804 and the result detection module 805 fails abnormally.

[0167] In the disclosed embodiment, the upgrade task module 806 can also perform control functions such as retry, skip, and close to release resource occupation for the upgrade change module 801, the test deployment module 802, the test verification module 803, the component release module 804, and the result detection module 805. On this basis, the upgrade task module 806 supports the configuration of corresponding retry strategies according to abnormal failures, including retry interval time, maximum number of retries, etc. When the corresponding retry strategy is not configured for abnormal failures, a general default retry strategy can also be set. During the execution of the module, different types of abnormal failures may occur. By flexibly configuring the corresponding retry strategy, problems arising in the component upgrade process can be solved more specifically, and the stability of the task process can be improved. The retry strategy can also adopt an attenuated retry mechanism, such as gradually extending the retry interval between two adjacent times to the maximum retry interval time during multiple retries to avoid relieving the underlying pressure.

[0168] In an optional embodiment of the present disclosure, the upgrade task module 806 is also used to schedule tasks for at least one of the upgrade change module 801 , the test deployment module 802 , the test verification module 803 , the component release module 804 and the result detection module 805 .

[0169] In the disclosed embodiment, the upgrade task module 806 can also orchestrate task nodes in the component upgrade process of the upgrade change module 801, the test deployment module 802, the test verification module 803, the component release module 804 and the result detection module 805, so as to independently customize the task process to apply different application scenarios and upgrade requirements, such as component upgrades, large-scale architecture upgrades, component compatibility testing, sidecar upgrades, sidecar compatibility testing and other application scenarios, and specify the execution logic and sequence of the modules corresponding to the modules.

[0170] In an optional embodiment of the present disclosure, the upgrade task module 806 is also used to perform task statistics on at least one of the upgrade change module 801 , the test deployment module 802 , the test verification module 803 , the component release module 804 and the result detection module 805 .

[0171] In the disclosed embodiment, the upgrade task module 806 can also support statistics on the upgrade change module 801, the test deployment module 802, the test verification module 803, the component release module 804 and the result detection module 805. The statistics can include task statistics of different dimensions such as the requester, the server application, and the component upgrade process stage, and can also include statistics on test, verification, and post-release result detection, and can also include statistics on dimensions such as the duration of process execution and advancement progress. Those skilled in the art can select the content of the task statistics according to actual needs, and the disclosed embodiment does not specifically limit this.

[0172] like Fig.10 The structural diagram of the automatic upgrade system (hereinafter referred to as the system) 1000 of the server-side component of the exemplary embodiment of the present disclosure shown may include an upgrade change module 1001, a test deployment module 1002, a test verification module 1003, a component release module 1004, a result detection module 1005, a component management module 1006 and an upgrade task module 1007.

[0173] In the embodiment of the present disclosure, the upgrade change module 1001, the test deployment module 1002, the test verification module 1003, the component release module 1004 and the result detection module 1005 in the system 1000 may correspond to the relevant descriptions of the upgrade change module 101, the test deployment module 102, the test verification module 103, the component release module 104 and the result detection module 105 in the aforementioned system 100, and will not be repeated here to avoid repetition.

[0174] The component management module 1006 in the system 1000 may correspond to the relevant description of the component management module 706 in the aforementioned system 700, and will not be described again here to avoid repetition.

[0175] The upgrade task module 1007 in the system 1000 may correspond to the relevant description of the component management module 806 in the aforementioned system 800, and will not be described again here to avoid repetition.

[0176] According to the automatic upgrade system of the server-side component of the embodiment of the present disclosure, the system includes an upgrade change module, a test deployment module, a test verification module, a component release module and a result detection module. In the dependency mode, it is possible to create a sub-code branch based on the main code branch in response to the component upgrade request, and call the automatic automatic upgrade plug-in on the sub-code branch for reconstruction, as well as automatically deploy the test environment and the sub-code branch, perform functional testing and code verification in the test environment, and after passing, initiate a sub-code merge request and determine the component upgrade progress based on the main code branch and the component dependency version of the online environment. In the sidecar mode, it is possible to determine the sidecar process corresponding to the component of the target version in response to the component upgrade request, and then perform functional testing and code verification through the automatic deployment of the test environment and the sidecar process, and after passing, the sidecar process is grayed out and fully released, and after the grayed out and fully released, abnormal verification is performed to determine the component upgrade progress. The system connects the full process nodes under different upgrade modes of the component through platformization, and realizes the automated construction and execution of the full process of component upgrade. In dependency mode, you can create sub-code branches and automate code refactoring, and in sidecar mode, determine the sidecar process; then create and deploy a test environment for functional testing and code verification; after passing, initiate a code merge request in dependency mode to request that the sub-code update be merged into the main code, or in sidecar mode, conduct an online grayscale release gradually to a full release, and perform a result test on the progress of component upgrades. The system can fully test and verify the compatibility and stability of component upgrades to ensure normal online operation, and the entire process does not require manual code modification, with a high degree of automation, to achieve efficient and low-cost centralized closed-loop component upgrades.

[0177] It should be noted that although several modules or units of the automatic upgrade system of the server-side component are mentioned in the above detailed description, this division is not mandatory. In fact, according to the embodiments of the present disclosure, the features and functions of two or more modules or units described above can be concretized in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided into multiple modules or units to be concretized.

[0178] Exemplary computer readable media

[0179] The following is a description of a computer-readable medium according to an exemplary embodiment of the present disclosure.

[0180] In this exemplary embodiment, reference Fig.11As shown, a program product 1100 for implementing the modules in the above system according to an exemplary embodiment of the present disclosure is described, such as a portable compact disk read-only memory (CD-ROM) and including program code, and can be run on a device, such as a personal computer. However, the program product of the present disclosure is not limited thereto, and in this document, a computer-readable medium can be any tangible medium containing or storing a program, which can be used by or in combination with an instruction execution system, an apparatus, or a device.

[0181] The program product 1100 may use any combination of one or more readable media. The readable medium may be a readable signal medium or a computer readable medium. The computer readable medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer readable media (a non-exhaustive list) include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0182] Computer readable signal media may include data signals propagated in baseband or as part of a carrier wave, wherein readable program code is carried. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Readable signal media may also be any readable medium other than computer readable media, which may send, propagate, or transmit programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0183] The program code contained on the readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wired, optical cable, RE, etc., or any suitable combination of the foregoing.

[0184] Program code for performing the operations of the present disclosure may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, C++, etc., and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user computing device, partially on a remote computing device, or entirely on a remote computing device or server. In the case of a remote computing device, the remote computing device may be connected to the user computing device through any type of network, including a local area network (FAN) or a wide area network (WAN), or may be connected to an external computing device (e.g., using an Internet service provider to connect through the Internet).

[0185] Exemplary Electronic Devices

[0186] refer to Fig.12 An electronic device according to an exemplary embodiment of the present disclosure is described.

[0187] Fig.12 The electronic device 1200 shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0188] like Fig.12 As shown, the electronic device 1200 is in the form of a general computing device. The components of the electronic device 1200 may include, but are not limited to: at least one processing unit 1210, at least one storage unit 1220, a bus 1250 connecting different system components (including the storage unit 1220 and the processing unit 1210), and a display unit 1240.

[0189] The storage unit stores program codes, which can be executed by the processing unit 1210, so that the processing unit 1210 executes to implement the modules according to various exemplary embodiments of the present disclosure described in the above “Exemplary System” section of this specification. For example, the processing unit 1210 can execute to implement the following Figure 1 , 7 , modules of the systems shown in 8 and 10, etc.

[0190] The storage unit 1220 may include a volatile storage unit, such as a random access storage unit (RAM) 1221 and / or a cache storage unit 1222 , and may further include a read-only storage unit (ROM) 1223 .

[0191] The storage unit 1220 may also include a program / utility 1224 having a set (at least one) of program modules 1225, such program modules 1225 including but not limited to: an operating system, one or more server applications, other program modules and program data, each of which or some combination may include an implementation of a network environment.

[0192] The bus 1250 may include a data bus, an address bus, and a control bus.

[0193] The electronic device 1200 may also communicate with one or more external devices 1300 (e.g., keyboards, pointing devices, Bluetooth devices, etc.), and such communication may be performed through an input / output (I / O) interface 1250. The electronic device 1200 also includes a display unit 1240, which is connected to the input / output (I / O) interface 1250 for display. In addition, the electronic device 1200 may also communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) through a network adapter 1260. As shown, the network adapter 1260 communicates with other modules of the electronic device 1200 through the bus 1250. It should be understood that, although not shown in the figure, other hardware and / or software modules may be used in conjunction with the electronic device 1200, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0194] It should be noted that, although several modules or submodules of the device are mentioned in the above detailed description, such division is merely exemplary and not mandatory. In fact, according to the embodiments of the present disclosure, the features and functions of two or more units / modules described above can be embodied in one unit / module. Conversely, the features and functions of one unit / module described above can be further divided into multiple units / modules to be embodied.

[0195] In addition, although the operations of the disclosed method are described in a specific order in the drawings, this does not require or imply that the operations must be performed in this specific order, or that all the operations shown must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be decomposed into multiple steps.

[0196] Although the spirit and principle of the present disclosure have been described with reference to several specific embodiments, it should be understood that the present disclosure is not limited to the disclosed specific embodiments, and the division of various aspects does not mean that the features in these aspects cannot be combined to benefit, and such division is only for the convenience of expression. The present disclosure is intended to cover various modifications and equivalent arrangements included in the spirit and scope of the attached claims.

Claims

1. An automatic upgrade system for server components, characterized in that: The system comprises: An upgrade change module is used to create a sub-code branch based on the main code branch of the server application in response to a component upgrade request in dependency mode, and call the automatic upgrade plug-in corresponding to the target version to reconstruct the sub-code branch; the automatic upgrade plug-in corresponding to the target version is configured with an upgrade rule for upgrading the component to the target version; or, the upgrade change module is used to determine the sidecar process corresponding to the component of the target version in response to the component upgrade request in sidecar mode; A test deployment module, used to create a first test environment and deploy the sub-code branch in the first test environment in dependency mode; or, the test deployment module, used to create a second test environment and deploy the sidecar process in the second test environment in sidecar mode; A test verification module, used to trigger automated test cases in the first test environment or the second test environment to perform functional testing, and to perform code verification based on continuous integration; A component release module, used to initiate a code merge request with the main code branch based on the sub-code branch when the functional test and the code verification are passed in the dependency mode; or, the component release module, used to perform an online grayscale release of the sidecar process when the functional test and the code verification are passed in the sidecar mode, and to perform an online full release of the sidecar process when the grayscale release is passed; The result detection module is used to detect the component dependency version of the main code branch and the component dependency version of the online environment in dependency mode to determine the progress of component upgrade; or, the result detection module is used to perform exception verification after the grayscale release of the sidecar process and the full release of the sidecar process in sidecar mode to determine the progress of component upgrade.

2. The system according to claim 1, characterized in that The upgrade change module is also used to perform dependency analysis on the reconstructed sub-code branch in dependency mode to determine the component of the target version that the server application depends on.

3. The system according to claim 1, characterized in that The result detection module is also used to perform an online rollback in the sidecar mode when the exception verification of the grayscale release fails, record the result of the exception verification, and terminate the component upgrade progress; or, the result detection module is also used to perform an online rollback in the sidecar mode when the exception verification of the full release fails, record the result of the exception verification, and terminate the component upgrade progress.

4. The system according to claim 1, characterized in that The system further comprises: A component management module is used to control the release of the original version of the component in the component repository and to classify the original version of the component, wherein the classification management includes at least one of the following: Classification management based on risk identification; Classification management based on version compatibility between components.

5. The system according to claim 4, characterized in that The component management module also generates a component upgrade request for the original version with risks based on the classification management based on risk identification.

6. The system according to claim 4, characterized in that The component management module is also used to determine the target version of the component upgrade request based on the classification management of version compatibility between components, and to generate a corresponding component upgrade request for the original version compatible between components when the original version compatible between components does not include the online running version of the component.

7. The system according to claim 1, characterized in that The system also includes an upgrade task module for generating a component upgrade request in response to selecting an upgrade range for a component to a target version; the component upgrade range includes a source version range of the component, the server application that is individually selected, and at least one of all the server applications that depend on the component.

8. The system according to claim 7, characterized in that The upgrade task module is further configured to determine a component pre-upgrade range based on the component upgrade range when the component upgrade range is greater than or equal to a predetermined range, and the component pre-upgrade range is smaller than the component upgrade range; The upgrade task module is further used to generate a component pre-upgrade request based on the component pre-upgrade range, so that the upgrade change module, the test deployment module, the test verification module, the component release module and the result detection module perform the component pre-upgrade within the component pre-upgrade range in response to the component pre-upgrade request; The upgrade task module is further configured to generate a component upgrade request based on the component upgrade range when there is no abnormality in the component pre-upgrade.

9. A computer-readable medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, a module in the automatic upgrade system of the server component according to any one of claims 1 to 8 is implemented.

10. An electronic device, characterized in that: An automated upgrade system for a server component according to any one of claims 1 to 8, comprising: Processor; and A memory, configured to store executable instructions of the processor; The processor is configured to implement the modules in the system by executing the executable instructions.

Images