Monomer warehouse assembling method and device and electronic equipment

Abstract

The invention provides a single warehouse assembly method and device and electronic equipment, and the method comprises the steps: obtaining target metadata information, the target metadata information comprises metadata information of a plurality of function modules, and a source code file in each function module of the plurality of function modules is managed by an independent version warehouse; installing or updating the plurality of function modules according to the target metadata information; the function modules are assembled according to a preset file assembly protocol rule, a single warehouse is obtained, and the file assembly protocol rule represents the mapping relation between the files in the function modules and the files in the single warehouse. By using the file assembly protocol rule and the function modular management mode, the size of the Git metadata in the monomer warehouse monorepoo is effectively reduced, the response speed of the Git operation is improved, and the performance problem that the execution efficiency of the version control command is reduced due to continuous expansion of the metadata of the Git warehouse is improved.

Description

Technical Field

[0001] The present application relates to the technical field of software development, and in particular to a single warehouse assembly method, device and electronic equipment. Background Art

[0002] Git is a distributed version control system designed to handle all projects, from small to large, quickly and efficiently.

[0003] At present, in the process of multi-team collaboration, a single Git code repository based on a single repository monorepo will gradually expand as the number of application files and the number of lines of code increase, followed by the growth of the Git repository size and the corresponding expansion of metadata. When the Git metadata reaches a certain level, software developers will encounter a gradual decrease in the efficiency of version control command execution in local development. For example, the time required to execute git pull to pull code or git fetch to synchronize remote branch content is extended, and the single execution of git fetch has exceeded 5 seconds, which affects R&D efficiency. Therefore, as the metadata of the Git repository continues to expand, the efficiency of version control command execution will decrease, and may eventually make the entire repository unavailable. Summary of the invention

[0004] The purpose of the embodiments of the present application is to provide a single warehouse assembly method, device and electronic device for improving the problem of reduced execution efficiency of version control commands.

[0005] An embodiment of the present application provides a method for assembling a monorepo, including: obtaining target metadata information, where the target metadata information includes: metadata information of multiple functional modules, and the source code files in each of the multiple functional modules are managed by a separate version repository; installing or updating the multiple functional modules according to the target metadata information; assembling the multiple functional modules according to a preset file assembly protocol rule to obtain a monorepo, where the file assembly protocol rule represents the mapping relationship between the files in the multiple functional modules and the files in the monorepo. In the implementation process of the above solution, the multiple functional modules are mapped to the monorepo through the preset file assembly protocol rule. Each functional module has an independent version repository and can perform independent version control operations. This method avoids repeated operations in a large repository, reduces redundant metadata, and improves the operating efficiency of the version repository. This method isolates the metadata of each functional module in its respective repository, making the metadata scale of each repository smaller, thereby making the management and maintenance of the repository more efficient. Moreover, separating the functional modules into different repositories reduces the historical record burden of each repository, making maintenance and update easier. Therefore, the above solution uses the file assembly protocol rule and the functional modular management method to effectively reduce the size of Git metadata in the monorepo, improve the response speed of Git operations, and solve the performance problem that the continuous expansion of Git repository metadata leads to a decrease in the execution efficiency of version control commands.

[0006] Optionally, in an embodiment of the present application, obtaining the target metadata information includes: pulling the target metadata information from a configuration platform, where the target metadata information is synchronized to the configuration platform after generating the target metadata information according to the multiple functional modules. In the implementation process of the above solution, centralized management and synchronization of metadata through the configuration platform ensure that the functional module metadata obtained by all developers and environments is consistent and up-to-date, improves the metadata inconsistency problem caused by local caching or manual operations, and improves the accuracy of the dependency management of the entire project, reducing the possibility of version conflicts.

[0007] Optionally, in the embodiments of the present application, multiple functional modules are installed or updated according to the target metadata information, including: for each of the multiple functional modules, determining whether the functional module is installed for the first time; if so, installing the functional module, otherwise, updating the functional module when the version number of the functional module is different from the version number in the metadata information. In the implementation process of the above solution, by clearly distinguishing the first installation and subsequent updates and only performing update operations when necessary, unnecessary repeated installations or updates are avoided, the accuracy of dependency management is improved, redundant operations are reduced, and the efficiency of the installation and update processes is significantly enhanced. Further, updates are only performed when the version numbers are inconsistent, reducing unnecessary file downloads and compilation time in each build process, significantly shortening the build time, and reducing the consumption of CPU, memory, and network bandwidth.

[0008] Optionally, in the embodiments of the present application, installing the functional module includes: downloading the installation package of the functional module from a package management server, where the installation package of the functional module is published to the package management server through a package management tool; and installing using the installation package of the functional module. In the implementation process of the above solution, by publishing and downloading the installation package through a centralized package management server, it is ensured that the versions of the functional modules installed in all environments are consistent and verified, reducing installation failures or inconsistencies caused by local environment differences or manual operations, and improving the reliability and consistency of dependency installation.

[0009] Optionally, in the embodiments of the present application, installing the functional module includes: downloading the source code file of the functional module from a version control server, where the source code file of the functional module is submitted to the version control server through a version control tool; compiling the source code file into an installation package of the functional module; and installing using the installation package of the functional module. In the implementation process of the above solution, by managing and downloading the source code file through a version control server, it is ensured that the source code versions used in all environments are consistent, and each change has a detailed record, improving the transparency and traceability of source code management, facilitating tracing the root cause of problems, and enhancing the stability and reliability of the project.

[0010] Optionally, in the embodiments of the present application, the file assembly protocol rules include: selecting one functional module from multiple functional modules as the base module of the monorepo, and the dependent modules other than the base module; assembling the multiple functional modules according to the preset file assembly protocol rules, including: copying all the files in the source file path of the dependent module to the target file path of the base module to obtain the monorepo.

[0011] In the implementation process of the above solution, by clearly specifying the base module and other dependent modules, the overall structure of the project becomes clearer, the dependency relationship is obvious at a glance, the dependency management and project structure are simplified, the coupling degree between modules is reduced, and the maintainability and scalability of the code are improved. Further, all files in the source file path of the dependent module are copied to the target file path of the base module, ensuring that all modules are built and run in the same environment, improving the build efficiency, ensuring the consistency of the dependency relationships of all modules, and avoiding build failures or inconsistencies caused by environmental differences.

[0012] The embodiment of the present application also provides a monorepo assembly device, including: a target metadata acquisition unit, configured to acquire target metadata information, where the target metadata information includes: metadata information of multiple functional modules, and the source code files in each of the multiple functional modules are managed by a separate version repository; a function installation and update unit, configured to install or update the multiple functional modules according to the target metadata information; and a functional module assembly unit, configured to assemble the multiple functional modules according to a preset file assembly protocol rule to obtain a monorepo, and the file assembly protocol rule represents the mapping relationship between the files in the multiple functional modules and the files in the monorepo.

[0013] Optionally, in the embodiment of the present application, the target metadata acquisition unit includes: a metadata pulling subunit, configured to pull the target metadata information from a configuration platform, and the target metadata information is synchronized to the configuration platform after generating the target metadata information according to the multiple functional modules.

[0014] Optionally, in the embodiment of the present application, the function installation and update unit includes: a module installation judgment subunit, configured to judge whether each of the multiple functional modules is installed for the first time; and a module installation and update subunit, configured to install the functional module if the functional module is installed for the first time, and update the functional module if the functional module has been installed and the version number of the functional module is different from the version number in the metadata information.

[0015] Optionally, in the embodiment of the present application, the module installation and update subunit includes: a package download and installation module, configured to download the installation package of the functional module from a package management server, and the installation package of the functional module is published to the package management server through a package management tool; and a package function installation module, configured to install using the installation package of the functional module.

[0016] Optionally, in the embodiments of the present application, the module installation and update subunit includes: a code file download module, configured to download the source code file of the functional module from a version control server, where the source code file of the functional module is submitted to the version control server through a version control tool; a code file compilation module, configured to compile the source code file into an installation package of the functional module; and a functional module installation module, configured to perform installation using the installation package of the functional module.

[0017] Optionally, in the embodiments of the present application, the file assembly protocol rule includes: selecting one functional module from multiple functional modules as the base module of the monorepo, and dependent modules other than the base module; the functional module assembly unit includes: a file copy subunit, configured to copy all files in the source file path of the dependent module to the target file path of the base module to obtain a monorepo.

[0018] The embodiments of the present application further provide an electronic device, including: a processor and a memory, where the memory stores machine-readable instructions executable by the processor, and the machine-readable instructions, when run by the processor, execute the method described above.

[0019] The embodiments of the present application further provide a computer-readable storage medium, on which a computer program is stored, and the computer program, when run by a processor, executes the method described above.

[0020] The embodiments of the present application further provide a computer program product, including: a computer program or computer instructions, and the computer program or computer instructions, when run by a processor, execute the method described above. Description of the Drawings

[0021] To more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings required to be used in the embodiments of the present application. It should be understood that the following drawings only show some embodiments of the present application, and thus should not be regarded as limiting the scope. For those of ordinary skill in the art, other related drawings can be obtained based on these drawings without creative efforts.

[0022] Figure 1 A schematic flowchart of the monorepo assembly method provided by the embodiments of the present application;

[0023] Figure 2 A schematic diagram of the process of prior splitting and dynamic assembly provided by the embodiments of the present application;

[0024] Figure 3 A schematic diagram of the process of assembling multiple functional modules provided by the embodiments of the present application;

[0025] Figure 4 Schematic structural diagram of the monomer warehouse assembly device provided by the embodiment of the present application shown;

[0026] Figure 5 Schematic structural diagram of the electronic device provided by the embodiment of the present application shown. Detailed implementation manners

[0027] To make the objectives, technical solutions, and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. It should be understood that the accompanying drawings in the embodiments of the present application are only for the purposes of illustration and description, and are not used to limit the protection scope of the embodiments of the present application. In addition, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in the embodiments of the present application illustrate the operations implemented according to some embodiments of the embodiments of the present application. It should be understood that the operations in the flowchart may not be implemented in sequence, and steps without logical context relationships may be reversed or implemented simultaneously. In addition, those skilled in the art may add one or more other operations to the flowchart or remove one or more operations from the flowchart under the guidance of the content of the embodiments of the present application.

[0028] In addition, the described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments. The components of the embodiments of the present application usually described and illustrated in the accompanying drawings herein may be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present application provided in the accompanying drawings is not intended to limit the scope of the claimed embodiments of the present application, but merely represents the selected embodiments of the present application.

[0029] It can be understood that "first" and "second" in the embodiments of the present application are used to distinguish similar objects. Those skilled in the art can understand that words such as "first" and "second" do not limit the quantity and execution order, and words such as "first" and "second" do not necessarily limit to be different. In the description of the embodiments of the present application, the term "and / or" is only an association relationship describing associated objects, indicating that three relationships may exist. For example, A and / or B may represent: A exists alone, A and B exist simultaneously, and B exists alone. In addition, the character " / " in this article generally represents an "or" relationship between the associated objects before and after. The term "plural" refers to two or more (including two). Similarly, "multiple groups" refers to two or more groups (including two groups).

[0030] It should be noted that the method for assembling a single repository provided in the embodiments of the present application can be executed by an electronic device, where the electronic device refers to a device terminal or a server with the function of executing a computer program. Examples of the device terminal include: smart phones, personal computers, tablet computers, personal digital assistants, or mobile Internet devices, etc. A server refers to a device that provides computing services through a network. Examples of the server include: x86 servers and non-x86 servers. Non-x86 servers include: mainframes, minicomputers, and UNIX servers.

[0031] In the related art, most R & D team members usually develop together in a single repository (such as a single Git code repository) in a multi-team collaboration manner. With the expansion of the scale of R & D team members and the continuous increase of project applications, the number of configuration files and code files in the Git code repository will increase significantly, resulting in a synchronous significant expansion of the disk scale occupied by the Git code repository and its corresponding metadata volume. When the Git metadata reaches a certain level, the execution efficiency of version control commands encountered by software developers in local development will gradually decrease. For example, when the size of Git metadata exceeds 1G, the average single-time duration of locally executing git fetch will exceed 5 seconds, and the average duration of locally executing the git pull command will reach more than 2.5 seconds, which affects the R & D efficiency and project development progress. Therefore, as the Git repository metadata continues to expand, it will lead to a decrease in the execution efficiency of version control commands. As time goes by, the Git metadata will continue to expand, and the execution performance problem of Git commands will become more obvious, and may even ultimately lead to the unavailability of the entire repository.

[0032] Regarding the above problems, please refer to Figure 1 the schematic flowchart of the method for assembling a single repository provided in the embodiments of the present application shown in; the main idea of this method for assembling a single repository is to split the original single repository into multiple functional modules in advance, and each functional module has an independent version repository, and map and assemble the multiple functional modules into the required single repository through preset file assembly protocol rules, so that each functional module can perform independent version control operations. This method avoids repeated operations in a large repository, reduces redundant metadata, and improves the running efficiency of the version repository. The implementation manner of the above method for assembling a single repository may include:

[0033] Step S110: Obtain target metadata information, where the target metadata information includes: metadata information of multiple functional modules, and the source code files in each of the multiple functional modules are managed by a separate version repository.

[0034] The metadata information of the above-mentioned functional module refers to the metadata information stored in the version repository corresponding to the functional module (such as a Git repository). The format of the metadata information may be in JSON format. The metadata information may include: functional module name, current version number of the functional module, functional module description, whitelist, update information list, version update mark, historical version information of code submission (such as submission ID, etc.), author information and / or branch information, etc.

[0035] It is understandable that, since each of the multiple functional modules is managed by a separate version repository, each functional module has its own metadata information, and each functional module can be developed independently. After the functional module is developed, it can be deployed independently, for example, by packaging it into an NPM installation package through a package management tool (such as a PNPM tool), and publishing the NPM installation package to a package management server.

[0036] Step S120: installing or updating multiple function modules according to the target metadata information.

[0037] It can be understood that the above-mentioned target metadata information can be generated based on the functional information of the functional module and the standard definition fields. For example, assuming that there is a functional module called the basic configuration "base-config", the fields of the metadata information of this functional module may include: functional module name (name), current version number of the functional module (version), functional module description (desc), whitelist (whiteList), update information list (msgInfo), version update mark (update), etc. These fields are all standard definition fields of metadata.

[0038] Step S130: assemble multiple functional modules according to preset file assembly protocol rules to obtain a single repository, where the file assembly protocol rules represent the mapping relationship between files in the multiple functional modules and files in the single repository.

[0039] A monorepo is a virtual repository that brings together the code files of multiple functional modules and develops and manages them as a single entity.

[0040] See also Figure 2Schematic diagram of the prior splitting and dynamic assembly process provided by the embodiments of the present application; assume that the original name of the monomer warehouse is frontend-module-root-monorepo, and assume that the metadata size of this monomer warehouse is 100M. At this time, the execution efficiency of the version control command is gradually decreasing. The monomer warehouse can be split according to functional modules, and the three obtained functional modules can include: frontend-module-components-monorepo (metadata size is 40M), frontend-module-config-monorepo (metadata size is 35M), and frontend-module-biz-monorepo (metadata size is 25M). After obtaining the metadata information of the above three functional modules as the target metadata information, the three functional modules can be assembled according to the target metadata information and the preset file assembly protocol rules. For example, taking frontend-module-biz-monorepo as the base module, and taking

[0041] frontend-module-components-monorepo and

[0042] frontend-module-config-monorepo as the dependent modules for assembly, so as to obtain the assembled monomer warehouse as shown on the right side of the figure. The metadata size is reduced from the original 100M of the monomer warehouse to 25M of the base module, thereby reducing the metadata size that the warehouse needs to manage, and effectively improving the performance problem that the continuous expansion of the metadata in the Git warehouse leads to the reduction of the execution efficiency of the version control command.

[0043] In the implementation process of the above solution, multiple functional modules are mapped into the monomer warehouse through the preset file assembly protocol rules, and each functional module has an independent version warehouse and can perform independent version control operations. This method avoids repeated operations in a large warehouse, reduces redundant metadata, and improves the running efficiency of the version warehouse. This method isolates the metadata of each functional module in its respective warehouse, making the metadata scale of each warehouse smaller, thus making the management and maintenance of the warehouse more efficient. Moreover, separating the functional modules into different warehouses reduces the historical record burden of each warehouse, making maintenance and update easier. Therefore, the above solution uses the file assembly protocol rules and the functional modular management method to effectively reduce the size of Git metadata in the monomer warehouse monorepo, improve the response speed of Git operations, and improve the performance problem that the continuous expansion of the metadata in the Git warehouse leads to the reduction of the execution efficiency of the version control command.

[0044] As an alternative implementation of the above step S110, the implementation of obtaining the target metadata information may include:

[0045] Step S111: Pull the target metadata information from the configuration platform. The target metadata information is synchronized to the configuration platform after the target metadata information is generated according to multiple functional modules.

[0046] It can be understood that the trigger timing for the electronic device to pull the target metadata information from the configuration platform can be when installing the NPM package for the dependency relationship of the functional module, or before the electronic device starts the service, or after the electronic device starts the service. Since the metadata has been pre-synchronized to the configuration platform, developers newly added to the project can quickly obtain all the required dependency information without waiting for a long Git clone or download process. After pulling the target metadata information from the configuration platform, the electronic device can also download the latest source code file of the functional module from the version control server, or download the installation package of the functional module from the package management server.

[0047] The implementation of the above step S111 is as follows: for example, after the functional module is developed, it can be independently deployed, or the target metadata information can be generated according to multiple functional modules, and then the metadata information of the functional module is synchronized to the configuration platform, so that the configuration platform records the metadata information required for each code update. Each time the target metadata information is generated, it is immediately synchronized to the configuration platform, forming a complete change record, which is convenient for tracing historical versions and change reasons. The electronic device can pull the target metadata information from the configuration platform through the HyperText Transfer Protocol (HTTP) or the Hypertext Transfer Protocol Secure (HTTPS). The target metadata information here may include the latest metadata information of the functional module. Since the metadata information includes the name of the functional module and the current version number (version) of the functional module, the electronic device can pull all the files of the functional module according to these two fields of name and version. Centralized management of metadata means that developers no longer need to manually track the version changes of each functional module, and all information is uniformly maintained by the configuration platform, simplifying the pipeline configuration of Continuous Integration (CI), Continuous Delivery, and / or Continuous Deployment, supporting parallel development, and different teams can work independently on their respective modules without interfering with each other, greatly improving the R & D efficiency.

[0048] It is understandable that the above target metadata information can be in JSON format or XML format. Here, the JSON format is taken as an example for illustration. The above target metadata information can be expressed as: {"base":{

[0049] "name":"@monorepo / frontend-module-config-monorepo",

[0050] "version":"1.0.1",

[0051] "desc":"Dacang basic configuration information",

[0052] "whiteList":[],

[0053] "msgInfo":[],

[0054] "update":true},

[0055] "packages":{

[0056] "nane":"@monorepo / frontend-module-components-monorepo",

[0057] "version":"1.0.1",

[0058] "desc":"Dacang general component information",

[0059] "whiteList":[],

[0060] "msgInfo":[],

[0061] "update":true}

[0062] }; Among them, the above base and packages represent the short names of the function module names. If there are other function modules not shown in the above JSON data structure, they can be added and extended in the above JSON data structure. version represents the current version number of the function module, desc represents the function module description, whiteList represents the whitelist, msgInfo represents the update information list, and update represents the version update flag.

[0063] Optionally, the synchronization of metadata information through the configuration platform as described above is not limited to the current project and can be easily extended to other projects or environments by simply adjusting the metadata on the configuration platform, which promotes the application of the microservices architecture or modular design concept and enhances the adaptability and scalability of the system.

[0064] As an alternative implementation of the above step S120, the implementation of installing or updating multiple functional modules based on the target metadata information may include:

[0065] Step S121: For each functional module among the multiple functional modules, determine whether this functional module is installed for the first time.

[0066] Optionally, after the electronic device pulls the metadata information of this functional module from the configuration platform, it can also write the metadata information of this functional module into the package.json file, so that when the electronic device determines whether this functional module is installed for the first time, it can directly read the metadata information of this functional module from the package.json file.

[0067] The implementation of the above step S121 is, for example: for each functional module among the multiple functional modules, after pulling the metadata information of this functional module from the configuration platform, the version number (the value of the version field) of this functional module in the metadata information can be compared with the version number (the value of the version field) of the same functional module in the metadata information of the functional module in the local node_modules directory to obtain a comparison result, and based on the comparison result, determine whether this functional module is installed for the first time.

[0068] Step S122: If this functional module is installed for the first time, install this functional module.

[0069] The implementation of the above step S122 is, for example: if this functional module is a base module and the metadata information of this base module is not stored locally, it means that this functional module is installed for the first time, and this functional module can be directly installed. If this functional module is a dependent module and the metadata information of this dependent module is not stored locally, it means that this functional module is installed for the first time, and the dependencies of this functional module can be directly installed through the pnpminstall command. For the specific installation process, refer to the following implementation content.

[0070] Step S123: If this functional module is not installed for the first time, update this functional module when the version number of this functional module is different from the version number in the metadata information.

[0071] For example, the implementation of the above step S123 is as follows: If the function module is a dependent module and the metadata information of the dependent module has been stored locally, it means that the function module is not installed for the first time. The version number (the value of the version field) of the function module in the metadata information can be compared with the version number (the value of the version field) of the same function module in the metadata information of the function module in the local node_modules directory to obtain a comparison result. If the comparison result is that the version number of the function module in the metadata information is the same as the version number of the same function module in the metadata information in the local node_modules directory, the version update flag is set to False, and there is no need to update the function module at this time. On the contrary, if the comparison result is that the version number of the function module in the metadata information is different from the version number of the same function module in the metadata information in the local node_modules directory, the version update flag is set to True. Then, when it is detected that the version update flag is True, the spawn API of node can be immediately called to update the function module.

[0072] In the implementation process of the above solution, through a strict version comparison mechanism, it is ensured that the function module after each installation or update is the latest and stable version, reducing function anomalies or compatibility problems caused by version inconsistencies, and enhancing the overall stability and reliability of the system. Further, the automated version checking and updating mechanism makes the CI / CD pipeline more concise and efficient, eliminating the need to configure complex scripts to handle different situations, simplifying the continuous integration and deployment process, reducing the possibility of human errors, and increasing the degree of automation.

[0073] As an alternative implementation of the above step S122, the implementation of installing the function module may include:

[0074] Step S122a: Download the installation package of the function module from the package management server. The installation package of the function module is published to the package management server through a package management tool.

[0075] The package management server refers to a server that centrally manages the installation packages of function modules. The installation packages here can include Node Package Manager (NPM) packages. The installation packages on the package management server can be packaged into NPM installation packages by developers through a package management tool and published to the package management server (also known as the NPM private server) through the pnpm publish command.

[0076] Step S122b: Install using the installation package of the function module.

[0077] The implementation manners of the above steps S122a to S122b are as follows: For example, after a developer executes the pnpm install command, the installation package of the functional module is downloaded from the package management server, and then, the installation package of the functional module is used for installation through a shell program. If the functional module is a dependent module, all files of the dependent module are installed in the node_modules directory of the base module. Since the pre-packaged installation package already contains the compiled binary files and other necessary resources, there is no need to repeat compilation during each build, thus significantly shortening the build and deployment time, especially in large-scale projects, and reducing the consumption of CPU, memory, and network bandwidth. Further, the developer no longer needs to manually process the source code files of the functional module, and only needs to directly download and install the standardized installation package through the package management tool, simplifying the CI / CD pipeline configuration, supporting parallel development, and different teams can work independently on their respective modules without interfering with each other, greatly improving the R & D efficiency.

[0078] As an alternative implementation manner of the above step S122, the implementation manner of installing the functional module may include:

[0079] Step S122c: Download the source code file of the functional module from the version control server, and the source code file of the functional module is submitted to the version control server through a version control tool.

[0080] The implementation manner of the above step S122c is as follows: For example, the electronic device uses the git clone command to clone and download the source code file of the functional module from the version control server (it can also switch to the target branch or tag), and then, the git pull command can be used to synchronize and update to the smallest source code file from the version control server to avoid functional anomalies caused by inconsistent functional module codes.

[0081] Step S122d: Compile the source code file into the installation package of the functional module.

[0082] The implementation manner of the above step S122d is as follows: For example, use pnpm install to install all necessary development dependencies of the functional module. If the functional module is written in TypeScript, the pnpm run build command can be used to compile the source code file into a JavaScript file first, and then, the pnpm pack command is used to package the JavaScript file into the installation package of the functional module. This step will generate a.tgz file, such as auth-module-1.0.0.tgz, which is the installation package of the functional module.

[0083] Step S122e: Use the installation package of the functional module for installation.

[0084] For example, the implementation of the above step S122e is as follows: Install the.tgz file of the function module into the specified directory of the base module (for example, successfully installed into the node_modules directory), and then it can be used in the main project of the base module. It can be understood that although an additional compilation step is required in the above process, in the actual practice process, the compilation process can be efficiently completed through an automated tool chain (such as CI / CD), reducing the time cost of manual intervention, significantly shortening the conversion time from source code to executable file, especially in large-scale projects, and reducing the consumption of CPU, memory, and network bandwidth.

[0085] Optionally, the electronic device can also detect potential security vulnerabilities and code quality issues through static analysis tools during the compilation process, ensuring that the generated installation package is more secure and reliable, reducing potential risks caused by using unvalidated code or dependencies, enhancing the overall stability and security of the system, and reducing the occurrence rate of security vulnerabilities. Further, by managing the source code through a centralized version control server, redundant information storage is avoided, storage costs and resource consumption are reduced, and the overall performance of the system is optimized. Especially in a large-scale monorepo environment, the performance bottleneck caused by Git repository bloat is effectively alleviated.

[0086] As an alternative implementation of the above step S130, the above file assembly protocol rules may include: selecting one function module from multiple function modules as the base module of the monorepo, and dependent modules other than the base module; the implementation of assembling multiple function modules according to the preset file assembly protocol rules may include:

[0087] Step S131: Copy all files in the source file path of the dependent module to the target file path of the base module to obtain a monorepo.

[0088] Please refer to Figure 3 the process schematic diagram of assembling multiple function modules provided by the embodiments of the present application shown; in the actual practice process, through the executable program of the file assembly processor, all files in the source file path of the dependent module can be copied to the target file path of the base module according to the file assembly protocol rules. Since the file assembly protocol rules represent the mapping relationship between the files in multiple function modules and the files in the monorepo, the executable program of the file assembly processor can know to synchronously copy all files in the source file path of the dependent module under node_modules to the target file path of the base module (such as base X / specific directory) according to this mapping relationship.

[0089] For example, the implementation of the above step S131 is as follows: Through the application program interface (API) of the file system (FS) of the node program, all files in the source file path of the dependent modules under node_modules are synchronously copied to the target file path of the base module (such as base X / specific directory), and finally combined into a complete monorepo. Among them, the dependent modules under the above node_modules may include: functional module 1, functional module 2, functional module 3, etc. Therefore, all files in the source file path of the dependent modules under node_modules may include: functional module 1 files, functional module 2 files, functional module 3 files, etc. Through the centralized file assembly protocol, it is ensured that the monorepo after each assembly is in a consistent and up-to-date version, reducing function anomalies or compatibility issues caused by version inconsistencies, and enhancing the overall stability and reliability of the system. Further, through centralized management and assembly, redundant storage of duplicate files is avoided, storage costs and resource consumption are reduced, and the overall performance of the system is optimized. Especially in a large-scale monorepo environment, the performance bottleneck caused by Git repository bloat is effectively alleviated.

[0090] It can be understood that the above file assembly protocol rules define the mapping relationship between the files in the functional modules and the files in the monorepo. The definition of the JSON data structure of the file assembly protocol rules is very important, and the data structure of this file assembly protocol rules can determine whether the files can be synchronized from the functional module directory to the new monorepo large warehouse directory.

[0091] Optionally, the above file assembly protocol rules can be represented in JSON format as:

[0092] {"version":"1.0.13",

[0093] "files":[{

[0094] "type":"base-config",

[0095]

[0096] }。Among them, for the data structure in the above file assembly protocol rules, type represents the type of the functional module. For example, base-config represents the type of basic configuration. Under this type, there are two file lists, namely the file list of type changeset and the file list of type husky. For different file types, source represents all the files in the source file path of the dependent module, while target represents the files in the target file path of the base module (i.e., the assembled monorepo).

[0097] Please refer to Figure 4 the structural schematic diagram of the monorepo assembly device provided by the embodiment of the present application shown in; The embodiment of the present application provides a monorepo assembly device 200, including:

[0098] A target metadata acquisition unit 210, configured to acquire target metadata information, where the target metadata information includes: metadata information of multiple functional modules, and the source code files in each functional module among the multiple functional modules are managed by a separate version repository.

[0099] A function installation and update unit 220, configured to install or update multiple functional modules according to the target metadata information.

[0100] A functional module assembly unit 230, configured to assemble multiple functional modules according to a preset file assembly protocol rule to obtain a monorepo, where the file assembly protocol rule represents the mapping relationship between the files in the multiple functional modules and the files in the monorepo.

[0101] As an alternative implementation manner of the above device, the target metadata acquisition unit includes:

[0102] A metadata pulling subunit, configured to pull the target metadata information from the configuration platform, and the target metadata information is synchronized to the configuration platform after generating the target metadata information according to multiple functional modules.

[0103] As an alternative implementation manner of the above device, the function installation and update unit includes:

[0104] A module installation judgment subunit, configured to judge whether each functional module among the multiple functional modules is installed for the first time.

[0105] A module installation and update subunit, configured to install the functional module if the functional module is installed for the first time, and update the functional module if the functional module is already installed and the version number of the functional module is different from the version number in the metadata information.

[0106] As an alternative implementation manner of the above device, the module installation and update subunit includes:

[0107] A package download and installation module, which is used to download the installation package of the function module from a package management server. The installation package of the function module is published to the package management server through a package management tool.

[0108] A package function installation module, which is used to install using the installation package of the function module.

[0109] As an optional implementation manner of the above device, the module installation and update subunit includes:

[0110] A code file download module, which is used to download the source code file of the function module from a version control server. The source code file of the function module is submitted to the version control server through a version control tool.

[0111] A code file compilation module, which is used to compile the source code file into the installation package of the function module.

[0112] A function module installation module, which is used to install using the installation package of the function module.

[0113] As an optional implementation manner of the above device, the file assembly protocol rule includes: selecting one function module from multiple function modules as the base module of a monomer repository, and dependent modules other than the base module; the function module assembly unit includes:

[0114] A file copy subunit, which is used to copy all files under the source file path of the dependent module to the target file path of the base module to obtain a monomer repository.

[0115] It should be understood that this device corresponds to the above-mentioned monomer repository assembly method embodiment and can execute each step involved in the above method embodiment. The specific functions of this device can be referred to the description above, and the detailed description is appropriately omitted here. This device includes at least one software function module that can be stored in a memory in the form of software or firmware or solidified in the operating system (OS) of the device.

[0116] Please refer to Figure 5 The structural schematic diagram of the electronic device provided by the embodiment of the present application shown in. An electronic device 300 provided by an embodiment of the present application includes: a processor 310 and a memory 320. The memory 320 stores machine-readable instructions executable by the processor 310. When the machine-readable instructions are executed by the processor 310, the above method is executed.

[0117] An embodiment of the present application also provides a computer-readable storage medium 330. A computer program is stored on the computer-readable storage medium 330, and when the computer program is run by a processor 310, the above method is executed. Among them, the computer-readable storage medium 330 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (abbreviated as SRAM), electrically erasable programmable read-only memory (abbreviated as EEPROM), erasable programmable read-only memory (abbreviated as EPROM), programmable read-only memory (abbreviated as PROM), read-only memory (abbreviated as ROM), magnetic memory, flash memory, magnetic disk or optical disc.

[0118] An embodiment of the present application also provides a computer program product, including: a computer program or computer instructions, and when the computer program or computer instructions are run by a processor, the method described above is executed.

[0119] It should be noted that the embodiments in this specification are all described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The same or similar parts among the embodiments can be referred to each other. For device embodiments, since they are basically similar to method embodiments, the description is relatively simple, and the relevant parts can refer to the partial description of the method embodiments.

[0120] In several embodiments provided by the embodiments of the present application, it should be understood that the disclosed devices and methods can also be implemented in other ways. The device embodiments described above are only illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the possible architectures, functions, and operations of devices, methods, and computer program products according to multiple embodiments of the present application. In this regard, each block in the flowchart or block diagram may represent a module, a program segment, or a part of code. A module, a program segment, or a part of code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may also occur in a different order from that marked in the accompanying drawings. For example, two consecutive blocks can actually be executed substantially in parallel, and they can sometimes be executed in the reverse order, which mainly depends on the functions involved.

[0121] In addition, the functional modules in each embodiment of the present application can be integrated together to form an independent part, or each module can exist alone, or two or more modules can be integrated to form an independent part. Moreover, in the description of this specification, the descriptions with reference to the terms "one embodiment", "some embodiments", "example", "specific example", "some examples", etc. mean that the specific features, structures, materials or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the embodiments of the present application. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner. In addition, without contradiction, those skilled in the art can combine and combine the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0122] The above description is only an optional implementation manner of the embodiments of the present application, but the protection scope of the embodiments of the present application is not limited thereto. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed in the embodiments of the present application, and all should be covered by the protection scope of the embodiments of the present application.

Claims

1. A method for assembling a single warehouse, characterized in that: include: Acquire target metadata information, the target metadata information including: metadata information of multiple function modules, source code files in each of the multiple function modules are managed by a separate version repository; Install or update the plurality of functional modules according to the target metadata information; The multiple functional modules are assembled according to preset file assembly protocol rules to obtain a single repository, wherein the file assembly protocol rules represent a mapping relationship between files in the multiple functional modules and files in the single repository.

2. The method according to claim 1, characterized in that The obtaining of target metadata information includes: The target metadata information is pulled from the configuration platform, and the target metadata information is generated according to the multiple functional modules and then synchronized to the configuration platform.

3. The method according to claim 1, characterized in that The step of installing or updating the plurality of functional modules according to the target metadata information comprises: For each of the multiple function modules, determining whether the function module is installed for the first time; If so, the function module is installed; otherwise, if the version number of the function module is different from the version number in the metadata information, the function module is updated.

4. The method according to claim 3, characterized in that The step of installing the functional module comprises: Downloading the installation package of the function module from the package management server, where the installation package of the function module is published to the package management server through a package management tool; Use the installation package of this function module to install it.

5. The method according to claim 3, characterized in that: The step of installing the functional module comprises: Downloading the source code file of the function module from the version control server, where the source code file of the function module is submitted to the version control server through a version control tool; Compile the source code file into an installation package of the functional module; Use the installation package of this function module to install it.

6. The method according to claim 1, characterized in that The file assembly protocol rule includes: selecting a function module from the multiple function modules as the base module of the single warehouse, and the dependent modules other than the base module; assembling the multiple function modules according to the preset file assembly protocol rule includes: Copy all files under the source file path of the dependent module to the target file path of the base module to obtain the single repository.

7. A single warehouse assembly device, characterized in that: include: A target metadata acquisition unit, used to acquire target metadata information, wherein the target metadata information includes: metadata information of multiple functional modules, wherein source code files in each of the multiple functional modules are managed by a separate version repository; A function installation and update unit, configured to install or update the plurality of function modules according to the target metadata information; The function module assembly unit is used to assemble the multiple function modules according to preset file assembly protocol rules to obtain a single repository, wherein the file assembly protocol rules represent the mapping relationship between the files in the multiple function modules and the files in the single repository.

8. An electronic device, characterized in that: include: A processor and a memory, wherein the memory stores machine-readable instructions executable by the processor, and the machine-readable instructions are executed by the processor to perform any method according to claims 1 to 6.

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

10. A computer program product, characterized in that include: A computer program or a computer instruction, wherein when the computer program or the computer instruction is executed by a processor, the method according to any one of claims 1 to 6 is executed.

Images