Micro-service engineering automatic configuration method, system and device and readable storage medium

Abstract

The invention relates to the technical field of computers, in particular to a micro-service engineering automatic configuration method, system and device and a readable storage medium, and the method comprises the steps: creating a CICD pipeline script in a code warehouse; binding the pom file path, the micro-service name and the project address of the micro-service project through the front script; according to the method, unified management can be carried out on micro-service versions, version recording is carried out on depended components, and a perfect version management mechanism is provided; the problems that version upgrading is incomplete in collaborative version issuing, and micro-services not subjected to collaborative upgrading depend on component versions can be solved; and meanwhile, the method is also suitable for large-scale enterprise-level micro-service application scenes and scenes involving multi-environment, multi-micro-service engineering and multi-component collaborative change, the effects of automatic upgrade and automatic change can be achieved, the tedious process of version upgrade is greatly simplified, and the development and deployment efficiency is improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method, system, device and readable storage medium for automatic configuration of a microservice engineering. Background Art

[0002] The current microservice dependency version management mainly determines the target version identifier when receiving the reference instruction sent by the microservice; according to the target version identifier, determines the target common service code package of the common service to be introduced in the snapshot warehouse or the formal warehouse; and configures the common service code package in the service reference party that sends the reference instruction. This solution only performs version collaborative management for a single or a small number of microservices, which is cumbersome and complicated for batch microservice upgrades.

[0003] The invention patent with patent number CN111522577A discloses a method, which determines the development-side dependency package version information corresponding to the target project; sends the dependency package version request information corresponding to the target project to the preset control end, and receives the control-side dependency package version information corresponding to the target project returned by the control end; the control-side dependency package version information is the latest updated dependency package version information corresponding to the target project on the control end; according to the control-side dependency package version information, the development-side dependency package version information is verified; wherein, if the development-side dependency package version information is the same as the control-side dependency package version information, the target project is run; otherwise, the version of the dependency package corresponding to the target project is updated on the development end according to the control-side dependency package version information, and then the target project is run. This method uses manual upgrades rather than automated dependency package version upgrades. In addition, each microservice is released independently and has different deployment environments. It is difficult to quickly coordinate changes and upgrades, and there may be version incompatibility between applications released in different environments.

[0004] To this end, a unified dependency version management for enterprise-level microservices is proposed to reduce the process of manually upgrading and coordinating versions of all other microservices that reference this version of the component due to an upgrade of a dependent component. At the same time, the efficiency of R&D assistance is improved, the cumbersome process of version upgrades in microservice development is simplified, and various version problems caused by incomplete version coordinated upgrades in microservice deployment and startup are reduced. This is a technical problem that needs to be urgently solved by technical personnel in this field. Summary of the invention

[0005] The purpose of this application is to solve at least one of the above technical defects. The technical solution adopted by this application is as follows:

[0006] In a first aspect, an embodiment of the present application provides a method for automatically configuring a microservice project, the method comprising:

[0007] Create CICD pipeline scripts in the code repository;

[0008] Bind the pom file path, microservice name, and project address of the microservice project through the pre-script;

[0009] Automatically trigger the pipeline to obtain the information and parameters required for subsequent automatic upgrades.

[0010] Optionally, after the pre-script is executed, when the project needs to publish components to a remote repository, include:

[0011] Create a tag for publishing components;

[0012] Triggering a release component pipeline, the pipeline is used for component release function;

[0013] Execute the preceding script to obtain relevant information of the current project;

[0014] Use the mvn deploy command to publish components;

[0015] Write the GAV coordinate information of the published components into the database to record the version information;

[0016] Notify other microservice projects that this project has released new dependent components;

[0017] Create automated upgrade tags for other microservice projects through the code repository API.

[0018] Optionally, after the execution of the pre-script is completed, when other microservice projects automatically upgrade the newly released components, including:

[0019] Trigger the automated upgrade pipeline;

[0020] Parse the GAV coordinate information in the pom file;

[0021] Match and compare the version number. If the version number in the library is higher, update the versionID in the pom file.

[0022] Update the component version information in the pom files of all modules;

[0023] Push the updated code back to the project.

[0024] Optionally, writing the GAV coordinate information of the published component into a database to record the version information includes:

[0025] The date of the published component, GAV coordinate information, publishing environment, publishing project ID, and status flag.

[0026] Optionally, the automatic upgrade tags for creating other microservice projects through the code repository API include:

[0027] The other microservice projects are projects that reference the component and are configured for automatic upgrades. After the corresponding projects are configured in advance, when the current component releases a new version to trigger the pipeline, the automatic upgrade tag labels of other microservice projects that reference the component are automatically created to trigger the automatic upgrade pipeline.

[0028] Optionally, the matching and comparing of version numbers, if the version number in the library is higher, updating the versionID in the pom file, includes:

[0029] If the verisonID version number in the library is smaller than the version number parsed in the pom file, the current component version number will not be updated.

[0030] In a second aspect, the present invention provides a microservice engineering automated configuration system, the system comprising: a creation module, a binding module, and an acquisition module, wherein:

[0031] Create module: used to create CICD pipeline scripts in the code repository;

[0032] Binding module: used to bind the pom file path, microservice name and project address of the microservice project through the pre-script;

[0033] Acquisition module: used to automatically trigger the pipeline to obtain the information and parameters required for subsequent automated upgrades.

[0034] In a third aspect, the present invention provides an electronic device, including a processor and a memory;

[0035] The memory is used to store operation instructions;

[0036] The processor is used to execute the above-mentioned microservice engineering automatic configuration method by calling the operation instruction.

[0037] In a fourth aspect, the present invention provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the method for automatically configuring the above-mentioned microservice engineering is implemented.

[0038] In a fifth aspect, the present invention provides a computer program product, which includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the above-mentioned method for automated configuration of microservice engineering is fully or partially executed.

[0039] The microservice engineering automation configuration solution disclosed in this application creates a CICD pipeline script in the code repository; binds the pom file path, microservice name and project address of the microservice project through the pre-script; and automatically triggers the pipeline to obtain the information and parameters required for subsequent automated upgrades. The technical solution provided by this application brings the following beneficial effects:

[0040] 1. The present invention can efficiently manage the problem of coordinated version upgrades among multiple microservices, automatically upgrade the versions of microservice dependent components, and perform version upgrades without manual notification, which greatly simplifies the cumbersome process of version upgrades and improves development and deployment efficiency;

[0041] 2. The present invention is also applicable to multi-environment deployment modes. For different environments, there may be inconsistent versions of dependent components referenced by microservices. The present invention can distinguish them according to the environment and complete version isolation between different environments. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in describing the embodiments of the present application.

[0043] Figure 1 A schematic diagram of a process flow of a microservice engineering automation configuration method provided in an embodiment of the present application;

[0044] Figure 2 A schematic diagram of a process flow of a microservice engineering automation configuration method provided in an embodiment of the present application;

[0045] Figure 3 A schematic diagram of a process flow of a microservice engineering automation configuration method provided in an embodiment of the present application;

[0046] Figure 4 A flowchart of the specific steps of a microservice engineering automation configuration method provided in an embodiment of the present application;

[0047] Figure 5 A schematic diagram of the structure of a microservice engineering automation configuration system provided in an embodiment of the present application;

[0048] Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0049] The embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present application, and cannot be interpreted as limiting the present application.

[0050] It will be understood by those skilled in the art that, unless otherwise stated, the singular forms "a", "an" and "the" used herein may also include plural forms. It should be further understood that the term "comprising" used in the specification of the present application refers to the presence of features, integers, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or groups thereof. The term "and / or" used herein includes all or any unit and all combinations of one or more associated listed items.

[0051] In order to make the objectives, technical solutions and advantages of the present application more clear, the specific implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.

[0052] The core of the present invention is to provide a microservice engineering automation configuration method. Figure 1 The figure is a flow chart of the microservice engineering automatic configuration method provided in this embodiment. In order to better understand the method, Figure 1 The technical solution of this embodiment is described in detail:

[0053] S101. Create a CICD pipeline script in the code repository;

[0054] S102. Bind the pom file path, microservice name, and project address of the microservice project through a pre-script;

[0055] S103, automatically triggering the pipeline to obtain information and parameters required for subsequent automatic upgrades.

[0056] In this embodiment, the code repository of the enterprise-level microservice can be gitlab or github; in this embodiment, the gitlab warehouse is taken as an example to illustrate, and a CICD pipeline script is created. The pom file path corresponding to the current project (the pom file contains the GAV coordinate information of all other dependent components introduced by this microservice project), the microservice name, and the project address are bound one by one in the front script according to the ID of each microservice project. The pipeline is automatically triggered each time a tag is created or a branch is modified. The pipeline of each microservice project will first execute the front script to obtain the relevant information and parameters required for subsequent automated upgrades, such as the pom path of the component to be upgraded.

[0057] After the pre-script is executed, in an optional embodiment, when the project needs to publish components to a remote repository, it includes:

[0058] Create a tag for publishing components;

[0059] Triggering a release component pipeline, the pipeline is used for component release function;

[0060] Execute the preceding script to obtain relevant information of the current project;

[0061] Use the mvn deploy command to publish components;

[0062] Write the GAV coordinate information of the published components into the database to record the version information;

[0063] Notify other microservice projects that this project has released new dependent components;

[0064] Create automated upgrade tags for other microservice projects through the code repository API.

[0065] After the execution of the pre-script is completed, in an optional embodiment, when other microservice projects automatically upgrade the newly released components, it includes:

[0066] Trigger the automated upgrade pipeline;

[0067] Parse the GAV coordinate information in the pom file;

[0068] Match and compare the version number. If the version number in the library is higher, update the versionID in the pom file.

[0069] Update the component version information in the pom files of all modules;

[0070] Push the updated code back to the project.

[0071] In this embodiment, there are two situations:

[0072] The flowchart for the first scenario can be found in Figure 2 , the current project needs to publish components to the remote warehouse. At this time, the project is the dependent party, and other microservice projects may need to reference the relevant components of the project. When serving as the party that publishes components, the automated component release pipeline mainly includes the following seven steps:

[0073] Step 1: Create a tag for publishing components;

[0074] Step 2: Trigger the release component pipeline, which is only used for component release functions;

[0075] Step 3: Execute the pre-script to obtain relevant information of the current project;

[0076] Step 4: Use mvn deploy to publish components. You need to specify the pom file path, which is obtained from the relevant information in step 3;

[0077] Step 5: After mvn deploy succeeds, the GAV coordinate information of the released component is written into the database to record the version information. The recorded content includes the date of the released component, GAV coordinate information (GroupID, ArtifactID, VersionID), release environment, release project ID, and status identification bit. The release environment here mainly obtains information based on pre-defined tags. Assuming that the currently released component is only used in the sit test environment, the tag that triggers the release of the component should specify the tag specification in advance (such as x-sit-deploy) to indicate that the current tag label is used for the release of dependent components in the sit environment. The status identification bit is used to identify whether other microservice projects can reference the component version. Since the component version is constantly iterating and updating, the old version may need to be abandoned. Other projects are not allowed to reference older versions during automatic upgrades. Therefore, the status identification position of the component that is not allowed to be referenced needs to be abandoned;

[0078] Step 6: Email notification to inform other microservice project leaders that new dependent components have been released for this project;

[0079] Step 7: After the component is released, the API provided by the code repository is called to create the automatic upgrade tags of other microservice projects. The other microservice projects here mainly refer to the projects that use this component and are configured for automatic upgrade. After the corresponding projects are configured in advance, once the current component releases a new version to trigger the pipeline, the automatic upgrade tag labels of other microservice projects that use this component can be automatically created to trigger the automatic upgrade pipeline.

[0080] The second case can be seen in Figure 3 , automatically upgrade the newly released components in the second step for other microservice projects;

[0081] Since it is an automatic upgrade of dependent components, the triggering method of the pipeline can be a scheduled trigger, a trigger when the branch code is changed, and an automatic trigger after a component in the previous step is released. Once the automatic upgrade pipeline is triggered, the pom file needs to be parsed first. The gav coordinates in the pom file are parsed according to the pom path obtained in the pre-script, and the parsed groupID and artifactID are matched. After matching, the verisonID is compared. If the verisonID version number in the library is higher, the versionID in the pom file is automatically updated to the latest version number; if the verisonID version number in the library is less than the version number parsed in the pom file, the current component version number is not updated. Since a microservice project may consist of multiple modules, it is necessary to update the corresponding component version information in the pom file under each module. After updating all component version information, the updated code needs to be pushed back to the project, and an email notification will be sent after the push is completed.

[0082] Figure 4 This is a flowchart of the specific steps of this embodiment. In the embodiment of the present application, a CICD pipeline script is created in the code repository; the pom file path, microservice name and project address of the microservice project are bound through a front-end script; the pipeline is automatically triggered to obtain the information and parameters required for subsequent automated upgrades, and the microservice versions can be uniformly managed. Version records are recorded for dependent components, and there is a complete version management mechanism; it can also be used to solve the problems of incomplete version upgrades and uncoordinated upgrades of microservice dependent component versions in collaborative releases; it is also suitable for large-scale enterprise-level microservice application scenarios involving multiple environments, multiple microservice projects, and multiple components. The collaborative changes can achieve the effect of automated upgrades and automated changes, greatly simplifying the cumbersome process of version upgrades and improving development and deployment efficiency.

[0083] based on Figure 1 The embodiment shown provides a method for automatically configuring a microservice project. Figure 5 A microservice engineering automation configuration system provided by an embodiment of the present application is shown. Figure 5 As shown, the system can mainly include: 201 creation module, 202 binding module, 203 acquisition module, wherein:

[0084] The 201 creation module is used to create a CICD pipeline script in the code repository;

[0085] The 202 binding module is used to bind the pom file path, microservice name and project address of the microservice project through a pre-script;

[0086] The 203 acquisition module is used to automatically trigger the pipeline to obtain information and parameters required for subsequent automatic upgrades.

[0087] In an embodiment of the present application, a CICD pipeline script is created in a code repository; the pom file path, microservice name, and project address of the microservice project are bound through a front-end script; the pipeline is automatically triggered to obtain the information and parameters required for subsequent automated upgrades, and the microservice versions can be uniformly managed. Version records are kept for dependent components, and a complete version management mechanism is provided; it can also be used to solve the problems of incomplete version upgrades and uncoordinated upgrades of microservice dependent component versions in collaborative releases; it is also suitable for large-scale enterprise-level microservice application scenarios, involving scenarios with collaborative changes of multiple environments, multiple microservice projects, and multiple components, and can achieve the effects of automated upgrades and automated changes, greatly simplifying the cumbersome process of version upgrades and improving development and deployment efficiency.

[0088] It can be understood that the above modules of the microservice engineering automation configuration system in this embodiment have the function of realizing Figure 1 The functions of the corresponding steps of the method in the embodiment shown in . The function can be implemented by hardware, or by hardware executing the corresponding software. The hardware or software includes one or more modules corresponding to the above functions. The above modules can be software and / or hardware, and the above modules can be implemented separately or integrated with multiple modules. For the functional description of the above modules, please refer to Figure 1 The corresponding description of the method in the embodiment shown in will not be repeated here.

[0089] An embodiment of the present application provides an electronic device, including a processor and a memory;

[0090] A memory, used for storing operation instructions;

[0091] The processor is used to execute the microservice engineering automatic configuration method provided in any embodiment of the present application by calling an operation instruction.

[0092] As an example, Figure 6 A schematic diagram of the structure of an electronic device applicable to the embodiment of the present application is shown. Figure 6 As shown, the electronic device 2000 includes: a processor 2001 and a memory 2003. The processor 2001 and the memory 2003 are connected, such as through a bus 2002. Optionally, the electronic device 2000 may also include a transceiver 2004. It should be noted that in actual applications, the transceiver 2004 is not limited to one, and the structure of the electronic device 2000 does not constitute a limitation on the embodiments of the present application.

[0093] The processor 2001 is applied in the embodiment of the present application to implement the method shown in the above method embodiment. The transceiver 2004 may include a receiver and a transmitter. The transceiver 2004 is applied in the embodiment of the present application to implement the function of the electronic device of the embodiment of the present application communicating with other devices when executed.

[0094] Processor 2001 may be a CPU (Central Processing Unit), a general purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. It may implement or execute various exemplary logic blocks, modules and circuits described in conjunction with the disclosure of this application. Processor 2001 may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc.

[0095] The bus 2002 may include a path to transmit information between the above components. The bus 2002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus. The bus 2002 may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 6 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0096] The memory 2003 can be a ROM (Read Only Memory) or other types of static storage devices that can store static information and instructions, a RAM (Random Access Memory) or other types of dynamic storage devices that can store information and instructions, or an EEPROM (Electrically Erasable Programmable Read Only Memory), a CD-ROM (Compact Disc Read Only Memory) or other optical disk storage, optical disk storage (including compressed optical disk, laser disk, optical disk, digital versatile disk, Blu-ray disk, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited to these.

[0097] Optionally, the memory 2003 is used to store application code for executing the solution of the present application, and the execution is controlled by the processor 2001. The processor 2001 is used to execute the application code stored in the memory 2003 to implement the microservice engineering automatic configuration method provided in any embodiment of the present application.

[0098] The electronic device provided in the embodiment of the present application is applicable to any embodiment of the above method and will not be described in detail here.

[0099] An embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored. When the program is executed by a processor, the microservice engineering automation configuration method shown in the above method embodiment is implemented.

[0100] The computer-readable storage medium provided in the embodiments of the present application is applicable to any embodiment of the above method and will not be described in detail here.

[0101] The microservice engineering automation configuration solution provided in the embodiment of the present application creates a CICD pipeline script in the code repository; binds the pom file path, microservice name and project address of the microservice project through a front-end script; automatically triggers the pipeline to obtain the information and parameters required for subsequent automated upgrades, can uniformly manage microservice versions, record versions of dependent components, and have a complete version management mechanism; can also be used to solve the problems of incomplete version upgrades and uncoordinated upgrades of microservice dependent component versions in collaborative releases; and is also suitable for large-scale enterprise-level microservice application scenarios involving multiple environments, multiple microservice projects, and multiple components with collaborative changes, and can achieve the effects of automated upgrades and automated changes, greatly simplifying the cumbersome process of version upgrades and improving development and deployment efficiency.

[0102] Through the description of the above implementation methods, technical personnel in the relevant field can understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the specific system can be divided into different functional modules to complete all or part of the functions described above.

[0103] Those of ordinary skill in the art will appreciate that the modules and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0104] In several embodiments covered by the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the division of modules is only a logical function division, and there may be other division methods in actual implementation, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or modules, or it can be an electrical, mechanical or other form of connection.

[0105] The modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, that is, they may be located in one place or distributed on multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the embodiments of the present application.

[0106] In addition, each functional module in each embodiment of the present application can be implemented in the form of hardware or in the form of software functional modules. If these functional modules are implemented in the form of software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present application is essentially or part of the prior art that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a computer program product, which includes one or more computer instructions. When loading and executing computer program instructions on a computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer program product is stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, a computer instruction can be transmitted from a website site, a computer, a server or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or a data center that includes one or more available media integrations. The available medium may be a magnetic medium (eg, a floppy disk, a hard disk, a magnetic tape), an optical medium (eg, a DVD), or a semiconductor medium (eg, a solid state disk (SSD)).

[0107] The above contents are merely examples and explanations of the structure of the present invention. The technicians in this technical field may make various modifications or additions to the specific embodiments described or replace them in a similar manner. As long as they do not deviate from the structure of the invention or exceed the scope defined by the claims, they should all fall within the protection scope of the present invention.

Claims

1. A microservice engineering automated configuration method, characterized in that: include: Create CICD pipeline scripts in the code repository; Bind the pom file path, microservice name, and project address of the microservice project through the pre-script; Automatically trigger the pipeline to obtain the information and parameters required for subsequent automatic upgrades.

2. According to the microservice engineering automation configuration method of claim 1, after the execution of the pre-script is completed, it is characterized in that: When a project needs to publish components to a remote repository, it includes: Create a tag for publishing components; Triggering a release component pipeline, the pipeline is used for component release function; Execute the preceding script to obtain relevant information of the current project; Use the mvn deploy command to publish components; Write the GAV coordinate information of the published components into the database to record the version information; Notify other microservice projects that this project has released new dependent components; Create automated upgrade tags for other microservice projects through the code repository API.

3. According to the microservice engineering automation configuration method of claim 1, after the execution of the pre-script is completed, it is characterized in that: When other microservice engineering automates the upgrade of newly released components, including: Trigger the automated upgrade pipeline; Parse the GAV coordinate information in the pom file; Match and compare the version number. If the version number in the library is higher, update the versionID in the pom file. Update the component version information in the pom files of all modules; Push the updated code back to the project.

4. The microservice engineering automation configuration method according to claim 2, characterized in that: The step of writing the GAV coordinate information of the published component into the database to record the version information includes: The date of the published component, GAV coordinate information, publishing environment, publishing project ID, and status flag.

5. The microservice engineering automation configuration method according to claim 2, characterized in that: The automated upgrade tags for creating other microservice projects through the code repository API include: The other microservice projects are projects that reference the component and are configured for automatic upgrades. After the corresponding projects are configured in advance, when the current component releases a new version to trigger the pipeline, the automatic upgrade tag labels of other microservice projects that reference the component are automatically created to trigger the automatic upgrade pipeline.

6. The microservice engineering automation configuration method according to claim 3, characterized in that: The matching and comparison of version numbers, if the version number in the library is higher, updates the versionID in the pom file, including: If the verisonID version number in the library is smaller than the version number parsed in the pom file, the current component version number will not be updated.

7. A microservice engineering automated configuration system, characterized in that: The system includes: a creation module, a binding module, and an acquisition module, wherein: Create module: used to create CICD pipeline scripts in the code repository; Binding module: used to bind the pom file path, microservice name and project address of the microservice project through the pre-script; Acquisition module: used to automatically trigger the pipeline to obtain the information and parameters required for subsequent automated upgrades.

8. An electronic device, characterized in that: including a processor and a memory; The memory is used to store operation instructions; The processor is used to execute the method according to any one of claims 1 to 6 by calling the operation instruction.

9. A computer-readable storage medium, characterized in that: The storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

10. A computer program product, characterized in that The computer program product comprises one or more computer instructions, and when the computer program instructions are loaded and executed on a computer, the method according to any one of claims 1 to 6 is fully or partially executed.

Images