Component version management method, device, electronic device and system

Abstract

The present invention relates to the technical field of component management, and specifically relates to a method, device, electronic device and system for component version management. The method includes obtaining an identifier of a target application and a corresponding branch name; obtaining target version configuration information of a corresponding target component based on the identifier and the branch name; updating local version configuration information of the target component based on the target version information, where the local version configuration information is applied to the target application in the form of a variable; storing the local version configuration information in a code repository hidden file, and the code repository hidden file is used to hide the content in the code repository hidden file when the code is submitted to the code repository. The local configuration information is applied to the target application in the form of a variable, and at the same time, the local configuration information is stored in the code repository hidden file, and the content in the code repository hidden file will not be submitted to the code repository, avoiding the problem of code merge conflicts caused by multi-party development.

Description

Technical Field

[0001] The present invention relates to the technical field of component management, and particularly to a method, device, electronic device and system for component version management. Background Art

[0002] With the advancement of componentization on the Android side, the number of components associated with an app is increasing. For example, an app depends on up to 120 components. Then, the version number management and version unification of components have become difficult problems.

[0003] The existing solution is to record the latest version number of components through the Ark platform, manually increment the component version number by 1, and submit it to GitLab after completion; then package the components into binary compressed packages aar through Jenkins packaging and upload them to Maven; then modify the configuration file to use the latest version of the components. When multiple people collaborate to develop an application, if a certain component is updated, other terminals collaborating in development need to upgrade the configuration of the component to the latest version for application development on the latest version. However, when merging code, due to multiple people modifying the component version number and application configuration file, merge conflicts are likely to occur. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a method, device, electronic device and system for component version management to solve the problem of code merge conflicts caused by multiple people collaborating in development.

[0005] According to a first aspect, an embodiment of the present invention provides a method for component version management, including:

[0006] Obtain the identifier of the target application and the corresponding branch name;

[0007] Obtain the target version configuration information of the corresponding target component based on the identifier and the branch name;

[0008] Update the local version configuration information of the target component based on the target version information, and the local version configuration information is applied to the target application in the form of variables;

[0009] Store the local version configuration information in a code repository hidden file, and the code repository hidden file is used to hide the content in the code repository hidden file when the code is submitted to the code repository.

[0010] The component version management method provided by the embodiments of the present invention updates the local version configuration information of the target component locally using the target version configuration information, so that all collaborative designers of the target application can develop the application under the latest component version. Moreover, the local configuration information is applied to the target application in the form of variables. In this way, the variable names remain unchanged, and only the variable values are updated each time, which can avoid code updates. At the same time, the local configuration information is stored in the hidden file of the code repository, and the content in this code repository hidden file will not be committed to the code repository, thus avoiding the problem of code merge conflicts caused by multi-party development.

[0011] In combination with the first aspect, in the first implementation manner of the first aspect, the obtaining of the target version configuration information of the corresponding target component based on the identifier and the branch name includes:

[0012] Obtain the development attributes of the target component;

[0013] Pull the component version information from the corresponding branch of the component management platform based on the development attributes;

[0014] Parse the component version information to determine the target version configuration information.

[0015] The component version management method provided by the embodiments of the present invention pulls the component version information from the corresponding branch of the component management platform according to the development attributes of the target component, ensuring the correspondence between the component version information and the development attributes, and improving the accuracy of the determined target version configuration information.

[0016] In combination with the first implementation manner of the first aspect, in the second implementation manner of the first aspect, the pulling of the component version information from the corresponding branch of the component management platform based on the development attributes includes:

[0017] When the development attribute is a release attribute, pull the component version information from the main branch of the component management platform;

[0018] When the development attribute is a test attribute, pull the component version information from the feature branch of the component management platform.

[0019] In combination with the first aspect, in the third implementation manner of the first aspect, the updating of the local version configuration information of the target component based on the target version information includes:

[0020] Generate a component configuration based on the target version information to update the local version configuration information of the target component;

[0021] Based on the development attributes of the target component, place the generated component configuration in the corresponding target development directory, where the target development directory includes a reference configuration for checking the reference to the local version configuration information.

[0022] In the component version management method provided by the embodiments of the present invention, when an application depends on a component, in fact, it only depends on a reference. The name of this reference, that is, the variable name, remains unchanged, but its value changes with the different component version numbers stored in the component version management platform. When executing the reference, the reference will be checked. If there is no such reference, the command will report an error and exit. Therefore, the setting of this reference configuration can ensure that the local execution of the reference command can succeed.

[0023] Combined with the third implementation manner of the first aspect, in the fourth implementation manner of the first aspect, the storing the local version configuration information in the code repository hidden file includes:

[0024] Add the target development directory to the code repository hidden file.

[0025] Combined with the first aspect, or any one of the first to fourth implementation manners of the first aspect, in the fifth implementation manner of the first aspect, the target version configuration information includes a target version number, and the target version number includes the name of the target component, the timestamp for building the target component, the build number of the target component, and a code identifier for indicating the code corresponding to the target component.

[0026] In the component version management method provided by the embodiments of the present invention, the timestamp of the target version number is used to ensure the uniqueness of the target version number, and the build number is used to increase the dimension to ensure a greater degree of uniqueness. The code identifier is used to indicate which part of the code is used by the target component, which is convenient for problem positioning.

[0027] According to the second aspect, embodiments of the present invention provide a component version management device, including:

[0028] A first acquisition module, configured to acquire an identifier of a target application and a corresponding branch name;

[0029] A second acquisition module, configured to acquire target version configuration information of a corresponding target component based on the identifier and the branch name;

[0030] An update module, configured to update the local version configuration information of the target component based on the target version information, and the local version configuration information is applied to the target application in the form of a variable;

[0031] A storage module, configured to store the local version configuration information into a code repository hidden file, where the code repository hidden file is used to hide the content within the code repository hidden file when the code is committed.

[0032] According to a third aspect, an embodiment of the present invention provides an electronic device, including: a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to execute the component version management method described in the first aspect or any one of the embodiments of the first aspect.

[0033] According to a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium, which stores computer instructions for causing a computer to execute the component version management method described in the first aspect or any one of the embodiments of the first aspect.

[0034] According to a fifth aspect, an embodiment of the present invention provides a component version management system, including:

[0035] A component construction platform, configured to construct components and generate configuration information of the constructed components, and upload the configuration information to a component management platform;

[0036] A component management platform, configured to manage the configuration information of components, where the configuration information includes a target application, a branch name, a mapping relationship between the components and the configuration information;

[0037] The electronic device described in the third aspect of the present invention is connected to the component management platform.

[0038] It should be noted that for the corresponding beneficial effects of the component version management device, electronic device, computer-readable storage medium, and component version management system provided in the embodiments of the present invention, please refer to the description of the corresponding beneficial effects of the component version management method above, and details will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the following will briefly introduce the drawings required for the description of the specific embodiments or the prior art. Obviously, the drawings in the following description are some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0040] Figure 1a is a structural block diagram of a component version management system according to an embodiment of the present invention;

[0041] Figure 1bIt is a structural block diagram of a component version management system according to an embodiment of the present invention;

[0042] Figure 2 It is a schematic diagram of a mapping relationship managed by a component management platform according to an embodiment of the present invention;

[0043] Figure 3 It is a flowchart of a component version management method according to an embodiment of the present invention;

[0044] Figure 4 It is a flowchart of a component version management method according to an embodiment of the present invention;

[0045] Figure 5 It is a flowchart of a component version management method according to an embodiment of the present invention;

[0046] Figure 6 It is a schematic diagram of a target version number according to an embodiment of the present invention;

[0047] Figure 7 It is a flowchart of a component version management method according to an embodiment of the present invention;

[0048] Figure 8 It is a structural block diagram of a component version management device according to an embodiment of the present invention;

[0049] Figure 9 It is a schematic hardware structure diagram of an electronic device provided by an embodiment of the present invention. Detailed implementation manners

[0050] To make the objectives, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Apparently, the described embodiments are some but not all of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.

[0051] For a target application, development is generally carried out in the form of components, that is, multiple people collaborate to develop the target application. Among them, the upgrade of the target application is the upgrade of each component. For each collaboration party developing the target application, when a component is updated, the local component needs to be synchronously updated to ensure that the developed application is based on the latest component version. The component version management method provided by the embodiments of the present invention is applied to the scenario where when a component is updated, each collaboration party needs to update the local component configuration.

[0052] The embodiments of the present invention provide a component version management system, as Figure 1aAs shown in the figure, it includes: a component construction platform 10, a component management platform 20, and an electronic device 30. Among them, the component construction platform is used to construct components and generate configuration information of the constructed components, and upload the configuration information to the component management platform 20 to uniformly manage the configuration information of each component by using the component management platform 20. The configuration information of the component includes the version number of the component, the mapping relationships between the component and the application, the branch, etc. For the component management platform 20, it maintains the configuration information of each component.

[0053] When each collaborating party updates the local configuration information, it obtains the latest version of the component configuration information from the component management platform 20, and uses the obtained component configuration information to update the local configuration information. At the same time, after the update is completed, the locally generated configuration information is stored in the code repository hidden file, so that when the code is submitted to the code repository later, the content in the code repository hidden file will not be submitted to the code repository. This is because, as described above, the target application is developed through multi-party collaboration. If multiple parties upload their local configuration files to the code repository, it will inevitably lead to code merge conflicts. Based on this, in the embodiments of the present invention, after the collaborating party updates the local configuration information, it will not submit the generated configuration file to the code repository to avoid the problem of code merge conflicts.

[0054] The electronic device 30 is each of the collaborating parties described above. Each collaborating party obtains the configuration information of the component from the component management platform to update the local configuration information, and specifically performs component version management by executing the component version management method described in the embodiments of the present invention.

[0055] The specific implementation details of the component version management method will be described in detail below.

[0056] In some alternative embodiments, as Figure 1b shown, the component construction platform is the jenkins platform, and the component management platform is the Ark platform. The components constructed in the jenkins platform are uploaded to the mvn server, so that other collaborating parties can download the component packages from the mvn server for application construction later. The application component dependency relationships are maintained in the Ark platform to implement application management, component management, and branch component management. Mvn server: a jar&aar package management platform that stores jar and aar packages and can record the dependency relationships of components. For example, the mapping relationships of the target application maintained in the Ark platform are as Figure 2 shown. On jenkins, through a script, execute

[0057] . / gradlew -Dorg.gradle.daemon=false ${module_name}:uploadArchives

[0058] The command is used to build components. Here, the components will be packaged into aar or jar packages, and the mvn interface will be called to upload the aar or jar to the mvn server. At the same time, the generated component version number, component name, appId, and branch name will be uploaded to the Ark platform by calling the Ark interface to establish the mapping relationship between the application, branch name, component, and version number. The specific processing process is as follows:

[0059] 1) The jenkins platform builds the components, and the generated aar package is uploaded to mvn for storage;

[0060] 2) The jenkins platform calls the Ark interface to update the component version number information stored in the Ark;

[0061] 3) The collaborating party's application calls the Ark interface through a script to obtain the component version number information on which the application and feature branch depend, and automatically generates the component configuration;

[0062] 4) The collaborating party generates the component and application configuration file build.gradle and applies the component in the form of variables.

[0063] The component version management system provided by the embodiment of the present invention records the component version number through the component management platform and ignores the configuration file locally, avoiding frequent modification of the component and application configuration files, thereby reducing merge conflicts.

[0064] According to the embodiment of the present invention, an embodiment of a component version management method is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than here.

[0065] In this embodiment, a component version management method is provided, which can be used in the above-mentioned electronic devices such as computers, mobile phones, and tablets. In the following description, since the electronic device is used to execute the component version management method, the electronic device is referred to as the local. Figure 3 It is a flowchart of the component version management method according to the embodiment of the present invention, as Figure 3 shown, and the process includes the following steps:

[0066] S11, obtain the identifier of the target application and the corresponding branch name.

[0067] The local script stores the identifier of the target application, i.e., appId, and the corresponding branch name. Locally, there may be multiple identifiers of the target application and the corresponding branch names maintained. When updating the corresponding component configuration information, locally, the component configuration information can be updated sequentially using the identifiers of each target application and the corresponding branch names; or locally, by communicating and connecting with the component management platform, the component management platform confirms which target application's component configuration information needs to be updated currently. Accordingly, locally, the identifier of the target application and the corresponding branch name are obtained.

[0068] S12. Obtain the target version configuration information of the corresponding target component based on the identifier and the branch name.

[0069] As described above, the component management platform is used to maintain the mapping relationship of the target application, the branch name, the component, and the configuration information. Therefore, locally, the target version configuration information of the target component can be obtained from the component management platform using the identifier of the target application and the branch name. Among them, the target version configuration information is the configuration information of the latest version of each target component.

[0070] It should be noted that the target component corresponding to the identifier and the branch name may be one or multiple, and no specific limitation is imposed on its specific quantity here.

[0071] The target version configuration information includes, but is not limited to, the version number of the target version, which is generated by the component construction platform and managed by the component management platform. The component construction platform generates the component version number of the component when the component construction is completed. Among them, the composition of the component version number includes, but is not limited to, the component name, the timestamp for generating the component, etc. The timestamp is used to ensure the uniqueness of the component version number. The specific composition of the component version number will be described in detail below.

[0072] S13. Update the local version configuration information of the target component based on the target version information.

[0073] Among them, the local version configuration information is applied to the target application in the form of variables.

[0074] After locally obtaining the target version information, the local version configuration information of the target component is updated. Among them, the local version configuration information is applied to the target application in the form of variables, that is, the target application references the component in a reference form, that is, when the target application references the component, it is processed in the way of variable names, and the reference content corresponds to the value of the variable, and the value of the variable is determined based on the local version configuration information.

[0075] For example, each time the local configuration information is updated, a component configuration is generated such that the version number in the generated component configuration is the same as the version number in the target version configuration information. Correspondingly, if the value of a variable in the generated configuration information is inconsistent with the value of the same variable in the previous version, then when the subsequent target application references this component, although the same variable name is used compared to the previous version, due to the different variable values, the target application can be updated without modifying the code.

[0076] S14. Store the local version configuration information in a hidden file of the code repository.

[0077] Among them, the hidden file of the code repository is used to hide the content in the hidden file of the code repository when the code is committed to the code repository.

[0078] As described above, after the local application is packaged, the corresponding packaged content needs to be sent to the code repository for software release of the target application. Among them, for the local version configuration information generated locally, it does not need to be uploaded to the code repository. Therefore, the local version configuration information is stored in a hidden file of the code repository to avoid uploading the local version configuration information. Although the local version configuration information is not uploaded to the code repository, the local version configuration information is referenced in the form of variables, so the value of the variable can still be referenced.

[0079] The component version management method provided in this embodiment updates the local version configuration information of the target component using the target version configuration information, so that all parties involved in the collaborative design of the target application can perform application development under the latest component version. Moreover, the local configuration information is applied to the target application in the form of variables, and the variable name remains unchanged in this way. Only the variable value is updated each time, which can avoid code updates. At the same time, the local configuration information is stored in a hidden file of the code repository, and the content in this hidden file of the code repository will not be committed to the code repository, avoiding the problem of code merge conflicts caused by multi-party development.

[0080] In this embodiment, a component version management method is provided, which can be used in the above-mentioned electronic devices, such as computers, mobile phones, tablet computers, etc. Figure 4 It is a flowchart of the component version management method according to an embodiment of the present invention, as Figure 4 shown. This process includes the following steps:

[0081] S21. Obtain the identifier of the target application and the corresponding branch name.

[0082] For details, please refer to Figure 3 S11 in the illustrated embodiment, which will not be elaborated here.

[0083] S22. Obtain the target version configuration information of the corresponding target component based on the identifier and the branch name.

[0084] Specifically, the above S22 includes:

[0085] S221. Obtain the development attributes of the target component.

[0086] The development component exists in the local script file. The electronic device reads from the local script file to obtain the development attributes of the target component. The development attributes include the release attribute, which represents the stable version, and the test attribute, which represents the unstable version.

[0087] S222. Pull the component version information from the corresponding branch of the component management platform based on the development attributes.

[0088] In the component management platform, the component version information is maintained according to different development attributes.

[0089] In some alternative embodiments, the above S222 includes:

[0090] When the development attribute is the release attribute, pull the component version information from the main branch of the component management platform. Among them, the main branch corresponds to relatively stable component version information, and the components used are all the release versions in the mvn server as described above Figure 1b that is, the release version.

[0091] When the development attribute is the test attribute, pull the component version information from the feature branch of the component management platform. Among them, the feature branch corresponds to the component version information that is under development and relatively unstable, and the components used are all the snapshot versions in the mvn server as described above Figure 1b that is, the snapshot version.

[0092] S223. Parse the component version information to determine the target version configuration information.

[0093] The local device parses the pulled component version information to obtain the corresponding target version configuration information.

[0094] S23. Update the local version configuration information of the target component based on the target version information.

[0095] Among them, the local version configuration information is applied to the target application in the form of variables.

[0096] For details, please refer to Figure 3 S13 in the illustrated embodiment, which will not be elaborated here.

[0097] S24. Store the local version configuration information in the code repository hidden file.

[0098] Among them, the code repository hidden file is used to hide the content in the code repository hidden file when the code is submitted to the code repository.

[0099] For details, please refer to Figure 3 S14 of the illustrated embodiment, which will not be elaborated here.

[0100] The component version management method provided in this embodiment pulls component version information from the corresponding branch of the component management platform for the development attributes of the target component, ensuring the correspondence between the component version information and the development attributes, and improving the accuracy of the determined target version configuration information.

[0101] In this embodiment, a component version management method is provided, which can be used for the above-mentioned electronic devices, such as computers, mobile phones, tablet computers, etc. Figure 5 is a flowchart of the component version management method according to an embodiment of the present invention, as Figure 5 shown, the process includes the following steps:

[0102] S31, obtain the identifier of the target application and the corresponding branch name.

[0103] For details, please refer to Figure 3 S11 of the illustrated embodiment, which will not be elaborated here.

[0104] S32, obtain the target version configuration information of the corresponding target component based on the identifier and the branch name.

[0105] The target version configuration information includes a target version number, and the target version number includes the name of the target component, the timestamp for building the target component, the build number of the target component, and a code identifier, and the code identifier is used to represent the code corresponding to the target component.

[0106] Specifically, as Figure 6 shown, the target version number includes the component name, the timestamp, the build number, and the code identifier, and these information are distinguished by corresponding delimiters. In order to distinguish different information, different delimiters can be used to distinguish different information. It should be noted that the delimiter is not limited to Figure 6 the form shown, and other forms can also be used, and no limitation is made thereto here, and it is specifically set according to actual needs.

[0107] The timestamp of the target version number is used to ensure the uniqueness of the target version number, the build number is used to increase the dimension to ensure a greater degree of uniqueness, and the code identifier is used to indicate which part of the code is used by the target component, which is convenient for problem positioning.

[0108] For the rest, for details, please refer to Figure 4 S22 of the illustrated embodiment, which will not be elaborated here.

[0109] S33. Update the local version configuration information of the target component based on the target version information.

[0110] Among them, the local version configuration information is applied to the target application in the form of variables.

[0111] Specifically, the above S33 includes:

[0112] S331. Generate a component configuration based on the target version information to update the local version configuration information of the target component.

[0113] S332. Based on the development attributes of the target component, place the generated component configuration in the corresponding target development directory.

[0114] Among them, the target development directory includes a reference configuration, and the reference configuration is used to check the reference to the local version configuration information.

[0115] The electronic device generates a component configuration by using the obtained target version information, thereby obtaining the local version configuration information of the target component. Based on the development attributes of the target component, it is stored in the corresponding target development directory. Among them, the development attributes are obtained from the local configuration file (in gradle.properties). For example, locally, by executing. / gradlewsyncAps, an interface provided by Ark is called, and according to the appId and branch name, the dependent components and component version numbers are obtained. The local script determines whether the develop variable in the configuration file is true, that is, determines whether the development attribute of the target component is a test attribute:

[0116] If it is true, then parse the component version information returned by Ark, generate a component configuration, and place it in the generated / debug directory of the main project. The components and the application use the component version number configured in generated / debug; this component version number is the target component version number.

[0117] If it is false, then parse the component version information returned by Ark, generate a component configuration, and place it in the generated / release directory of the main project. The components and the application use the component version number configured in generated / release; this component version number is the target component version number.

[0118] Locally, a set of reference configurations are default placed in the generated / default directory to ensure that the. / gradlew syncAps command can be executed successfully locally.

[0119] S34. Store the local version configuration information in the code repository hidden file.

[0120] Among them, the code repository hidden file is used to hide the content in the code repository hidden file when the code is submitted to the code repository.

[0121] Specifically, add the target development directory to the code repository hidden file. Corresponding to the example described above, add the generated directory to.gitignore to ignore the automatically generated configuration files and avoid configuration file modifications being uploaded to the code repository, that is, gitlab, which may cause merge conflicts during code merging.

[0122] In the component version management method provided in this embodiment, when applying dependent components, in fact, only a reference is relied on. The reference name, that is, the variable name, remains unchanged, but its value changes with the different component version numbers stored in the component version management platform. When executing the reference, the reference will be checked. If there is no such reference, the command will report an error and exit. Therefore, the setting of this reference configuration can ensure that the local execution of the reference command can succeed.

[0123] In a specific application example of this embodiment, as Figure 7 shown, when it is necessary to update the component configuration locally, the component version management method includes:

[0124] S401, execute syncAps to call the interface provided by the Ark platform;

[0125] S402, determine whether its development attribute is a test attribute. When it is a test attribute, execute S404; otherwise, execute S403;

[0126] S403, pull the configuration corresponding to the main branch and execute S405;

[0127] S404, pull the configuration corresponding to the feature branch and execute S405;

[0128] S405, read the target version configuration information;

[0129] S406, determine whether the reading is successful. If successful, execute S417; otherwise, execute S407;

[0130] S407, alarm that the update fails;

[0131] S417, traverse the components and execute S408;

[0132] S408, check whether there is a component version number. If so, execute S409; otherwise, execute S412. Specifically, for newly added components, mvn has not been uploaded yet and no version number has been generated. Such components are only placed in the configuration file first and will not be relied on;

[0133] S409. Generate component references and execute S410;

[0134] S410. Determine whether its development attribute is a test attribute. When it is a test attribute, execute S411; otherwise, execute S414. Specifically, the development attribute is obtained from the local configuration file (in gradle.properties);

[0135] S411. Update the corresponding version number in the app - snapshot configuration file and execute S416;

[0136] S414. Update the corresponding version number in the app - release configuration file and execute S416;

[0137] S412. Determine whether its development attribute is a test attribute. When it is a test attribute, execute S413; otherwise, execute S415. Specifically, the development attribute is obtained from the local configuration file (in gradle.properties);

[0138] S413. Update the app - snapshot configuration file to latestversion and execute S416;

[0139] S415. Update the app - release configuration file to latestversion and execute S415;

[0140] S416. Whether it is the last component. If so, execute S418; if not, execute S417.

[0141] In this embodiment, by using the time + "." + jenkins build number + "_" + commit number as the version number of the component uploaded to mvn, the uniqueness of the component version number is ensured, and it is convenient for problem positioning. By recording the component version number through the Ark platform and ignoring the configuration file locally, frequent modification of the component and application configuration files is avoided, thereby reducing merge conflicts. This method avoids manual modification of the configuration file by changing the naming method of the component version number. The new naming method can easily show when the component package was built and which part of the code it corresponds to, making it easier to locate problems; manual operation of modifying the component and application configuration files is no longer required, there are fewer code merge conflicts, and the error probability is lower.

[0142] In this embodiment, a component version management device is also provided. This device is used to implement the above - mentioned embodiment and preferred implementation manners, and those that have been described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that realizes a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware is also possible and contemplated.

[0143] This embodiment provides a component version management device, as Figure 8 shown, including:

[0144] A first acquisition module 51, configured to acquire an identifier of a target application and a corresponding branch name;

[0145] A second acquisition module 52, configured to acquire target version configuration information of a corresponding target component based on the identifier and the branch name;

[0146] An update module 53, configured to update local version configuration information of the target component based on the target version information, and the local version configuration information is applied to the target application in the form of a variable;

[0147] A storage module 54, configured to store the local version configuration information into a code repository hidden file, and the code repository hidden file is used to hide the content in the code repository hidden file when the code is committed.

[0148] In some alternative embodiments, the second acquisition module 52 includes:

[0149] An acquisition unit, configured to acquire a development attribute of the target component;

[0150] A pull unit, configured to pull component version information from a corresponding branch of a component management platform based on the development attribute;

[0151] An analysis unit, configured to analyze the component version information to determine the target version configuration information.

[0152] In some alternative embodiments, the pull unit includes:

[0153] A first pull subunit, configured to pull the component version information from the main branch of the component management platform when the development attribute is a release attribute;

[0154] A second pull subunit, configured to pull the component version information from a feature branch of the component management platform when the development attribute is a test attribute.

[0155] In some alternative embodiments, the update module 53 includes:

[0156] A generation unit, configured to generate a component configuration based on the target version information to update the local version configuration information of the target component;

[0157] A storage unit, configured to place the generated component configuration into a corresponding target development directory based on the development attributes of the target component in the target version information, where the target development directory includes a reference configuration for checking references to the local version configuration information.

[0158] In some alternative embodiments, the storage module 54 includes:

[0159] An adding module, configured to add the target development directory to the hidden files of the code repository.

[0160] In some alternative embodiments, the target version configuration information includes a target version number, which includes the name of the target component, a timestamp for building the target component, a build number of the target component, and a code identifier for representing the code corresponding to the target component.

[0161] The component version management device in this embodiment is presented in the form of functional units. Here, the unit refers to an ASIC circuit, a processor and a memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0162] The further function descriptions of the above-mentioned various modules are the same as those in the corresponding embodiments above, and will not be repeated here.

[0163] An embodiment of the present invention further provides an electronic device having the above-mentioned Figure 8 shown component version management device.

[0164] Please refer to Figure 9 , Figure 9 is a schematic structural diagram of an electronic device provided by an alternative embodiment of the present invention. As Figure 9 shown, the electronic device may include: at least one processor 601, such as a CPU (Central Processing Unit), at least one communication interface 603, a memory 604, and at least one communication bus 602. Among them, the communication bus 602 is used to implement connection communication between these components. Among them, the communication interface 603 may include a display screen (Display), a keyboard (Keyboard), and optionally the communication interface 603 may further include a standard wired interface and a wireless interface. The memory 604 may be a high-speed RAM memory (Random Access Memory, volatile random access memory), or a non-volatile memory, such as at least one disk memory. Optionally, the memory 604 may also be at least one storage device located far from the aforementioned processor 601. Among them, the processor 601 may be combined with Figure 8For the described apparatus, an application program is stored in the memory 604, and the processor 601 calls the program code stored in the memory 604 to execute any of the above method steps.

[0165] Among them, the communication bus 602 can be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus 602 can be divided into an address bus, a data bus, a control bus, etc. For the sake of simplicity of representation, Figure 9 only a thick line is used to represent it in the figure, but it does not mean that there is only one bus or one type of bus.

[0166] Among them, the memory 604 can include volatile memory, such as random-access memory (RAM); the memory can also include non-volatile memory, such as flash memory, hard disk drive (HDD) or solid-state drive (SSD); the memory 604 can also include a combination of the above types of memories.

[0167] Among them, the processor 601 can be a central processing unit (CPU), a network processor (NP), or a combination of a CPU and an NP.

[0168] Among them, the processor 601 can further include a hardware chip. The above hardware chip can be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The above PLD can be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0169] Optionally, the memory 604 is further configured to store program instructions. The processor 601 may invoke the program instructions to implement the component version management method as shown in any embodiment of the present application.

[0170] An embodiment of the present invention further provides a non-transitory computer storage medium storing computer-executable instructions that can execute the component version management method in any of the above method embodiments. The storage medium may be a magnetic disk, an optical disk, a read-only memory (ROM), a random access memory (RAM), a flash memory, a hard disk drive (HDD), or a solid-state drive (SSD), etc.; the storage medium may also include a combination of the above types of memories.

[0171] Although the embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations fall within the scope defined by the appended claims.

Claims

1. A component version management method, characterized in that An electronic device applied to a component version management system, the component version management system including a component management platform and the electronic device, the component management platform being used to uniformly manage the configuration information of each component, the electronic device being connected to the component management platform, the method including: Obtain the identifier of the target application and the corresponding branch name; Obtain the target version configuration information of the corresponding target component based on the identifier and the branch name; Update the local version configuration information of the target component based on the target version configuration information, the local version configuration information being applied to the target application in the form of variables; Store the local version configuration information in a code repository hidden file, the code repository hidden file being used to hide the content in the code repository hidden file when the code is submitted to the code repository.

2. The method according to claim 1, characterized in that The obtaining the target version configuration information of the corresponding target component based on the identifier and the branch name includes: Obtain the development attribute of the target component; Pull the component version information from the corresponding branch of the component management platform based on the development attribute; Parse the component version information to determine the target version configuration information.

3. The method according to claim 2, wherein The pulling the component version information from the corresponding branch of the component management platform based on the development attribute includes: When the development attribute is a release attribute, pull the component version information from the main branch of the component management platform; When the development attribute is a test attribute, pull the component version information from the feature branch of the component management platform.

4. The method according to claim 1, wherein The updating the local version configuration information of the target component based on the target version configuration information includes: Generate a component configuration based on the target version configuration information to update the local version configuration information of the target component; Based on the development attribute of the target component, place the generated component configuration in the corresponding target development directory, the target development directory including a reference configuration, the reference configuration being used to check the reference to the local version configuration information.

5. The method according to claim 4, wherein The storing the local version configuration information in the code repository hidden file includes: Add the target development directory to the code repository hidden file.

6. The method according to any one of claims 1-5, characterized in that, The target version configuration information includes a target version number, the target version number including the name of the target component, the timestamp for building the target component, the build number of the target component, and a code identifier, the code identifier being used to represent the code corresponding to the target component.

7. A component version management device, characterized in that, including: A first obtaining module, used to obtain the identifier of the target application and the corresponding branch name; A second obtaining module, used to obtain the target version configuration information of the corresponding target component based on the identifier and the branch name; An updating module, used to update the local version configuration information of the target component based on the target version configuration information, the local version configuration information being applied to the target application in the form of variables; A storing module, used to store the local version configuration information in a code repository hidden file, the code repository hidden file being used to hide the content in the code repository hidden file when the code is submitted.

8. An electronic device, characterized in that, including: A memory and a processor, which are communicatively connected to each other. Computer instructions are stored in the memory, and the processor executes the computer instructions to execute the component version management method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing a computer to execute the component version management method according to any one of claims 1-6.

10. A component version management system, characterized in that, Comprising: A component construction platform for constructing components and generating configuration information of the constructed components, and uploading the configuration information to a component management platform; A component management platform for managing the configuration information of components, where the configuration information includes a target application, a branch name, the component, and the mapping relationship of the configuration information; The electronic device according to claim 8, which is connected to the component management platform.

Images