Component version management method and device, computer device and storage medium

Abstract

The application relates to an assembly version management method, device, computer equipment and storage medium. The method comprises the following steps: constructing a release version management project and a gray version management project; determining each first assembly project, configuring a first declaration in each first assembly project, and the first declaration indicates that release versions of each first assembly project dependent on the release version management project are declared as dependent projects of each first assembly project; when a target assembly in the multiple assemblies has a gray version, declaring the gray version of the target assembly as a dependent project of the gray version management project; determining each second assembly project according to the target assembly, and configuring a second declaration in each second assembly project, and the second declaration indicates that the gray version of the target assembly in the gray version management project is declared as a dependent project of each second assembly project. The application can reduce the business influence range when a new version assembly has a problem, and can perform gray verification on the assembly without modifying the code of other projects.

Description

Technical Field

[0001] This application relates to the field of component version management, and in particular to a component version management method, apparatus, computer device, and storage medium. Background Technology

[0002] The following statements are provided only as background information in relation to this application and do not necessarily constitute prior art.

[0003] When developing Java projects, common modules are usually packaged into a JAR file, which other projects can directly reference to avoid writing duplicate code. These common modules can be called components.

[0004] The content of a component (usually code) may need to be changed. Once the component's content has been changed, it needs to be repackaged, that is, the modified content of the component needs to be packaged into a JAR file so that other projects referencing the component can use the modified content.

[0005] After repackaging, a version identifier needs to be assigned to the repackaged Jar file. There are two options for assigning the version identifier to this Jar file:

[0006] 1. The version identifier of the component's JAR file remains unchanged. That is, the component has only one version identifier. Each time the component is packaged, only the content of the component is overwritten, and the version identifier of the component remains unchanged.

[0007] 2. The version of the component's JAR file changes. That is, the component has multiple version identifiers. Each time the component is packaged, the version identifier will change. For example, the version identifier will be changed in an incrementing manner. For example, the previous version identifier of the component was component_1.0, and the new version identifier is incremented to component_2.0.

[0008] If the above allocation option 1 is adopted, the component will have only one version identifier. Each new version of the component will overwrite the content of the previous version. Since the component's version identifier does not change, other projects that reference the component can use the latest version of the component without modifying their code. However, the fact that the component's version identifier does not change also has the following drawbacks:

[0009] (1) The latest version of the component will take effect immediately after being packaged. Other projects will use the latest version of the component in the next build. If there is a problem with the latest version of the component, it will cause problems in the operation of other projects and have a significant impact on business.

[0010] (2) The component rollback takes a long time because it requires repackaging the content of the previous version to achieve the component rollback.

[0011] (3) Cannot implement grayscale verification of components.

[0012] If the above allocation option (2) is adopted, the version identifier of the component will change, so users of other projects need to modify their code to use the latest version of the component. For example, suppose project A originally declared in its code that it referenced version 1.0 of component B. If component B is updated to version 2.0, project A needs to modify its code to declare that it references version 2.0 of component B in order to use version 2.0 of component B. Otherwise, it will still use version 1.0 of component B. The advantage is that if there is a problem with the latest version of the component, the business impact is small. By changing the component dependency version declared by some projects, the functionality of the new version of the component can be verified, and the component can be gray-scale verified. However, there are also disadvantages, namely, other projects need to modify their code. Because the code needs to be modified, the promotion of the new version of the component is difficult, and the removal of the old version of the component is also difficult. Summary of the Invention

[0013] To address the aforementioned shortcomings or drawbacks, this application provides a component version management method, apparatus, computer device, and storage medium. The embodiments of this application can reduce the scope of business impact when problems occur in a new version of a component; and can perform gray-scale verification of components without modifying the code in other projects.

[0014] This application provides a component version management method according to a first aspect. In one embodiment, the method includes:

[0015] Build release version management projects and canary release version management projects;

[0016] Identify each first component project, and configure a first declaration in each first component project. The first declaration indicates that the release version that each first component project in the release version management project depends on is declared as a dependency project of each first component project.

[0017] When a target component among the above components has a grayscale version, declare the grayscale version of the target component as a dependency project of the grayscale version management project;

[0018] Based on the target component, determine each second component project, and configure a second declaration in each second component project. The second declaration indicates that the gray version of the target component in the gray version management project is declared as a dependency project of each second component project.

[0019] In one embodiment, the release version management project declares multiple dependent projects, which are release versions of multiple components; the first component project refers to the component project that depends on the release version of at least one of the multiple components; the second component project refers to the first component project that depends on the grayscale version of the target component.

[0020] In one embodiment, a second declaration is configured in each second component project, including:

[0021] Configure the second declaration before the first declaration in each second component project.

[0022] In one embodiment, the above method further includes:

[0023] When building a release version management project, declare the release version management project's version name as a variable;

[0024] When building a grayscale version management project, declare the version name of the grayscale version management project as a variable.

[0025] In one embodiment, the above method further includes:

[0026] When declaring the release version of any of the above components as a dependency of the release version management project, declare the release version name of any component as a constant.

[0027] When declaring a grayscale version of any of the above components as a dependency of the grayscale version management project, declare the version name of the grayscale version of any component as a constant.

[0028] In one embodiment, the above method further includes:

[0029] When a newer release version of any of the above components exists, update the version dependency declaration for that component in the release version management project.

[0030] In one embodiment, the method further includes: declaring the version name of any first component project as a variable when constructing any first component project.

[0031] This application provides a component version management apparatus according to a second aspect. In one embodiment, the apparatus includes:

[0032] Build modules are used to build release version management projects and canary release version management projects;

[0033] The first configuration module is used to determine each first component project and configure a first declaration in each first component project. The first declaration indicates that the release version that each first component project in the release version management project depends on is declared as a dependency project of each first component project.

[0034] The declaration module is used to declare the gray version of the target component as a dependency of the gray version management project when the target component among the above components has a gray version.

[0035] The second configuration module is used to determine each second component project based on the target component, and to configure a second declaration in each second component project. The second declaration indicates that the gray version of the target component in the gray version management project is declared as a dependency project of each second component project.

[0036] This application provides a computer device according to a third aspect, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of any of the above-described methods.

[0037] According to a fourth aspect, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of any of the above-described methods.

[0038] In the above embodiments of this application, a release version management project and a gray-scale version management project are constructed; each first component project is determined, and a first declaration is configured in each first component project, indicating that the release version depended on by each first component project in the release version management project is declared as a dependency project of each first component project; when a gray-scale version exists for a target component among the above multiple components, the gray-scale version of the target component is declared as a dependency project of the gray-scale version management project; each second component project is determined according to the target component, and a second declaration is configured in each second component project, indicating that the gray-scale version of the target component in the gray-scale version management project is declared as a dependency project of each second component project. This embodiment of the application can ensure that after a component updates its version content, a release operation is required before other projects can use the latest version content of the component. This can reduce the scope of business impact when problems occur with the new version component, while other projects do not need to modify their code; it can also enable gray-scale verification of components without modifying the code of other projects. Attached Figure Description

[0039] Figure 1 This is a flowchart illustrating a component version management method in one embodiment;

[0040] Figure 2 Here is an example code for building the first component project in one embodiment;

[0041] Figure 3 This is a schematic diagram of an existing implementation method;

[0042] Figure 4 Here is an example of code for building a release version management project in one embodiment;

[0043] Figure 5 Here is an example code in one embodiment that uses a release version management project in the first component project;

[0044] Figure 6 This is a flowchart illustrating the process of constructing the first component project in one embodiment;

[0045] Figure 7 Here is an example code for building a grayscale version management project in one embodiment;

[0046] Figure 8 Here is an example code snippet from one embodiment that uses grayscale versioning to manage a project in the second component project;

[0047] Figure 9 This is a structural block diagram of a component version identification device in one embodiment;

[0048] Figure 10 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0049] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0050] This application provides a component version management method. In one embodiment, the component version management method includes: Figure 1 The steps shown are described below, and the method will be explained in detail below.

[0051] S110: Build release version management projects and canary release version management projects.

[0052] This example uses Maven (a project management tool that can automate the building and dependency management of Java projects) to build release version management projects and canary release management projects.

[0053] The release version management project declares multiple dependency projects, which are release versions of multiple components.

[0054] After developing a new version of a component, it will not be immediately released to all projects. Instead, it will undergo a phased rollout (or canary release) to test its functionality (e.g., releasing it to a select group of projects initially, and then using the feedback to determine whether to further refine it or release it to all projects). Only after successful phased rollout will it be released to all projects. The release version of a component refers to the official version released to all projects after completing phased rollout. The component's version content can refer to its code.

[0055] The gray-scale version management project declares at least one dependent project, which is a gray-scale version of at least one component. A component's gray-scale version refers to a version of the component that is still undergoing gray-scale verification and has not been fully released to all projects.

[0056] Furthermore, when building a release version management project, the version name of the release version management project is declared as a variable; when building a gray-scale version management project, the version name of the gray-scale version management project is declared as a variable.

[0057] S120: Identify each first component project and configure a first declaration in each first component project. The first declaration indicates that the release version that each first component project in the release version management project depends on is declared as a dependency project of each first component project.

[0058] When building any first component project, declare the version name of that first component project as a variable. Configuring the first declaration in each first component project means configuring the first declaration in the POM (Project Object Model) file of each first component project.

[0059] Furthermore, the first component project refers to a component project that depends on a release version of at least one of the aforementioned components.

[0060] Furthermore, if a newer release version of any of the aforementioned components exists, update the version dependency declaration for that component in the release version management project.

[0061] S130: When a target component among the above components has a grayscale version, declare the grayscale version of the target component as a dependency of the grayscale version management project.

[0062] S140: Determine each second component project based on the target component, and configure a second declaration in each second component project. The second declaration indicates that the gray version of the target component in the gray version management project is declared as a dependency project of each second component project.

[0063] Configuring a second declaration in each second component project refers to configuring the second declaration in the POM (Project Object Model) file of each second component project. A second component project is a first component project that depends on a grayscale version of the target component.

[0064] Furthermore, configuring the second declaration in each second component project includes configuring the second declaration before the first declaration in each second component project. By configuring the second declaration before the first declaration, the component dependencies in the second declaration can be applied preferentially, thus eliminating the need for other projects to use them.

[0065] Furthermore, the above method also includes: when declaring the release version of any of the above components as a dependency of the release version management project, declaring the version name of the release version of any component as a constant; when declaring the grayscale version of any of the above components as a dependency of the grayscale version management project, declaring the version name of the grayscale version of any component as a constant.

[0066] This embodiment introduces release version management projects and canary release version management projects, allowing other projects to use the latest release version or canary release version of the component without modifying their code. Furthermore, it ensures that after a component update, a release operation is required before other projects can use the latest version. This minimizes the business impact when issues arise with the new component version, while also eliminating the need for other projects to modify their code.

[0067] This application also provides an application example to further illustrate a component version management method provided in the above embodiments.

[0068] In this application example, assume that component version management needs to implement the following functions:

[0069] 1. Each time a new version of a component is released, the version number is incremented instead of being overwritten;

[0070] 2. Other projects can use the released version of the component without changing the code;

[0071] 3. Implement grayscale verification for components.

[0072] For feature 1 above, by declaring the component's version identifier as a variable, the version identifier can be incremented by changing the variable's value when a new version of the component is built. See [link to details] for more information. Figure 2 The example code shown declares the version identifier of the one-starter component as the variable "project.release.version".

[0073] For function 2 mentioned above, a common implementation is to declare the component's version identifier as a variable, and also set the version identifiers of the components that the component depends on (called dependent components) as variables. Then, when the dependent component is built, the value passed to the variable can dynamically change the version identifier of the dependent component. For example... Figure 3The example code shown illustrates this, where the one-starter component depends on the two-starter component. The version identifier of the two-starter component is declared as a variable, "depend.version". However, when there are many dependent components, and each component has a different version, this implementation requires writing numerous variables, at least declaring the version identifier of each dependent component as a variable. Managing a large number of variables becomes difficult, and it's also hard to unify variables for the same dependent components across different projects (such as component projects). Furthermore, the build tool struggles to determine which variables to pass when building the project. In short, this implementation is not suitable for scenarios with many dependent components and different versions.

[0074] Therefore, the solution provided in this application example is to build a release management project, in which you can declare release versions that depend on multiple components. See [link to relevant documentation] for details. Figure 4 The example code shown should be noted, in order to reduce the length, Figure 4 The example only shows the dependency declaration for one dependent component, namely two-starter. In release version control projects, the release version control project's version identifier is declared as a variable, while the version identifiers of dependent components are declared as constants, for example, Figure 4 The code example declares the version identifier of the release version management project component-release as a variable, namely "component.release.version", and declares the dependent component as the two-starter component, whose version identifier is declared as a constant, namely "1.0".

[0075] Then, by using the release version management project in the first component project, the first component project can obtain the latest release version content of the release version management project through the version identifier declared as a variable in the release version management project. See details in [link to documentation]. Figure 5 The example code shown demonstrates that the `one-starter` component's project declares an import of the release management project `component-release`, and declares a dependency on the `two-starter` component within `component-release`. The version identifier of the `two-starter` component is inherited from the release management project `component-release`. Further, the process of the `one-starter` component's project using the latest version of the `two-starter` component through the release management project `component-release` can be found in [link to example code]. Figure 6As shown. By building a release version management project, it is possible to achieve the following: (1) Components need to be released so that other projects can use the released version; (2) Other projects can use the latest version of the component without changing the version declaration of the dependent component.

[0076] For feature 3 mentioned above, the approach used to build a release version management project can be referenced. In a canary version management project, canary versions that depend on one or more components can be declared. See [link to relevant documentation] for details. Figure 7 The example code shown should be noted, in order to reduce the length, Figure 7 The example only shows the dependency declaration for one dependent component, namely two-starter. In a canary release project, the version identifier of the canary release project is declared as a variable, while the version identifier of the dependent component is declared as a constant, for example, Figure 7 The code example declares the version identifier of the grayscale version management project component-gray as a variable, namely "component.gray.version", and declares the dependent component as the two-starter component, whose version identifier is declared as a constant, namely "2.0".

[0077] Then, the second component project uses a canary release management project. The second component project can then access the canary version content of the canary release management project through the version identifier declared as a variable in the canary release management project, and access the release version content of the release version management project through the version identifier declared as a variable in the release version management project. It's important to note that to ensure the second component project has priority access to the component's canary release version, the dependency declaration that imports the canary release management project should be placed before the dependency declaration that imports the release version management project. This leverages a Maven feature: if the same dependency is declared twice, the dependency declared earlier will take precedence. Figure 5 The code shown is an example; specific details can be inserted within it. Figure 8 The underlined portion of the example code shows how the canary version management project `component-gray` is declared and imported within the `one-starter` component's project. Since the `component-gray` declaration precedes `component-release`, version 2.0 of the `two-starter` component within `component-gray` will be used before version 1.0 of the `two-starter` component in `component-release`, thus enabling the canary version verification of the component.

[0078] It should be noted that, regarding the various steps included in the component version management method provided in any of the above embodiments, unless otherwise explicitly stated herein, there is no strict order restriction on the execution of these steps; they can be executed in other orders. Furthermore, at least some of these steps may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is also not necessarily sequential, but can be performed alternately or in turn with other steps or at least a portion of the sub-steps or stages of other steps.

[0079] Based on the same inventive concept, this application also provides a component version management device. In this embodiment, as... Figure 9 As shown, the component version management device includes the following modules:

[0080] Module 110 is used to build release version management projects and canary release version management projects;

[0081] The first configuration module 120 is used to determine each first component project and configure a first declaration in each first component project. The first declaration indicates that the release version declarations that each first component project in the release version management project depends on are the dependency projects of each first component project.

[0082] Declaration module 130 is used to declare the gray version of the target component as a dependency project of the gray version management project when the target component among the above multiple components has a gray version.

[0083] The second configuration module 140 is used to determine each second component project based on the target component, and configure a second declaration in each second component project. The second declaration indicates that the gray version of the target component in the gray version management project is declared as a dependency project of each second component project.

[0084] In one embodiment, the release version management project declares multiple dependent projects, which are release versions of multiple components; the first component project refers to the component project that depends on the release version of at least one of the multiple components; the second component project refers to the first component project that depends on the grayscale version of the target component.

[0085] In one embodiment, when configuring a second declaration in each second component project, the second configuration module 140 configures the second declaration before the first declaration in each second component project.

[0086] In one embodiment, the build module 110 is further configured to declare the version name of the release version management project as a variable when building the release version management project; and to declare the version name of the grayscale version management project as a variable when building the grayscale version management project.

[0087] In one embodiment, the first configuration module 120 is further configured to declare the version name of the release version of any component as a constant when declaring the release version of any component among the plurality of components as a dependency of the release version management project. The declaration module 130 is further configured to declare the version name of the grayscale version of any component as a constant when declaring the grayscale version of any component among the plurality of components as a dependency of the grayscale version management project.

[0088] In one embodiment, the first configuration module 120 is further configured to update the version dependency declaration for any of the aforementioned components in the release version management project when a newer release version exists for any of the components.

[0089] In one embodiment, the build module 110 is further configured to build a first component project. The build module 110 is also configured to declare the version name of any first component project as a variable when building any first component project.

[0090] Specific limitations regarding the component version management device can be found in the limitations of the component version management method described above, and will not be repeated here. Each module in the aforementioned component version management device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0091] In one embodiment, a computer device is provided, the internal structure of which can be shown as follows: Figure 10 As shown.

[0092] The computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and the database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores data such as POM files for various projects; the specific data stored can also be found in the limitations defined in the above method embodiments. The network interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a component version management method.

[0093] Those skilled in the art will understand that Figure 10 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0094] This embodiment also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it performs the following steps:

[0095] Build a release version management project and a canary version management project; determine each first component project, and configure a first declaration in each first component project, indicating that the release version that each first component project in the release version management project depends on is declared as a dependency project of each first component project; when the target component in the above multiple components has a canary version, declare the canary version of the target component as a dependency project of the canary version management project; determine each second component project according to the target component, and configure a second declaration in each second component project, indicating that the canary version of the target component in the canary version management project is declared as a dependency project of each second component project.

[0096] In one implementation, the release version management project declares multiple dependent projects, which are release versions of multiple components; the first component project refers to the component project that depends on the release version of at least one of the multiple components; the second component project refers to the first component project that depends on the grayscale version of the target component.

[0097] In one implementation, when the processor executes a computer program to configure the second declaration in each of the second component projects, it also performs the following steps:

[0098] Configure the second declaration before the first declaration in each second component project.

[0099] In one implementation, the processor executes a computer program and also performs the following steps:

[0100] When building a release version management project, declare the version name of the release version management project as a variable; when building a gray-scale version management project, declare the version name of the gray-scale version management project as a variable.

[0101] In one implementation, the processor executes a computer program and also performs the following steps:

[0102] When declaring the release version of any of the above components as a dependency of the release version management project, the release version name of any component is declared as a constant; when declaring the grayscale version of any of the above components as a dependency of the grayscale version management project, the grayscale version name of any component is declared as a constant.

[0103] In one implementation, the processor executes a computer program and also performs the following steps:

[0104] When a newer release version of any of the above components exists, update the version dependency declaration for that component in the release version management project.

[0105] In one implementation, the processor executes a computer program and also performs the following steps:

[0106] When building any first component project, declare the version name of any first component project as a variable.

[0107] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0108] Build a release version management project and a canary version management project; determine each first component project, and configure a first declaration in each first component project, indicating that the release version that each first component project in the release version management project depends on is declared as a dependency project of each first component project; when the target component in the above multiple components has a canary version, declare the canary version of the target component as a dependency project of the canary version management project; determine each second component project according to the target component, and configure a second declaration in each second component project, indicating that the canary version of the target component in the canary version management project is declared as a dependency project of each second component project.

[0109] In one implementation, the release version management project declares multiple dependent projects, which are release versions of multiple components; the first component project refers to the component project that depends on the release version of at least one of the multiple components; the second component project refers to the first component project that depends on the grayscale version of the target component.

[0110] In one implementation, the computer program is executed by a processor to implement the following steps when configuring the second declaration in each second component project:

[0111] Configure the second declaration before the first declaration in each second component project.

[0112] In one implementation, the computer program is executed by a processor and also performs the following steps:

[0113] When building a release version management project, declare the version name of the release version management project as a variable; when building a gray-scale version management project, declare the version name of the gray-scale version management project as a variable.

[0114] In one implementation, the computer program is executed by a processor and also performs the following steps:

[0115] When declaring the release version of any of the above components as a dependency of the release version management project, the release version name of any component is declared as a constant; when declaring the grayscale version of any of the above components as a dependency of the grayscale version management project, the grayscale version name of any component is declared as a constant.

[0116] In one implementation, the computer program is executed by a processor and also performs the following steps:

[0117] When a newer release version of any of the above components exists, update the version dependency declaration for that component in the release version management project.

[0118] In one implementation, the computer program is executed by a processor and also performs the following steps:

[0119] When building any first component project, declare the version name of any first component project as a variable.

[0120] Those skilled in the art will understand that implementing all or part of the processes in the above method embodiments can be accomplished by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), memory bus (RAMbus), direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0121] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0122] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A component version management method, characterized in that, The method includes: Build a release version management project and a canary version management project; the release version management project declares multiple dependent projects, which are release versions of multiple components; when building the release version management project, the version name of the release version management project is declared as a variable; when building the canary version management project, the version name of the canary version management project is declared as a variable. Each first component project is identified, and a first declaration is configured in each first component project. The first declaration indicates that the release version that each first component project in the release version management project depends on is declared as a dependency project of each first component project. When declaring the release version of any component among the multiple components as a dependency project of the release version management project, the version name of the release version of any component is declared as a constant. When a target component among the multiple components has a grayscale version, the grayscale version of the target component is declared as a dependency project of the grayscale version management project; Each second component project is determined based on the target component, and a second declaration is configured in each second component project. The second declaration indicates that the gray version of the target component in the gray version management project is declared as a dependency project of each second component project. When declaring the gray version of any component among the plurality of components as a dependency project of the gray version management project, the version name of the gray version of any component is declared as a constant. Configuring the second declaration in each second component project includes configuring the second declaration before the first declaration in each second component project.

2. The method as described in claim 1, characterized in that, The first component project refers to a component project that depends on a release version of at least one of the plurality of components; the second component project refers to a first component project that depends on a grayscale version of the target component.

3. The method as described in claim 1, characterized in that, The method further includes: When any of the plurality of components has a newer release version, update the version dependency declaration for that component in the release version management project.

4. The method as described in claim 1 or 3, characterized in that, The method further includes: when constructing any of the first component projects, declaring the version name of any of the first component projects as a variable.

5. A component version management device, characterized in that, The device includes: A build module is used to build a release version management project and a canary version management project. The release version management project declares multiple dependent projects, which are release versions of multiple components. When building the release version management project, the version name of the release version management project is declared as a variable. When building the canary version management project, the version name of the canary version management project is declared as a variable. The first configuration module is used to determine each first component project, configure a first declaration in each first component project, the first declaration indicating that the release version that each first component project in the release version management project depends on is declared as a dependency project of each first component project; when declaring the release version of any component among the multiple components as a dependency project of the release version management project, the version name of the release version of any component is declared as a constant. The declaration module is used to declare the gray version of the target component as a dependency project of the gray version management project when the target component among the multiple components has a gray version. The second configuration module is used to determine each second component project according to the target component, and configure a second declaration in each second component project. The second declaration indicates that the gray version of the target component in the gray version management project is declared as a dependency project of each second component project. When declaring the gray version of any component among the multiple components as a dependency project of the gray version management project, the version name of the gray version of any component is declared as a constant. Configuring the second declaration in each second component project includes configuring the second declaration before the first declaration in each second component project.

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

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

Images