Component upgrading method and system and computer storage medium

Abstract

The invention discloses a component upgrading method and system and a computer storage medium. The method comprises the steps of obtaining an upgraded target component and corresponding target version information; obtaining version information of a plurality of dependent components corresponding to the target component, updating the version information of the dependent components based on the target version information according to a dependent hierarchy sequence of the dependent components, and outputting the updated version information of the dependent components to the corresponding dependent components, and updating the dependent component according to the updated version information. According to the method, all the dependent components can be updated based on the latest target component version, so that the consistency and accuracy of the component library are maintained, in addition, the workload of manually updating the version information of the dependent components can be greatly reduced, the opportunity of human intervention is reduced, the risk of errors caused by misoperation or omission is reduced, and the user experience is improved. And the efficiency of the upgrading process is improved.

Description

Technical Field

[0001] The present invention relates to the field of Internet technology, and in particular to a component upgrading method, system and computer storage medium. Background Art

[0002] In modern project software development, a component library group is a collection of basic functional modules designed for development in a project, which contains multiple interdependent components. These components jointly support the functional implementation of the entire system through clearly defined interfaces and interaction modes.

[0003] However, in the process of developing and maintaining component libraries, a common and difficult problem is dependency management between components. For example, a component depends on components A, B, and C at the same time, and component B depends on component D, and component C also depends on component D. Since the versions of component D that components B and C depend on are inconsistent, the instance pointed to when using the function of component D from component B is not the same as the instance pointed to when using the function of component D from component C. In the scenario where a singleton state needs to be shared, components B and C cannot use the same instance, which leads to inconsistency and instability of the entire system.

[0004] Currently, one method is that after a developer modifies and releases a component, they manually traverse all other components that depend on the component, update the dependent versions in the configuration file one by one, and then release these components. Although this method is intuitive, it is obviously inefficient and prone to errors. Another method is to manually execute the scanning script after the component is released, update the version of the directly dependent components, and then release them. This has the problem of an unsmooth release process and serious fragmentation. Summary of the invention

[0005] One of the purposes of the present invention is to provide a component upgrade method to solve the technical problem in the prior art that when components with mutual dependencies are upgraded and released, manually modifying the upgrade information of other dependent components may easily cause the dependent components to be missed and the upgrade cannot be completed in one go.

[0006] One of the objectives of the present invention is to provide a component upgrading system.

[0007] One of the objects of the present invention is to provide a computer storage medium.

[0008] In order to achieve one of the above-mentioned purposes of the invention, the present invention provides a database synchronization method, including: obtaining an upgraded target component and corresponding target version information; obtaining version information of several dependent components corresponding to the target component, updating the version information of the dependent components based on the target version information according to the dependency hierarchy order of the dependent components, and outputting the updated version information of the dependent components to the corresponding dependent components, so that the dependent components are updated according to the updated version information.

[0009] As a further improvement of an embodiment of the present invention, before obtaining the version information of several dependent components corresponding to the target component, the method includes: determining the project path where the target component is located; traversing other project components under the project path, parsing the configuration file corresponding to each project component, and determining several dependent components that depend on the target component; obtaining the version information of several dependent components corresponding to the target component includes: parsing the configuration file corresponding to each dependent component and determining the corresponding version information.

[0010] As a further improvement of an embodiment of the present invention, the dependent component includes at least one of a first version attribute field, a second version attribute field and a dependency attribute field, the first version attribute field is used to mark the version information of the dependent component after the update operation, the second version attribute field is used to mark the version information of the dependent component before the update operation, and the dependency attribute field is used to mark the version information of several other dependent components on which the current dependent component depends.

[0011] As a further improvement of an embodiment of the present invention, the obtaining of version information of several dependent components corresponding to the target component includes: determining several first dependent components that have a direct dependency relationship with the target component, and determining several second dependent components that have a direct dependency relationship with the first dependent component; determining the dependent components of each dependency level layer by layer until all dependent components with dependencies are covered, and determining the corresponding version information according to the configuration file of each dependent component; the updating of the version information of the dependent components based on the target version information according to the dependency level order of the dependent components includes: updating the version information of the first dependent component based on the target version information, and updating the version information of the second dependent component based on the updated version information of the first dependent component.

[0012] As a further improvement of an embodiment of the present invention, the updating of the version information of the first dependent component based on the target version information includes: parsing the dependency attribute field of the first dependent component to determine that its dependent component is the first dependent version information of the target component; when the target version information and the first dependent version information are inconsistent, updating the first dependent version information based on the target version information, and adding 1 to the first version attribute field value of the first dependent component.

[0013] As a further improvement of an embodiment of the present invention, the updating of the version information of the second dependent component based on the updated version information of the first dependent component includes: obtaining and parsing the dependency attribute field of the current second dependent component, and determining that its dependent component is the second dependent version information of the first dependent component; based on the first version attribute field of the first dependent component, updating the second dependency version information, and adding 1 to the value of the first version attribute field of the second dependent component.

[0014] As a further improvement of an embodiment of the present invention, the updating of the version information of the dependent component based on the target version information includes: determining a number of first dependent components that have a direct dependency relationship with the target component; judging whether the version information corresponding to the second version attribute field of the first dependent component is consistent with the target version information; if not, updating the first version attribute field of the first dependent component based on the target configuration information.

[0015] As a further improvement of an embodiment of the present invention, the method also includes: obtaining a target level tag value of the target component, and determining an initial level tag value of each dependent component according to the dependency level order of the dependent components; when performing a version information update operation on each dependent component, updating the level tag value of the dependent component based on the initial level tag value; and determining the release order of the target component and / or dependent components based on the updated level tag value.

[0016] As a further improvement of an embodiment of the present invention, the method of determining the initial level marking value of each dependent component according to the dependency level order of the dependent components includes: determining the initial level marking value of each dependent component according to the dependency level in which the dependent component is located, wherein dependent components at the same dependency level have the same initial level marking value, and the initial level marking value corresponding to the dependent component is positively correlated with the dependency level in which it is located.

[0017] As a further improvement of an embodiment of the present invention, when performing a version information update operation on each dependent component, the level mark value of the dependent component is updated based on the initial level mark value, including: obtaining the current dependent component to be processed, and a set of historical dependent components that have completed the version information update operation, wherein the first dependency level value of the historical dependent component in the historical dependent component set is less than the second dependency level value of the current component to be processed; determining whether the current dependent component to be processed exists in the historical dependent component set; if so, updating the level mark value of the current dependent component to be processed based on the second dependency level value, determining several other dependent components corresponding to the current component to be processed, and updating the level mark values ​​of the other dependent components based on the second dependency level value in accordance with the dependency level order of the other dependent components; if not, updating the historical dependent component set based on the current dependent component to be processed.

[0018] As a further improvement of an embodiment of the present invention, after determining the release order of dependent components according to the updated hierarchy mark values, the method also includes: publishing in batches from small to large according to the updated hierarchy mark values, and detecting whether the version information of the same dependent components in the server and the client are consistent after the first batch release is completed; if so, controlling the client to execute the second batch release until the release of dependent components corresponding to all hierarchy mark values ​​is completed.

[0019] In order to achieve one of the above-mentioned purposes of the invention, the present invention also provides a component upgrade system, including: an input module, used to obtain the upgraded target component and the corresponding target version information; a processing module, used to obtain the version information of several dependent components corresponding to the target component, and update the version information of the dependent components based on the target version information according to the dependency hierarchy order of the dependent components; an output module, used to output the updated version information of the dependent components to the corresponding dependent components, so that the dependent components are updated according to the updated version information.

[0020] To achieve one of the above-mentioned purposes of the invention, the present invention also provides a computer storage medium, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor executes the steps of the above-mentioned component upgrade method.

[0021] Compared with the prior art, the embodiments of the present invention have at least one of the following beneficial effects:

[0022] The present invention adopts a component upgrade method, which obtains the upgraded target component and the corresponding target version information, determines the version information of several dependent components corresponding to the target component, and updates the version information of the dependent components based on the target version information in accordance with the dependency hierarchy order of the dependent components. By updating the version information of the dependent components layer by layer, the method can ensure that all dependent components are updated based on the latest target component version, thereby maintaining the consistency and accuracy of the component library. In addition, it can greatly reduce the workload of manually updating the version information of the dependent components, reduce the chance of human intervention, reduce the risk of introducing errors due to improper operation or omissions, and improve the efficiency of the upgrade process. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 It is a structural diagram of a component upgrading system in one embodiment of the present invention.

[0024] Figure 2 It is a schematic diagram of the steps of a component upgrading method in one embodiment of the present invention.

[0025] Figure 3 It is a partial schematic diagram of step S2 in one embodiment of the present invention.

[0026] FIG. 4( a ) is a schematic diagram of version information of a dependent component before version information is updated in one embodiment of the present invention.

[0027] FIG. 4( b ) is a schematic diagram of version information of a dependent component after version information is updated in one embodiment of the present invention.

[0028] Figure 5 It is a schematic diagram of the steps of a component upgrading method in an embodiment of the present invention.

[0029] Figure 6 2 is a schematic diagram of step N2 in an embodiment of the present invention.

[0030] FIG. 7( a ) is a schematic diagram of the structure before the dependent component level tag value is updated in one embodiment of the present invention.

[0031] FIG. 7( b ) is a schematic diagram of a structure after the dependent component level tag value is updated in one embodiment of the present invention.

[0032] Figure 8 It is a schematic diagram of the principle structure of a database synchronization method in a preferred embodiment of the present invention. DETAILED DESCRIPTION

[0033] The present invention will be described in detail below in conjunction with the specific embodiments shown in the accompanying drawings. However, these embodiments do not limit the present invention, and any structural, methodological, or functional changes made by a person skilled in the art based on these embodiments are all within the scope of protection of the present invention.

[0034] It should be noted that the term "comprising" or any other variation thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In addition, the terms "first", "second", etc. are used for descriptive purposes only and cannot be understood as indicating or implying relative importance.

[0035] like Figure 1 As shown, an embodiment of the present invention provides a component upgrading system 100.

[0036] In one implementation, the component upgrade system 100 implements synchronization of components or component libraries between the client and server according to a component upgrade method, thereby improving component synchronization efficiency and accuracy.

[0037] In a specific embodiment, the component upgrade method can be implemented with reference to any technical solution provided below.

[0038] A component is a software unit that can be independently developed, tested, deployed, and replaced. A component can be at least one of a dynamic link library, a class library, or a functional module. They encapsulate specific functions or business logic and provide interfaces for interacting with other components or systems.

[0039] The component upgrade system 100 refers to a mechanism or framework for managing, deploying and monitoring the upgrade process of each component in the software system. Specifically, it may include version management, upgrade strategy, automated deployment and monitoring and alarm. Among them, version management is used to record the current version and historical version of each component so that version upgrade or rollback can be performed when necessary; upgrade strategy is used to specify the rules for component upgrade, such as priority; automated deployment is used to realize automatic download, installation and configuration of components to reduce errors and costs of manual operations; monitoring and alarm are used to monitor the upgrade process in real time and promptly alarm when abnormal situations occur so as to quickly locate and solve the problem.

[0040] In one embodiment, the component upgrade system 100 is used to update the version information of the target component that has been changed on the client and the dependent components that have a dependency relationship with the target component, and publish the updated dependent components to the server.

[0041] In a specific embodiment, the server side includes an NPM (Node Package Manager) warehouse, and the client side includes a local development environment of a developer. In this embodiment, the NPM warehouse is a package / component management tool that allows developers to publish, share, and install various software packages. Developers develop projects on their local computers and can use NPM client tools (such as NPM command line tools) to manage dependent components of the project. These dependent components can come from the NPM warehouse. When developers update the dependent components of the project, they will publish these updated components back to the NPM warehouse for use in other projects or teams.

[0042] The component upgrade system 100 includes an input module 11 for obtaining upgraded target components and corresponding target version information.

[0043] The component upgrade system 100 includes a processing module 12 for obtaining version information of several dependent components corresponding to the target component, and updating the version information of the dependent components based on the target version information according to the dependency hierarchy order of the dependent components.

[0044] The component upgrade system 100 includes an output module 13 for outputting updated version information of dependent components to corresponding dependent components, so that the dependent components are updated according to the updated version information.

[0045] like Figure 2 As shown, an embodiment of the present invention provides a component upgrading method.

[0046] The component upgrading method is applied to a component upgrading system.

[0047] In one embodiment, the component upgrade system can be as follows: Figure 1 The configuration is performed as described above, and the corresponding technical solution is set and referenced in the generation method provided by the present invention. Of course, the component upgrade system applied by the component upgrade method provided by the present invention is not limited to this configuration structure.

[0048] like Figure 2 As shown, a component upgrading method provided in one embodiment of the present invention includes the following steps.

[0049] Step S1, obtaining the upgraded target component and the corresponding target version information;

[0050] Step S2, obtaining version information of several dependent components corresponding to the target component, and updating the version information of the dependent components based on the target version information according to the dependency hierarchy order of the dependent components;

[0051] Step S3, outputting the updated version information of the dependent component to the corresponding dependent component, so that the dependent component is updated according to the updated version information.

[0052] In this way, by obtaining the upgraded target component and the corresponding target version information, the version information of several dependent components corresponding to the target component is determined, and the version information of the dependent components is updated based on the target version information in accordance with the dependency hierarchy order of the dependent components. This method ensures that all dependent components are updated based on the latest target component version by updating the version information of the dependent components layer by layer, thereby maintaining the consistency and accuracy of the component library. In addition, it can greatly reduce the workload of manually updating the version information of the dependent components, reduce the chance of human intervention, reduce the risk of introducing errors due to improper operation or omissions, and improve the efficiency of the upgrade process.

[0053] In the above step S1, the target component is the component whose version has changed. It is the starting point of the entire upgrade process, or the source of this upgrade. In other words, in the process of software development and version control, when the developer upgrades or modifies a component, this component becomes the target component. The upgrade or modification of the target component may trigger the need to update the version of other dependent components, because the new version of the target component may require its dependent components to be adjusted accordingly to avoid the instance sharing problem caused by non-unique dependent instances.

[0054] The target version information refers to the version information corresponding to the target component after it is upgraded or updated; the dependent component refers to the component that has a dependency relationship with the target component. During the software or system development process, there is a mutual dependency relationship between components. The normal operation of a component may need to rely on the services or functions provided by other components. These components that have a dependency relationship with the target component are called dependent components.

[0055] In the above step S2, the dependency hierarchy order refers to a hierarchical structure formed by the dependency relationships between dependent components, that is, one component may depend on another component, and the dependent component may depend on other components, thus forming a hierarchical structure.

[0056] After obtaining the target component, all other dependent components that have a dependency relationship with the target component are determined by scanning the project path where the target component is located.

[0057] Based on this, in one embodiment, before step S2, the method of the present invention may further include the following steps.

[0058] Step P21, determining the project path where the target component is located;

[0059] Step P22, traversing other project components under the project path, parsing the configuration file corresponding to each project component, and determining a number of dependent components that depend on the target component;

[0060] Step S2', parsing the configuration file corresponding to each dependent component to determine the corresponding version information.

[0061] In this way, by determining the project path where the target component is located and traversing all other project components under the project component, all other dependent components that have a dependency relationship with the target component can be fully covered, avoiding missing dependent components and ensuring the stability and consistency of the project.

[0062] In the above step P21, the project path refers to the location of the file or resource in the project, which is used to indicate which files the application should load when it is executed. The project path can be a relative path (i.e., a path relative to the location of the current file) or an absolute path (i.e., a complete path starting from the root directory).

[0063] In a specific embodiment, the above-mentioned project path may also be predefined.

[0064] In a specific embodiment, in the above step P22, traversing other project components under the project path refers to traversing all directories under the same directory structure as the target component, and the directory name is the project component (or module) name, and it is stored in the defined modules variable, and the structure of the modules variable is:

[0065] [{"moduleName":"module1"},{"moduleName":"module2"},...,{"moduleName":"moduleN"}], where "moduleName" is the attribute field name and "module1" is the name of the project component.

[0066] In one embodiment, the configuration file is a package.json file, which is used to define metadata and dependency relationships of project components or dependent components.

[0067] When the modules variable containing all project components is obtained, the modules variable is looped, and the package.json configuration files under the project components are read one by one by splicing the project path and the project component name, and the corresponding dependency attribute fields (i.e., dependencies) are determined. According to the dependency attribute fields, the project components whose dependent components are the target components are obtained, and the modules variable is updated. The modules variable is used to store all dependent components that have a dependency relationship with the target component.

[0068] After updating the modules variable, the package.json configuration files under the dependent components are read one by one to determine the first version attribute field (ie, latest), the second version attribute field (ie, version), and the dependency attribute field corresponding to the dependent component.

[0069] Check several dependent components under the dependency attribute field to determine whether the dependent component is the dependent version information of the target component; determine whether the dependent version information is consistent with the target version information after the target component is upgraded; if not, store the target version information of the target component in the latest attribute field (i.e., the first version attribute field).

[0070] In one embodiment, the updating of the version information of the dependent component based on the target version information includes: determining a number of first dependent components that have a direct dependency relationship with the target component; judging whether the version information of the second version attribute field corresponding to the first dependent component is consistent with the target version information; if not, updating the first version attribute field of the first dependent component based on the target configuration information.

[0071] In this way, the version information of all first dependent components that directly depend on the target component can be updated to the latest version, so that the interfaces and function calls between them will remain consistent, reducing conflicts and errors caused by version mismatches.

[0072] For example, the target component is module1, and the corresponding target version information is "1.0.1". When cyclically scanning the configuration files of dependent components, it is found that the dependent component in the dependency attribute field (dependencies) of module2 is module1, and its corresponding dependency version information is "1.0.0", which is inconsistent with the target version information "1.0.1", indicating that module2 is a dependent component of the target component module1 and needs to be updated. In this case, the value of the latest attribute field (i.e., the second version attribute field) in module2 is updated to "1.0.1".

[0073] In one embodiment, the first version attribute field is used to mark the version information of the dependent component after the update operation, the second version attribute field is used to mark the version information of the dependent component before the update operation, and the dependency attribute field is used to mark the version information of several other dependent components on which the current dependent component depends.

[0074] In a specific embodiment, the dependency attribute field includes a dependency component name and dependency version information of the corresponding dependency component. The dependency component name and dependency version information may be stored in the form of a key-value pair.

[0075] Specifically, the first version attribute field, the second version attribute field, and the dependency attribute field of the dependent component are stored together in the modules variable, that is, the modules variable is updated to the following structure:

[0076] [{"moduleName": "module1", "version": "1.0.3", "latest": "1.0.3", "dependencies": {"module2": "1.5.1", "module3": "0.7.6"}}, ...].

[0077] In the updated modules variable, if the current project component name is module1, the dependent components of this project component are module2 and module3. If the target component is module2, module1 is the dependent component of the target component.

[0078] It should be noted that both the target component and the dependent component have two types of version information. One is the version information of the component itself, such as the first version attribute field and the second version attribute field, and the other is the version information corresponding to the dependent component of the component, that is, the dependent version information recorded in the dependency attribute field.

[0079] For example, taking the updated modules variable as an example, the values ​​corresponding to the "version" and "latest" attribute fields are "1.0.3", the version information of the dependent component module1 itself is "1.0.3", the version information of the dependent component module2 it depends on is "1.5.1", and the version information of the dependent component module3 is "0.7.6".

[0080] Of course, you can also perform filtering operations on dependent components while traversing other project components under the project path, and store the first version attribute field, the second version attribute field, and the dependency attribute field in the configuration file corresponding to the dependent components that meet the conditions into the modules variable. The order of the processing process is not specifically limited.

[0081] The dependency hierarchy order in the above step S2 can determine the hierarchical structure of the dependent components by the following method, and then update the version information of the dependent components according to the dependency hierarchy order of the hierarchical structure.

[0082] like Figure 3 As shown, in one embodiment, step S2 of the present invention may specifically include the following steps.

[0083] Step S21, determining a number of first dependent components that have a direct dependency relationship with the target component, and determining a number of second dependent components that have a direct dependency relationship with the first dependent component;

[0084] Step S22, determining the dependent components of each dependency level layer by layer until all dependent components with dependency relationships are covered, and determining the corresponding version information according to the configuration file of each dependent component;

[0085] Step S23: updating the version information of the first dependent component based on the target version information, and updating the version information of the second dependent component based on the updated version information of the first dependent component.

[0086] In this way, by identifying and covering all dependent components that have dependencies on the target component layer by layer, version conflicts or runtime errors caused by dependent components can be avoided. At the same time, the version information of dependent components is updated layer by layer starting from the target component in the hierarchical order of the dependencies, reducing compatibility issues caused by version mismatches.

[0087] The dependency relationship between the second dependent component and the target component in the above step S21 is an indirect dependency relationship. Similarly, if there are other dependent components that have a direct dependency relationship with the second dependent component, a third dependent component will be formed, and so on until the Nth dependent component is obtained, and the Nth dependent component satisfies that no other components have a direct dependency relationship and / or an indirect dependency relationship with it.

[0088] In a specific embodiment, the updating of the version information of the first dependent component based on the target version information in step S23 includes:

[0089] Step S231, parsing the dependency attribute field of the first dependent component to determine that the dependent component is the first dependent version information of the target component;

[0090] Step S232: When the target version information and the first dependent version information are inconsistent, the first dependent version information is updated based on the target version information, and the first version attribute field value of the first dependent component is increased by 1.

[0091] In this way, by updating the dependency property field of the first dependent component to point to the latest version of the target component (i.e., the target version information), the first dependent component can correctly work with the target component. At the same time, the version property of the first dependent component itself is updated to ensure that the interface and function between the first dependent component and the target component remain consistent, avoiding compatibility issues caused by version mismatch.

[0092] In another specific embodiment, the step S23 of updating the version information of the second dependent component based on the updated version information of the first dependent component includes:

[0093] Step S233, obtaining and parsing the dependency attribute field of the current second dependency component, and determining that its dependency component is the second dependency version information of the first dependency component;

[0094] Step S234: based on the first version attribute field of the first dependency component, update the second dependency version information, and increase the value of the first version attribute field of the second dependency component by 1.

[0095] In this way, the dependency relationship between the second dependent component and the first dependent component can be dynamically updated, and the changes in the dependency relationship can be tracked and managed by incrementally updating the version information of the second dependent component itself.

[0096] When the first dependent component changes (such as version information changes), its downstream components (such as the second dependent component) also need to update their dependencies accordingly to ensure the stability and compatibility of the entire system.

[0097] Specifically, step S233 determines that the version information of the first dependent component on which it currently depends is the second dependent version information by parsing the dependency attribute field of the second dependent component. However, since the first dependent component has been updated in the previous step (step S232), the dependency relationship of the second dependent component also needs to be updated accordingly to point to the new version of the first dependent component (step S234). At the same time, in order to track this change, the version information of the second dependent component itself (the first version attribute field value) will also be incremented accordingly. This helps ensure that the dependencies between components are always kept up to date and avoids potential problems caused by version inconsistencies (e.g., instance sharing problems).

[0098] In a specific embodiment, a save function is defined to update the package.json configuration file under the dependent component. The function reads the "moduleName" attribute field name in parameter A to locate the dependent component path, reads the package.json configuration file content under the dependent component, and serializes it into a JSON object, which is assigned to the packageInfo variable; modifies the version field in the packageInfo variable to the latest attribute of the dependent component specified in parameter A; modifies the dependencies field in the packageInfo variable to the dependency version information of the dependent component specified in parameter A to the target version information; deserializes the content of packageInfo into a string and rewrites it into the package.json configuration file to update the package.json configuration file.

[0099] To facilitate understanding of the version information update of dependent components, as shown in Figure 4(a), for example, assuming that the target component is M1, that is, the developer has modified or updated M1, and its corresponding target version information is V1. By scanning the project path where the target component is located, it is determined that the first dependent components that directly depend on M1 are M2 and M3, the second dependent components that directly depend on M2 are M21 and M22, and the second dependent components that directly depend on M3 are M31 and M32. Among them, the version information of M2 and M3 themselves (that is, the second version attribute field, or the latest attribute field) is l:w2, l:w3 respectively, the version information of M21, M22, M31 and M32 themselves is l:w21, l:w22, l:w31 and l:w32 respectively, the dependency version information in the dependency attribute field of M2 and M3 is d:V2, d:V3 respectively, and the dependency version information in the dependency attribute field of M21, M22, M31 and M32 is d:V21, d:V22, d:V31 and d:V32 respectively.

[0100] As shown in Figure 4(b), based on the target version information, the dependency version information (value) of the dependency component name M1 (key) under the dependency property field corresponding to M2 is updated to V1, that is, updated from d:V2 to d:V1, and the version information value of M2 itself is increased by 1, that is, updated from l:w2 to l:w2+1; similarly, the dependency version information (value) of the dependency component name M1 (key) under the dependency property field corresponding to M3 is updated to V1, that is, updated from d:V3 to d:V1; at the same time, the version information value of M3 itself is increased by 1, that is, updated from l:w3 to l:w3+1, refer to the shaded area of ​​Figure 4(b).

[0101] Based on the version information of the first dependent component, the dependent version information (value) of the dependent component name M2 (key) under the dependency property field corresponding to M21 and M22 is updated to w2+1, that is, updated from d:w21 to d:w2+1, and the version information values ​​of M21 and M22 themselves are increased by 1, that is, updated from l:w21 to l:w21+1, and l:w22 to l:w22+1. Similarly, the dependent version information (value) of the dependent component name M3 (key) under the dependency property field corresponding to M31 and M32 is updated to w3+1, that is, updated from d:w31 to d:w3+1, and the version information values ​​of M31 and M32 themselves are increased by 1, that is, updated from l:w31 to l:w31+1, and w32 to w32+1, refer to the shaded area of ​​Figure 4(b).

[0102] During the release and deployment process of target components and dependent components, the release order of target components and dependent components not only affects the functional implementation of a single component, but is also the cornerstone of the stability and compatibility of the entire system.

[0103] like Figure 5 As shown, in one embodiment, the method of the present invention may also include but is not limited to the following steps.

[0104] Step N1, obtaining the target level tag value of the target component, and determining the initial level tag value of each dependent component according to the dependency level order of the dependent components;

[0105] Step N2, when performing a version information update operation on each dependent component, updating the level tag value of the dependent component based on the initial level tag value;

[0106] Step N3: Determine the release order of the target component and / or dependent components according to the updated level tag value.

[0107] In this way, by obtaining the target level tag value of the target component and reasonably arranging the release order of the dependent components according to the dependency level order of the dependent components, the system update can be promoted in an orderly manner, ensuring seamless connection between components and avoiding problems caused by version mismatch or functional conflicts.

[0108] The hierarchical tag value in the above step N1 is an identifier used to determine the release order or update order of the components, and the initial value of the identifier can be initialized according to the dependency relationship of the components and their hierarchical position in the project. The hierarchical tag value is a numerical value or code used to indicate the position of the component in the dependency hierarchy.

[0109] In one embodiment, the target level mark value is the first level, such as Level 0 or 0.

[0110] In one embodiment, the initial level tag value of each dependent component is determined according to the dependency level that the dependent component is in. This means that the higher the dependency level of a dependent component in a project (i.e., it depends on more other lower-level components), the higher its initial level tag value may be.

[0111] Among them, dependent components at the same dependency level have the same initial level tag value, and the initial level tag value corresponding to the dependent component is positively correlated with the dependency level it is in. In other words, as the dependency level increases, the initial level value of the dependent component will also increase accordingly. This positive correlation helps to clarify the release order of components according to the level tag value in the subsequent release or deployment process, ensuring that the dependency relationship is correctly processed and satisfied.

[0112] The above steps N1 to N3 can update the hierarchical tag value of the dependent component while updating the dependent component version information. In other words, steps N1 to N3 can be executed simultaneously with steps S1 to S3, or interspersed with steps S1 to S3. Steps N1 to N3 can also be executed after steps S1 to S3 are executed, and there is no specific limitation on this.

[0113] like Figure 6 As shown, in a specific embodiment, step N2 of the present invention may specifically include the following steps.

[0114] Step N21, obtaining the currently-to-be-processed dependent component and a set of historical dependent components that have completed the version information update operation, wherein the first dependency level value of the historical dependent components in the set of historical dependent components is less than the second dependency level value of the currently-to-be-processed component;

[0115] Step N22, determining whether the currently-to-be-processed dependent component exists in the historical dependent component set;

[0116] If yes, jump to step N23A, update the level mark value of the current dependent component to be processed based on the second dependency level value, determine several other dependent components corresponding to the current component to be processed, and update the level mark values ​​of the other dependent components based on the second dependency level value according to the dependency level order of the other dependent components;

[0117] If not, jump to step N23B to update the historical dependent component set based on the current dependent component to be processed.

[0118] In this way, the historical dependency component collection is used to record the dependency components that have been processed, so that repeated components can be identified and updated when processing subsequent dependency levels. According to the position of the component in the dependency relationship and the changes in the dependency level, its level tag value is dynamically updated to ensure the correctness of the dependency relationship and the stability of the system.

[0119] The historical dependency component collection is a collection for recording dependency components that have been processed before (including at least one of a version information update operation and a level tag value update operation) and related information thereof.

[0120] The above step N23A is used to process dependent components whose dependency relationships or dependency levels have changed, and step N23B is used to process dependent components that have not been processed before, add them to the historical dependent component set, and record their relevant information.

[0121] For example, as shown in Figures 7(a) and 7(b), assume that there is a four-layer dependency hierarchy structure including the target component (M1) as shown in the figure, the first dependent components directly dependent on M1 are M2, M3 and M4, the second dependent components directly dependent on M2 are M21 and M22, the second dependent components directly dependent on M3 are M31 and M32, and the third dependent components directly dependent on M21 are M5 and M3. The aleryChangeModules variable is used to store the historical dependency component set.

[0122] According to the dependency level and target level tag value of the dependent component, the initial level tag value of each dependent component is determined, that is, the initial level tag values ​​of M2, M3 and M4 are all Level1, while the initial level tag values ​​of M21, M22, M31 and M32 are all Level2, and the initial level tag values ​​of M5 and M3 are all Level3.

[0123] Initialize the historical dependency component set to be empty, and obtain the target component M1 according to the dependency hierarchy order of the dependent components. If M1 does not exist in the historical dependency component set, initialize the target level tag value of the target component M1 to Level0, and add M1 to the historical dependency component set, then aleryChangeModules={M1}; traverse the first dependent components M2, M3 and M4, and determine whether M2, M3 and M4 exist in the historical dependency component set aleryChangeModules in turn. If not, set the level tag values ​​of M2, M3 and M4 to Level1 (the same as their initial level tag values), and add them to the historical dependency component set, then the historical dependency component set is updated to aleryChangeModules={M1, M2, M3, M4}.

[0124] Similarly, traverse the second dependent components M21, M22, M31 and M32, and determine whether M31 and M32 exist in the historical dependent component set aleryChangeModules in turn. If not, set the level tag values ​​of M31 and M32 in turn to Level2 (the same as their initial level tag values), and add them to the historical dependent component set. The historical dependent component set is updated to aleryChangeModules = {M1, M2, M3, M4, M21, M22, M31, M32}

[0125] Similarly, when processing the third dependent component M5, determine whether M5 exists in the historical dependent component set aleryChangeModules. If not, set the level tag value of M5 to Level3 (the same as its initial level tag value) and add it to the historical dependent component collection. The historical dependent component collection is then updated to aleryChangeModules = {M1, M2, M3, M4, M21, M22, M31, M32, M5}.

[0126] However, when processing the third dependent component M3, M3 exists in the historical dependent component set aleryChangeModules, so the historical Level1 is updated based on the current Level3 of M3, that is, the level mark value of M3 is updated to Level3, and at the same time, other dependent components M31 and M32 that depend on M3 are determined, and the level mark values ​​of other dependent components M31 and M32 are updated to Level4.

[0127] Based on this, as shown in Figure 7(b), the hierarchical structure of M3, M31 and M32 changes, and the structural part in the dotted box is moved to the shaded part. At this time, the component at Level 0 is M1, the components at Level 1 are M2 and M4, the components at Level 2 are M21 and M22, the components at Level 3 are M3 and M5, and the components at Level 4 are M31 and M32.

[0128] In one embodiment, the updated level mark values ​​are released in batches from small to large. For example, components at Level 0 are released first, then components at Level 1, and so on, until all components are released.

[0129] In this way, by releasing in batches, potential risks can be spread over multiple stages instead of releasing them all at once, reducing the risk of system paralysis or serious errors caused by the failure of a single large-scale release.

[0130] For example, let's publish a component to the NPM repository. Define the publish function and specify that it receives a parameter A, which can be the name of the component to be published. At this time, start the child process to execute the publish command. Before executing the publish command, set the current working directory of the child process to the root directory corresponding to the component represented by parameter A, so that when publishing, the package.json configuration file can be found in this directory and the configuration information in it can be read, including the version information of the component; set and execute the publish command "npm publish", npm will start the publish operation, it will read the version field in the package.json file to determine the version number of the module, and publish this version of the component to the npm repository. The publish function will return the result of this publish operation. This result may be a status code indicating success or failure, or an object with more detailed information. By checking this result, we can understand whether the publish operation was completed successfully and whether any errors or warnings were encountered. Of course, parameter A can also be the directory path / component name where the component to be published is located.

[0131] In one embodiment, after the first batch release is completed, it is detected whether the version information of the same dependent components in the server and the client are consistent; if so, the client is controlled to execute the second batch release until the release of dependent components corresponding to all level tag values ​​is completed.

[0132] In this way, by checking after each batch release, possible problems can be discovered and located in a timely manner, avoiding release failures caused by accumulated problems.

[0133] For example, define a check function to call the NPM warehouse component interface information and determine the latest version information of its component in the remote warehouse. The function includes parameters A (component name) and B (component version information). Specifically, create an http request to access the component information interface of the NPM warehouse, and return the component information corresponding to parameter A in the remote warehouse according to parameter A; parse the http return information and convert it into a JSON object to determine whether its version information is consistent with parameter B. If it is consistent, the check function returns true and performs the next component release operation; if it is inconsistent, start the timer and recursively call its own function (check function) after 10 seconds to continue checking.

[0134] The above-mentioned various implementation modes, embodiments or specific examples provided by the present invention can be combined with each other to finally form multiple better implementation modes.

[0135] The component upgrade method of the present invention can be implemented by defining a scan function, which is used to scan the dependency information (dependency attribute field) of all project components under a specified project path and provide a function of storing component information. The input parameter A of the scan function is the project path to be scanned. The implementation logic of the scan function is as follows:

[0136] Initialize the variables modules, needUpgradeModules, and updateChangeModules; modules is used to store the configuration information of all dependent components, including the dependent component name, version information, latest version information, and at least one of the dependency information; needUpgradeModules is used to store the component information that needs to be updated in the current round; updateChangeModules is used to store all component information that has already changed.

[0137] Scan and read all directories under the parameter A path, store the directory name as the component name in the modules variable, such as modules = [{"moduleName":"module1"},......]; loop through each project component in the modules variable, concatenate parameter A with the component name, read the package.json configuration file under each component, extract the module's version attribute field (version information) and dependencies attribute field (dependency component information) from the package.json configuration file, store this information in the modules variable, and set the latest attribute field for each project component, with the default value being the same as the version attribute value. For example, modules = [{"moduleName":"module1","version":"1.0.3","latest":"1.0.3","dependencies":{"module2":"1.5.1","module3":"0.7.6"}},.....]

[0138] Traverse each project component in the modules variable again, check each dependent component under the dependencies property of each project component, find the corresponding dependency version information of the target component in the modules, and compare the latest property with the dependency version information recorded in the dependencies of the current component; if the latest version information corresponding to the latest property field is greater than the current dependency version information, it means that the version information of the dependent component needs to be updated. Store the dependency package information that needs to be updated in the form of changeVersionPackage in the information of the current module. For example, modules=[{"moduleName":"module1","version":"1.0.3","latest":"1.0.3","dependencies":{"module2":"1.5.1","module3":"0.7.6"},"cha ngeVersionPackage":{"module2":{"curVersion":"1.5.1","latest":"1.5.2"},"module3",{"curVersion":"0.7.6","latest":"0.8.1"}},...].

[0139] Filter the modules variable to select the modules containing the dependency package information to be updated and store them in the needUpgradeModules variable. If the length of the needUpgradeModules variable is 0, it means that there is no module that needs to be updated. The function returns the updateChangeModules variable and exits. Otherwise, traverse each dependent component in the needUpgradeModules variable, update the version information of the dependent component, and overwrite the latest version number (latest attribute value) recorded in changeVersionPackage with the dependency version information of the corresponding dependent component in dependencies. Update the latest attribute value of the dependent component itself and add 1 to the version number at the end. At this time, the needUpgradeModules variable structure is as follows:

[0140] [{"moduleName":"module1","version":"1.0.3","latest":"1.0.4","dependenci es":{"module2":"1.5.2","module3":"0.8.1"},"changeVersionPackage":{"module2":{"curVersion":"1.5.1","latest":"1.5.2"},"module3",{"curVersion":"0.7.6","lat est”:”0.8.1”}},.....].

[0141] Synchronize the changes in needUpgradeModules to the modules variable, and ensure that the version information of the dependent components and the dependent version information of the dependent components are updated values. Get the maximum level attribute (i.e. maxLevel) of all components in the aleryChangeModules variable. If aleryChangeModules is empty, set level = 1; otherwise, set level = maxLevel + 1. Traverse each dependent component in the needUpgradeModules variable; determine whether the dependent component already exists in the aleryChangeModules variable; if not, add the level attribute to it and store it in aleryChangeModules; if it exists, update the information of the dependent component, including the changeVersionPackage attribute and the level attribute, and add it back to the aleryChangeModules variable.

[0142] Use while(true) infinite loop to wrap the above steps to ensure that the versions of all levels of dependent components and their dependent components (dependency version information in the dependencies attribute field) are updated. At the end of each loop, check whether the length of the needUpgradeModules variable is 0. If it is 0, the loop is interrupted and the data of the aleryChangeModules variable is returned.

[0143] Write a publishing program. Define the main function as the main entry function in the publishing program to implement the main control flow of the component upgrade method. The function can accept parameter A (the root directory of the target component, which is the execution path of the publishing command by default). Call the scan function in the main function and store the result of the component to be published returned by the scan function in the waitiUpgradePackages variable; obtain the maximum level tag value (or level attribute value) in waitiUpgradePackages, and execute a loop from 1 to the maximum level tag value (i.e. maxLevel).

[0144] Specifically, filter out the component information whose level attribute value is equal to the current number of loops from the waitiUpgradePackages variable, and call the save function in batches to update the package.json file of the current level components; after the save operation, call the publish function in batches to perform the refrigerator publishing operation of the current level components, and start the check function at the same time to check the remote warehouse version of the current level dependent components. When the local version information of all dependent components of the current level is consistent with the version information of the corresponding dependent components in the remote warehouse, enter the next level (level tag value) loop until all dependent components that need to be published in all levels of the dependent hierarchy structure are published. When all dependent components are published, the information in waitiUpgradePackages is output and saved to a file.

[0145] Figure 8 A schematic diagram showing the principle structure of a component method in a preferred embodiment is shown below. Figure 8 , summarizing the processing process of this preferred embodiment.

[0146] When the release program is started, the scan function is called, which scans and loads the information of all dependent components and records the current property information of each dependent component (including at least one of the dependency information and version information); parses the information of the dependent components to determine whether the dependent components need a version update; if not, the result is directly output, indicating that the current dependent components are all the latest versions and no update operation is required; if so, the information of these dependent components is saved, and the saved dependent component version information is updated to the latest version, and the release phase is entered to start the release process. During the release process, the program will also check the release progress (i.e., the check function). Specifically, the program will query the NPM repository to compare the currently released version with the latest version in the NPM repository; if the version information of all dependent components is consistent, the release is complete.

[0147] One embodiment of the present invention provides a computer-readable storage medium.

[0148] In one embodiment, a computer readable storage medium stores a computer program executed by the processor mentioned above, or a component upgrade method in any of the technical solutions mentioned above.

[0149] When the processor executes the computer program, it can execute the description of the component upgrade method in any of the above technical solutions, so it will not be repeated here. In addition, the description of the beneficial effects of using the same method will not be repeated.

[0150] The computer-readable storage medium may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0151] In summary, the component upgrade method, system and computer storage medium provided by the present invention. By obtaining the upgraded target component and the corresponding target version information, determining the version information of several dependent components corresponding to the target component, and updating the version information of the dependent components based on the target version information according to the dependency hierarchy order of the dependent components, the method can ensure that all dependent components are updated based on the latest target component version by updating the version information of the dependent components layer by layer, thereby maintaining the consistency and accuracy of the component library, and can also greatly reduce the workload of manually updating the version information of the dependent components, reduce the chance of human intervention, reduce the risk of introducing errors due to improper operation or omissions, and improve the efficiency of the upgrade process.

[0152] It should be understood that although this specification is described according to implementation modes, not every implementation mode contains only one independent technical solution. This description of the specification is only for the sake of clarity. Those skilled in the art should regard the specification as a whole. The technical solutions in each implementation mode may also be appropriately combined to form other implementation modes that can be understood by those skilled in the art.

[0153] The series of detailed descriptions listed above are only specific descriptions of feasible implementation methods of the present invention. They are not intended to limit the scope of protection of the present invention. Any equivalent implementation methods or changes that do not deviate from the technical spirit of the present invention should be included in the scope of protection of the present invention.

Claims

1. A component upgrade method, characterized in that: include: Obtain the upgraded target component and corresponding target version information; Obtaining version information of several dependent components corresponding to the target component, updating the version information of the dependent components based on the target version information according to the dependency hierarchy order of the dependent components, and Output the updated version information of the dependent component to the corresponding dependent component, so that the dependent component is updated according to the updated version information.

2. The component upgrade method according to claim 1, characterized in that: Before obtaining version information of several dependent components corresponding to the target component, the method includes: Determine the project path where the target component is located; Traverse other project components under the project path, parse the configuration file corresponding to each project component, and determine several dependent components that depend on the target component; The obtaining of version information of several dependent components corresponding to the target component includes: Parse the configuration file corresponding to each dependent component to determine the corresponding version information.

3. The component upgrade method according to claim 1, characterized in that: The dependent component includes at least one of a first version attribute field, a second version attribute field and a dependency attribute field, the first version attribute field is used to mark the version information of the dependent component after the update operation, the second version attribute field is used to mark the version information of the dependent component before the update operation, and the dependency attribute field is used to mark the version information of several other dependent components on which the current dependent component depends.

4. The component upgrade method according to claim 1, characterized in that: The obtaining of version information of several dependent components corresponding to the target component includes: Determine a plurality of first dependent components that have a direct dependency relationship with the target component, and determine a plurality of second dependent components that have a direct dependency relationship with the first dependent component; Determine the dependent components of each dependency level layer by layer until all dependent components with dependencies are covered, and determine the corresponding version information based on the configuration files of each dependent component; The updating of the version information of the dependent components based on the target version information according to the dependency hierarchy order of the dependent components includes: The version information of the first dependent component is updated based on the target version information, and the version information of the second dependent component is updated based on the updated version information of the first dependent component.

5. The component upgrade method according to claim 4, characterized in that: The updating of the version information of the first dependent component based on the target version information includes: Parse the dependency attribute field of the first dependent component to determine that the dependent component is the first dependent version information of the target component; When the target version information and the first dependent version information are inconsistent, the first dependent version information is updated based on the target version information, and the first version attribute field value of the first dependent component is increased by 1.

6. The component upgrade method according to claim 4, characterized in that: The updating of the version information of the second dependent component based on the updated version information of the first dependent component includes: Obtain and parse the dependency attribute field of the current second dependency component to determine that its dependency component is the second dependency version information of the first dependency component; Based on the first version attribute field of the first dependency component, the second dependency version information is updated, and the value of the first version attribute field of the second dependency component is increased by 1.

7. The component upgrade method according to claim 1, characterized in that: The updating of the version information of the dependent component based on the target version information includes: Determine a plurality of first dependent components that have a direct dependency relationship with the target component; Determine whether the version information corresponding to the second version attribute field of the first dependent component is consistent with the target version information; If not, the first version attribute field of the first dependent component is updated based on the target configuration information.

8. The component upgrade method according to claim 1, characterized in that: The method further comprises: Obtain the target level tag value of the target component, and determine the initial level tag value of each dependent component according to the dependency level order of the dependent components; When performing a version information update operation on each dependent component, the level tag value of the dependent component is updated based on the initial level tag value; According to the updated level tag value, the release order of the target component and / or dependent components is determined.

9. The component upgrade method according to claim 8, characterized in that: The step of determining the initial level tag value of each dependent component according to the dependency level order of the dependent components includes: According to the dependency level of the dependent component, the initial level tag value of each dependent component is determined, wherein dependent components at the same dependency level have the same initial level tag value, and the initial level tag value corresponding to the dependent component is positively correlated with the dependency level at which it is located.

10. The component upgrade method according to claim 8, characterized in that: When performing the version information update operation on each dependent component, updating the level tag value of the dependent component based on the initial level tag value includes: Obtaining a currently pending dependent component and a set of historical dependent components that have completed version information update operations, wherein a first dependency level value of the historical dependent components in the set of historical dependent components is less than a second dependency level value of the currently pending component; Determine whether the current dependency component to be processed exists in the historical dependency component set; If yes, then based on the second dependency level value, the level mark value of the current dependent component to be processed is updated, a number of other dependent components corresponding to the current component to be processed are determined, and according to the dependency level order of the other dependent components, the level mark values ​​of the other dependent components are updated based on the second dependency level value; If not, the historical dependency component set is updated based on the currently pending dependency components.

11. The component upgrade method according to claim 8, characterized in that: After determining the release order of the dependent components according to the updated level mark value, the method further includes: Release the updated layer tag values ​​in batches from small to large, and check whether the version information of the same dependent components on the server and client are consistent after the first batch is released. If so, the control client executes the second batch release until the release of dependent components corresponding to all level tag values ​​is completed.

12. A component upgrade system, characterized in that: include: An input module is used to obtain the upgraded target component and the corresponding target version information; A processing module, used to obtain version information of several dependent components corresponding to the target component, and update the version information of the dependent components based on the target version information according to the dependency hierarchy order of the dependent components; The output module is used to output the updated version information of the dependent component to the corresponding dependent component, so that the dependent component is updated according to the updated version information.

13. A computer storage medium comprising: at least one processor; A memory storing a computer program executable on the processor, wherein the processor executes the steps of the component upgrade method according to claims 1 to 11 when executing the program.

Images