A method for automated build and release management of front-end multi-package projects

Abstract

The present invention discloses a method for automated construction and release management of front-end multi-package engineering. Based on the monorepo architecture, the independence and flexibility of the module version are achieved by maintaining the submodules in independent git sub-repositories, and the problems of rigid dependency and complex version update under the traditional monorepo architecture are solved. The present invention adopts a parameterized construction method, and the construction process and configuration are completely decoupled. The module construction and release can be completed by parameter input, which greatly reduces manual operation and error risks. Combined with the silent automated deployment link, the whole process is automated from code construction to image generation and release, which significantly improves the deployment efficiency. In addition, through the full-process traceability mechanism and web visualization interface, it supports comprehensive tracing of version records, operation logs and dependencies, realizes rapid problem location and one-key rollback, and has high flexibility and reliability through the coordinated optimization of module management, construction and deployment processes.

Description

Technical Field

[0001] The present invention relates to the technical field of software engineering, and in particular to a method for automated construction and release management of front-end multi-package engineering. Background Art

[0002] As the complexity of front-end development continues to increase, applications are often split into multiple modules or components for easier development, maintenance, and iteration. The monorepo architecture has gradually become a mainstream project organization method. The characteristic of monorepo is that multiple submodules are managed through a unified code base, making code reuse and dependency management more efficient. This architecture is widely used in enterprise-level front-end projects, microservice systems, and open source modular projects. However, in actual development and operation and maintenance, there are still many problems in the construction and release management of the monorepo architecture.

[0003] In the prior art, in order to manage multiple submodules in a monorepo architecture, a centralized full-volume release mode or a manual combined release mode is usually adopted:

[0004] 1. Full release mode: In this mode, all submodules are upgraded and released at once. Although this method simplifies the process, it can easily lead to redundant growth of the code base, rigid dependencies between modules, and cannot meet the needs of flexible updates of single modules. In addition, since all modules are upgraded uniformly, developers often need to handle a large number of unnecessary version updates, resulting in serious waste of storage space for hosting services.

[0005] 2. Manual combination release mode: Developers manually adjust the dependencies of modules according to their needs and release them one by one. This method requires extremely high proficiency of operators, and the operation is complex and prone to errors. Once an error occurs, the tracing and rollback process is time-consuming and cumbersome, which seriously affects the development and launch progress.

[0006] To avoid the above problems, some tools try to optimize the management of monorepo through automated build processes, such as introducing parameterized configuration and centralized operation interface. However, these methods still face the following major problems in practice, such as developers need to frequently switch code branches and manually adjust build dependency versions, resulting in long build times and prone to errors; existing tools are not flexible enough in managing dependencies of single modules, especially unable to achieve fine-grained adjustments to dependencies between modules, resulting in a lack of targeting in builds and releases; and existing tools have limited version management capabilities, unable to intuitively display build history, and complex problem tracing and version rollback operations, which bring high costs to project maintenance.

[0007] Therefore, how to optimize the multi-module project building and release process in the monorepo architecture to achieve process automation while taking into account the flexibility and traceability of version management has become a technical problem to be solved by the present invention. Summary of the invention

[0008] The technical problem solved by the present invention is to provide a method for automated construction and release management of front-end multi-package projects in response to the defects existing in the above-mentioned prior art, so as to solve the problems of cumbersome construction and release process, insufficient flexibility and lack of traceable management proposed in the above-mentioned background technology.

[0009] In order to solve the above technical problems, the technical solution adopted by the present invention is as follows:

[0010] A method for automated construction and release management of front-end multi-package projects, based on the monorepo architecture and combined with the git submodule management mechanism, comprises the following steps:

[0011] Step 1: Independent management of module versions:

[0012] Maintain each submodule in the monorepo architecture as a separate git repository while retaining its directory structure in the monorepo project;

[0013] Provide a web visualization interface for managing submodule version information, including a module list, a current working version list, and a historical version list, where:

[0014] The module list is grouped according to module purpose, showing module name and build status;

[0015] The current working version list shows the version number, dependency information, build time and notes of each submodule;

[0016] The historical version list is used to record and trace back all historical build versions and their dependencies;

[0017] Step 2: Parameterized construction and automated deployment:

[0018] Receive module building and publishing parameter information through the user interface, including target branch, module dependency, release version number, and deployment environment information;

[0019] Automatically performs the following actions based on the received parameters:

[0020] Switch to the target branch and resolve module dependencies;

[0021] Generate npm package and upload it to the remote repository;

[0022] Update the package.json file of the target project and submit it to the git remote;

[0023] Step 3: Automatically deploy web services:

[0024] Automatically trigger the deployment process of the web service based on the built npm package, including dependency installation, source code building, image generation and upload operations;

[0025] Upload the generated web image to the internal image repository and deploy it to the specified web server;

[0026] Step 4: Full process traceability management:

[0027] Keep operational records for each build and release task, including module version, dependency information, operator, build time, and build log;

[0028] The web visualization interface supports one-click rollback or copy operation process.

[0029] As a further solution of the present invention, the web visualization interface further includes a quick operation function module, which is used to complete the test version release or the formal version release of the module with one click, wherein: the test version release generates an npm package based on the test environment parameters input by the user, and publishes it to the test warehouse; the formal version release generates an npm package based on the formal environment parameters input by the user, and deploys it to the web server of the formal environment.

[0030] As a further solution of the present invention, the independent git repository of the submodule is bound to the parent repository in the monorepo project through a git submodule, specifically including: the version changes of the submodule are entered through the web interface, and the dependency configuration file of the parent repository is automatically updated; the dependency changes of the submodule are automatically parsed and executed in the build process of the parent repository.

[0031] As a further solution of the present invention, the construction parameters of the parameterized construction and deployment include the following:

[0032] checkouts parameter: used to declare the target branch or version tag of each submodule;

[0033] deploy parameter: used to declare the name of the npm package to be released, the version number, the release type, and whether it is a patch version;

[0034] fat parameter: used to declare the web branch and target server information that need to be updated after the release is successful.

[0035] As a further solution of the present invention, the automatically deployed web service includes the following steps:

[0036] S1, pull the web service source code;

[0037] S2, automatically switch to the target branch;

[0038] S3, install npm dependencies and perform web build operations;

[0039] S4, generate a web image and upload it to the internal image repository;

[0040] S5, deploy the image to the specified web server.

[0041] As a further solution of the present invention, the deployment of the web service is completed through a silent automation link, including the following contents: all operations are automatically triggered by the backend service through the received construction parameters without manual intervention; the execution status during the construction process is fed back in real time through the web interface.

[0042] As a further solution of the present invention, the full-process traceable management further includes: providing a visual display of historical construction tasks in the web interface, including version numbers, dependency information, build logs and operators; providing a one-click rollback function to roll back the current module version to a specified historical version; providing a process replication function for quickly reusing parameter configurations of historical tasks.

[0043] As a further solution of the present invention, the method is applicable to the following scenarios: automated construction and release of multi-module front-end projects within an enterprise; dependency management and deployment of service modules in a microservice architecture; modular management and automated release in an open source community.

[0044] As a further solution of the present invention, the system comprises:

[0045] User interaction module: used to receive module information, version information, build parameters and deployment environment information input by users, and present module status, version list and historical build records through the web visualization interface;

[0046] Parameter parsing module: used to parse the build parameters input by the user interaction module, including target branch, dependency, npm package version number and server deployment information, and generate build instructions;

[0047] Build execution module: used to automatically switch the target branch according to the parsed build parameters, perform dependency parsing, npm package generation and verification, and upload the build product to the remote npm repository;

[0048] Deployment execution module: used to trigger the deployment process of the web service according to the npm package generated by the build execution module, including dependency installation, source code building, image generation and upload operations;

[0049] Version management module: used to record module version information, dependencies, build time, operation logs and build status, and supports version backtracking and process replication;

[0050] Feedback module: used to feed back the execution status of build and deployment to the user interaction module in real time.

[0051] As a further solution of the present invention, the user interaction module and the version management module are integrated through a web interface, providing a one-click operation function and supporting the release of a test version or a formal version of the module;

[0052] The deployment execution module is integrated with the image repository and web server, supporting the storage of web build results in the form of images in the internal image repository and deployment to the target server;

[0053] The system is suitable for multi-module front-end engineering automation management scenarios within the enterprise, including module construction, version updates and rapid deployment of web services.

[0054] Compared with the prior art, the present invention has the following beneficial effects:

[0055] 1. Based on the monorepo architecture, by maintaining each submodule in an independent git sub-repository, it not only maintains the unified management of multi-module projects, but also realizes the independence and flexibility of module versions, solving the problems of rigid dependencies between modules and complex version updates under the traditional monorepo architecture.

[0056] 2. Through parameterized construction, the present invention achieves a complete decoupling of the construction process and configuration. Module construction and release can be completed only through parameter input, reducing the tediousness and inflexibility brought by traditional hard coding. At the same time, the design of silent automatic deployment links further expands the application of construction results, and realizes the automation of the entire process from code construction to image generation and release without human intervention.

[0057] 3. Through the full-process operation record and backtracking mechanism, the module version, dependency, operation log and build status are fully traceable, which significantly improves the speed of problem location and the reliability of operation. Combined with the web visual interface, users can quickly perform one-click rollback or process reuse. This design is particularly suitable for the diverse needs of version management in complex projects.

[0058] Additional aspects and advantages of the present invention will be given in part in the following description and in part will be obvious from the following description, or will be learned through practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0060] Figure 1 User operation flow chart released for this version of the invention.

[0061] Figure 2 A process for distributing npm packages is constructed for the present invention.

[0062] Figure 3 It is a web-visualized online management interface of the present invention.

[0063] Figure 4 In the present invention, independent submodules such as components, jssdk, etc. are independent git repositories. In the project, they can be bound to directories of different levels and locations. On the premise of maintaining the internal independence of the submodules, the organization is restored to a complete schematic diagram of the front-end project.

[0064] Figure 5 Automated construction and publishing flow chart for the present invention.

[0065] Figure 6 The invention is a method for automatically and silently constructing and deploying a web flow chart. DETAILED DESCRIPTION

[0066] The technical solutions in the embodiments of the present invention are described clearly and completely below. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0067] See also Figure 1 — Figure 6 In an embodiment of the present invention, a method for automated construction and release management of front-end multi-package projects is provided, based on the monorepo architecture and combined with the git submodule management mechanism, and the method comprises the following steps:

[0068] Step 1: Independent management of module versions:

[0069] Maintain each submodule in the monorepo architecture as a separate git repository while retaining its directory structure in the monorepo project;

[0070] Provide a web visualization interface for managing submodule version information, including a module list, a current working version list, and a historical version list, where:

[0071] The module list is grouped according to module purpose, showing module name and build status;

[0072] The current working version list shows the version number, dependency information, build time and notes of each submodule;

[0073] The historical version list is used to record and trace back all historical build versions and their dependencies;

[0074] Step 2: Parameterized construction and automated deployment:

[0075] Receive module building and publishing parameter information through the user interface, including target branch, module dependency, release version number, and deployment environment information;

[0076] Automatically performs the following actions based on the parameters received:

[0077] Switch to the target branch and resolve module dependencies;

[0078] Generate npm package and upload it to the remote warehouse;

[0079] Update the package.json file of the target project and submit it to the git remote;

[0080] Step 3: Automatically deploy web services:

[0081] Automatically trigger the deployment process of the web service based on the built npm package, including dependency installation, source code building, image generation and upload operations;

[0082] Upload the generated web image to the internal image repository and deploy it to the specified web server;

[0083] Step 4: Full process traceability management:

[0084] Keep operational records for each build and release task, including module version, dependency information, operator, build time, and build log;

[0085] The web visualization interface supports one-click rollback or copy operation process.

[0086] As a further solution of the present invention, the web visualization interface further includes a quick operation function module, which is used to complete the test version release or the formal version release of the module with one click, wherein: the test version release generates an npm package based on the test environment parameters input by the user, and publishes it to the test warehouse; the formal version release generates an npm package based on the formal environment parameters input by the user, and deploys it to the web server of the formal environment.

[0087] As a further solution of the present invention, the independent git repository of the submodule is bound to the parent repository in the monorepo project through a git submodule, specifically including: the version changes of the submodule are entered through the web interface, and the dependency configuration file of the parent repository is automatically updated; the dependency changes of the submodule are automatically parsed and executed in the build process of the parent repository.

[0088] As a further solution of the present invention, the construction parameters of the parameterized construction and deployment include the following:

[0089] checkouts parameter: used to declare the target branch or version tag of each submodule;

[0090] deploy parameter: used to declare the name of the npm package to be released, the version number, the release type, and whether it is a patch version;

[0091] fat parameter: used to declare the web branch and target server information that need to be updated after the release is successful.

[0092] As a further solution of the present invention, the automatically deployed web service includes the following steps:

[0093] S1, pull the web service source code;

[0094] S2, automatically switch to the target branch;

[0095] S3, install npm dependencies and perform web build operations;

[0096] S4, generate a web image and upload it to the internal image repository;

[0097] S5, deploy the image to the specified web server.

[0098] As a further solution of the present invention, the deployment of the web service is completed through a silent automation link, including the following contents: all operations are automatically triggered by the backend service through the received construction parameters without manual intervention; the execution status during the construction process is fed back in real time through the web interface.

[0099] As a further solution of the present invention, the full-process traceable management further includes: providing a visual display of historical construction tasks in the web interface, including version numbers, dependency information, build logs and operators; providing a one-click rollback function to roll back the current module version to a specified historical version; providing a process replication function for quickly reusing parameter configurations of historical tasks.

[0100] As a further solution of the present invention, the method is applicable to the following scenarios: automated construction and release of multi-module front-end projects within an enterprise; dependency management and deployment of service modules in a microservice architecture; modular management and automated release in an open source community.

[0101] As a further solution of the present invention, the system comprises:

[0102] User interaction module: used to receive module information, version information, build parameters and deployment environment information input by users, and present module status, version list and historical build records through the web visualization interface;

[0103] Parameter parsing module: used to parse the build parameters input by the user interaction module, including target branch, dependency, npm package version number and server deployment information, and generate build instructions;

[0104] Build execution module: used to automatically switch the target branch according to the parsed build parameters, perform dependency parsing, npm package generation and verification, and upload the build product to the remote npm repository;

[0105] Deployment execution module: used to trigger the deployment process of the web service according to the npm package generated by the build execution module, including dependency installation, source code building, image generation and upload operations;

[0106] Version management module: used to record module version information, dependencies, build time, operation logs and build status, and supports version backtracking and process replication;

[0107] Feedback module: used to feed back the execution status of build and deployment to the user interaction module in real time.

[0108] As a further solution of the present invention, the user interaction module and the version management module are integrated through a web interface, providing a one-click operation function and supporting the release of a test version or a formal version of the module;

[0109] The deployment execution module is integrated with the image repository and web server, supporting the storage of web build results in the form of images in the internal image repository and deployment to the target server;

[0110] The system is suitable for multi-module front-end engineering automation management scenarios within the enterprise, including module construction, version updates and rapid deployment of web services.

[0111] Embodiment 1:

[0112] Based on the code organization method of monorepo multi-package projects and the source code management mechanism of git submodules, the present invention designs a complete set of automated building and publishing processes.

[0113] The overall operation process is divided into three steps: user operation, remote construction and distribution of npm packages, and remote construction and deployment of web services. Except for user operation, which requires user participation, the two remote construction services are automatically triggered and executed. Figure 1 As shown:

[0114] The user visualization interface of the present invention provides a simple form and button operation. The user operation process starts with opening the application, entering module information, module corresponding npm package dependency branch information and release version number and other information on the interface, test version npm package release operation and options, and official version one-click release operation. The user's operation process on the interactive interface is as follows: Figure 2 As shown:

[0115] The process of automatically building and distributing npm packages receives information about user operation results through the service, and executes a series of automated instructions to achieve the purpose of automatically producing and uploading npm packages. The automatic construction and deployment of web packages takes over the output results of the automatic distribution of npm packages process, automatically updates dependency information on the remote service, and executes the web building and packaging process, and publishes the web image that needs to be deployed and accessed to the web server, completing the purpose of automatic web update. The specific organization and execution process are as follows:

[0116] 1. Version management of independent modules.

[0117] Each submodule of the monorepo project is maintained as an independent git repository, while retaining its directory structure in the monorepo project. On this basis, a web-based visual online management interface is built to enter and update the version information of each submodule. This interface mainly includes the module list (left), the version list of the current module in progress, and the historical version list (middle). The main management operations are concentrated in the main panel on the right side of the interface.

[0118] The module list is divided into business modules, packages, services and other groups according to their uses. The items in the group also display the module name, the number of versions currently being built / the total number of built versions, so that you can instantly view the busy and idle status of each module build.

[0119] The workspace mainly displays the list of versions currently in use. Each version entry records the current version number, version dependency, build account (operator), build time, and version notes. Version dependency is the most critical information, and version notes can be used to quickly mark the purpose of the current version.

[0120] A list of all versions lists all historical build records of the current module package, making it easy to trace the historical dependency information, build purpose, operator, etc. of a specific version number.

[0121] like Figure 4 As shown in the figure, independent submodules such as components and jssdk are independent git repositories. In the project, they can be bound to directories of different levels and locations. On the premise of maintaining the internal independence of the submodules, the organization can be restored to a complete front-end project.

[0122] Also, in the automated build and release process, the implementation subject is the API service deployed on the web server, which receives web requests issued during web interface operations and automatically executes the following through a series of built-in command instructions:

[0123] After receiving the publishing request from the user system through a web request, the distribution service automatically parses the parameters and switches to the target branch;

[0124] The parameter structure is as follows and is referred to as "build parameters" in the following text:

[0125] {

[0126] "checkouts": {

[0127] "@cem / module-dashboard": "v2.15.0_test",

[0128] "@cem / entity-components": "v3.24.2"

[0129] },

[0130] "deploy": {

[0131] "scope": "@cem / module-dashboard",

[0132] "tag": "beta",

[0133] "version": "2.15.0-beta1",

[0134] "hotfix": false

[0135] },

[0136] "default": {

[0137] "branch": "master"

[0138] },

[0139] "fat": {

[0140] "enabled": true,

[0141] "cem_front_branch": "chore / test_publish",

[0142] "server": "server3"

[0143] }

[0144] }

[0145] In the parameter structure, checkouts is the branch dependency information, and the dependency details are declared in the format of {module name}:{target branch / hash / tag}; deploy is the preset information of the published npm package, scope is the entity of the published npm package, tag indicates whether it is a release or beta version, version is the npm version number to be released, and hotfix declares whether it is a patch type; default is the default branch of other submodules that have not declared dependencies. The instruction will generate complete cut-out branches of all submodules through default and checkouts information; fat is the server deployment information, indicating the details of the npm package being deployed to the web server after it is successfully released, enabled is the deployment switch, if it is false, the web server deployment link will not be entered, cem_front_branch is the branch of the web general project to which the successfully published npm package will be updated, and server is the code used to deploy web servers within the enterprise, and the build results of the web general project are uploaded to this server.

[0146] Verify the integrity of the request parameters to ensure that the operation is not interrupted; the integrity is determined by whether the parameter structure is consistent with the "Build Parameters" definition, and whether all subordinate fields of deploy and default have non-empty values.

[0147] Execute the build instructions, generate the target npm package, and automatically complete the verification;

[0148] After the build product is verified (the . / dist directory exists and is not empty), the npm package is uploaded to the remote repository, the version information is updated to the package.json file of the target project, and submitted to the git remote;

[0149] According to the value of the parameter fat.cem_front_branch, if it is a meaningful string, it is determined that "automatic update of dependencies" is required, and the npm information is updated to the branch pointed to by "cem_front_branch"; if the value of fat.cem_front_branch is null, the result of the npm version build is returned, including version information and npm return results, and the execution program is exited;

[0150] Determine whether to trigger the subsequent deployment process based on the parameters (if fat.enabled has a value and is true, the deployment process will be entered, otherwise the deployment process will be exited) to complete the release of the relevant test environment or formal environment.

[0151] Embodiment 2:

[0152] The present invention provides an automated construction and release management method and system for front-end multi-package engineering, the specific application scenario of which is an enterprise-level front-end project. The project adopts a monorepo architecture, includes multiple business modules, a public component library, and a tool module, and serves the development needs of multiple product lines within the enterprise. The existing construction and release process has low development efficiency, high error rate, and difficulty in tracing due to the complex dependencies between modules and frequent version updates. Through the implementation scheme of the present invention, the efficiency and reliability of construction and release can be significantly improved.

[0153] In this scenario, the front-end project of an enterprise is divided into three main module categories: business modules (such as report modules and user management modules), public component library modules (such as UI components and tool functions), and service interface modules (such as API gateways). Each module exists in the project as a submodule and is uniformly organized and managed through the monorepo architecture. During the development process, due to the rapid iteration of business needs, individual modules often need to be updated and released independently. The traditional full-volume release mode leads to a large number of unnecessary dependency updates, while the manual release method requires too high skills from developers and is prone to errors.

[0154] In this embodiment, the following functions are implemented through the method and system of the present invention: such as independent management of module versions: each submodule is maintained as an independent git sub-repository, for example, the "report module" is @org / module-reports, which is stored in a unified monorepo project directory structure. Through the web visualization interface of the present invention, developers can intuitively view the current version (such as v2.1.0), dependencies (such as the v3.0.1 version of the dependent UI component library), and build history of the "report module". When the "report module" needs to be updated, the developer enters the target version number and dependency information in the interface and triggers a one-click build operation. The system will parse the input parameters, switch to the target branch through the git submodule mechanism, and automatically adjust the dependency configuration between modules, such as updating the UI component library that the "report module" depends on from v3.0.1 to v3.1.0.

[0155] Parameterized build and automated deployment: Developers select "official version" through the interface to release, and the system will automatically generate build parameters, for example:

[0156] {

[0157] "checkouts": {

[0158] "@org / module-reports": "v2.2.0",

[0159] "@org / ui-components": "v3.1.0"

[0160] },

[0161] "deploy": {

[0162] "scope": "@org / module-reports",

[0163] "version": "2.2.0",

[0164] "tag": "release"

[0165] },

[0166] "default": {

[0167] "branch": "main"

[0168] }

[0169] }

[0170] After receiving the above build parameters, the system performs the following operations in sequence: Switch to the target branch of the "report module" and adjust its dependent versions synchronously. Automatically call the npm command to generate the npm package of version @org / module-reports@2.2.0, and upload it to the company's internal npm repository after verification. Write the updated module version information to the package.json file of the monorepo project and submit it to the remote git repository. When the npm package is uploaded successfully, the system automatically triggers the deployment process according to the "release" tag in the parameter, updates the latest "report module" to the company's internal web server, and completes the launch of the formal environment.

[0171] Silent automated deployment: After the system is built, it automatically enters the deployment phase without the need for manual intervention by the developer. Taking the "report module" as an example, the system automatically pulls the latest source code through the silent deployment link, switches to the build branch, and performs the following operations in sequence: install the latest npm dependencies; generate web image files and push them to the internal image repository of the enterprise; deploy the image to the target server (such as prod-server-1) to complete the automated update of the web service; after the deployment is complete, the system will provide real-time feedback on the deployment results, including image generation logs, server status, and service availability verification results. For example, the system will display on the interface that the "report module" has been successfully deployed to the production environment, and mark the latest version number as 2.2.0.

[0172] Full-process traceable management: Detailed records of each build and release task are stored in the system, including module version, dependency version, operator, and build time. For example, when a compatibility issue occurs in the "report module", developers can use the interface to check whether the version of the "UI component library" it depends on is correct and quickly locate the problem; if a rollback is required, developers can directly roll back to the previous stable version, such as v2.1.0, with one click through the interface, and the system will automatically perform the rollback operation, including dependency switching, npm package downgrade, and web service restoration; in addition, the system supports fast copying of previous build tasks, such as the "test environment" build parameters can be migrated to the "formal environment" with one click to reduce repeated operations.

[0173] Through the above implementation methods, the present invention significantly optimizes the actual application of the monorepo architecture in enterprise-level projects, making module management more flexible. Through the independent maintenance mechanism of git submodules, developers can independently update and release single modules to avoid version redundancy problems caused by full release; the combination of parameterized build and silent deployment greatly reduces the manual operations of developers and realizes the full process automation from parameter input to web service update; the full process traceable management not only improves the efficiency of problem location and rollback, but also enhances the transparency and controllability of version management.

[0174] Embodiment 3:

[0175] Another typical application scenario of the present invention is the management and release of an internal component library of an enterprise, which serves multiple front-end projects, such as a UI component library, a data visualization tool library, and a server-side communication tool library. These component libraries are widely used in multiple teams and projects within an enterprise, and the efficiency of version management and release directly affects the progress of project development. However, due to the characteristics of multiple modules in the component library being interdependent and frequently updated, traditional construction and release methods are difficult to meet the needs.

[0176] Take a certain company's UI component library as an example. The component library consists of multiple independent modules, such as button components, form components, data table components, etc. Each module has a separate function definition and dependency relationship. For example, a "button component" may depend on a "theme management module", while a "data table component" may depend on a "page management module" and a "theme management module". When a module needs to be updated, the version information of the related dependent modules must be adjusted and released at the same time. This complex dependency relationship makes the traditional full-volume release mode extremely inefficient, because modules that do not need to be updated will also be forced to rebuild and release, resulting in a large amount of version redundancy. The manual adjustment and release method is too dependent on the operator, prone to operational errors, and thus affects the overall stability of the project.

[0177] In order to solve the above problems, the present invention optimizes the management and release of component libraries in the following ways, such as modular independent version management, where each component module is designed as an independent git sub-repository, for example, the "button component" is @org / button, and the "data table component" is @org / datatable. These modules are embedded in the monorepo project in the form of sub-modules, which not only retains the unity of the overall project, but also realizes the independence of a single module; when the "button component" needs to be updated, the developer only needs to select the module in the web visualization interface, enter the target version number and the version information of the dependent modules, for example, update the "button component" from v1.2.0 to v1.3.0, and update the dependent "theme management module" from v2.0.0 to v2.1.0. The system will automatically record this information and generate a new dependency configuration file.

[0178] After the developer enters the parameters, the system will generate build parameters based on the input information, for example:

[0179] {

[0180] "checkouts": {

[0181] "@org / button": "v1.3.0",

[0182] "@org / theme": "v2.1.0"

[0183] },

[0184] "deploy": {

[0185] "scope": "@org / button",

[0186] "tag": "release",

[0187] "version": "1.3.0"

[0188] }

[0189] }

[0190] The system executes the following steps in sequence according to the parameters: switch the branch of the "button component" to the target version and synchronously adjust the branches of its dependent modules; call the npm build command to generate a new npm package @org / button@1.3.0 and upload it to the company's internal npm repository; automatically update the dependencies of the "button component" in the component library, such as updating the version information of the "theme management module" in the package.json file of the component library.

[0191] After the system completes the npm package building, it will automatically trigger the predefined test script to ensure the functionality and compatibility of the module. For example, the test script of the "button component" will check whether its rendering effect is normal under different theme configurations; after the test passes, the system will publish the module to different environments according to the developer's choice. For example, the developer can choose to publish the module to the "test environment" for team verification, or directly publish it to the "formal environment" for project use. The entire process does not require manual intervention by the developer, reducing the possibility of human error.

[0192] During the build and release process, the system will provide real-time feedback on the execution status, such as the build log, test results, and release status of the npm package. If a module fails the test, the system will automatically record the failed test case and prompt the developer to fix it through the web interface; after the release is completed, the system will record detailed information on all operations, including build time, operator, version information of dependent modules, etc. This information not only supports the rapid location of problems, but also provides reference for future version iterations.

[0193] Through this implementation mode, the application process of the present invention in component library management and release avoids the version redundancy problem of full release through modular independent management, and significantly improves the efficiency of construction and release; the combination of parameterized construction and automated release reduces the steps of manual intervention and realizes the full process automation from parameter input to version release; automated testing and real-time feedback mechanism improve the stability and reliability of module release, and the full process traceability provides technical guarantee for problem location and rapid rollback.

[0194] In the present invention, unless otherwise clearly stipulated and limited, the terms "installation", "setting", "connection", "fixation", "screw-on" and the like should be understood in a broad sense. For example, it can be a fixed connection, a detachable connection, or an integral one; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium; it can be the internal connection of two elements or the interaction relationship between two elements. Unless otherwise clearly defined, ordinary technicians in this field can understand the specific meanings of the above terms in the present invention according to the specific circumstances.

[0195] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above and that the present invention can be implemented in other specific forms without departing from the spirit or essential features of the present invention. Therefore, the embodiments should be considered exemplary and non-restrictive in all respects, and the scope of the present invention is defined by the appended claims rather than the above description, and it is intended that all changes falling within the meaning and scope of the equivalent elements of the claims be included in the present invention.

Claims

1. A method for automated construction and release management of front-end multi-package projects, based on the monorepo architecture and combined with the git submodule management mechanism, characterized in that: The method comprises the following steps: Step 1: Independent management of module versions: Maintain each submodule in the monorepo architecture as a separate git repository while retaining its directory structure in the monorepo project; Provide a web visualization interface for managing submodule version information, including a module list, a current working version list, and a historical version list, where: The module list is grouped according to module purpose, showing module name and build status; The current working version list shows the version number, dependency information, build time and notes of each submodule; The historical version list is used to record and trace back all historical build versions and their dependencies; Step 2: Parameterized construction and automated deployment: Receive module building and publishing parameter information through the user interface, including target branch, module dependency, release version number, and deployment environment information; Automatically performs the following actions based on the parameters received: Switch to the target branch and resolve module dependencies; Generate npm package and upload it to the remote warehouse; Update the package.json file of the target project and submit it to the git remote; Step 3: Automatically deploy web services: Automatically trigger the deployment process of the web service based on the built npm package, including dependency installation, source code building, image generation and upload operations; Upload the generated web image to the internal image repository and deploy it to the specified web server; Step 4: Full process traceability management: Keep operational records for each build and release task, including module version, dependency information, operator, build time, and build log; The web visualization interface supports one-click rollback or copy operation process.

2. A method for automated construction and release management of front-end multi-package projects according to claim 1, characterized in that: The web visualization interface further includes a quick operation function module, which is used to complete the test version release or the official version release of the module with one click, wherein: the test version release generates an npm package based on the test environment parameters input by the user and publishes it to the test warehouse; the official version release generates an npm package based on the official environment parameters input by the user and deploys it to the web server of the official environment.

3. A method for automated construction and release management of front-end multi-package projects according to claim 1, characterized in that: The independent git repository of the submodule is bound to the parent repository in the monorepo project through the git submodule, specifically including: the version changes of the submodule are entered through the web interface, and the dependency configuration file of the parent repository is automatically updated; the dependency changes of the submodule are automatically parsed and executed in the build process of the parent repository.

4. A method for automated construction and release management of front-end multi-package projects according to claim 1, characterized in that: The build parameters of the parameterized build and deployment include the following: checkouts parameter: used to declare the target branch or version tag of each submodule; deploy parameter: used to declare the name of the npm package to be released, the version number, the release type, and whether it is a patch version; fat parameter: used to declare the web branch and target server information that need to be updated after the release is successful.

5. The method for automated construction and release management of front-end multi-package engineering according to claim 1, characterized in that: The automated deployment of the web service includes the following steps: S1, pull the web service source code; S2, automatically switch to the target branch; S3, install npm dependencies and perform web build operations; S4, generate a web image and upload it to the internal image repository; S5, deploy the image to the specified web server.

6. A method for automated construction and release management of front-end multi-package projects according to claim 5, characterized in that: The deployment of the web service is completed through a silent automation link, including the following: all operations are automatically triggered by the backend service through the received build parameters without manual intervention; the execution status of the build process is fed back in real time through the web interface.

7. A method for automated construction and release management of front-end multi-package projects according to claim 1, characterized in that: The full-process traceable management further includes: providing a visual display of historical build tasks in the web interface, including version numbers, dependency information, build logs and operators; providing a one-click rollback function to roll back the current module version to a specified historical version; and providing a process replication function for quickly reusing parameter configurations of historical tasks.

8. The method for automated construction and release management of front-end multi-package projects according to claim 1, characterized in that: The method is applicable to the following scenarios: automated construction and release of multi-module front-end engineering within an enterprise; Dependency management and deployment of service modules in microservice architecture; modular management and automated release in open source communities.

9. The method for automated construction and release management of front-end multi-package projects according to claim 1, characterized in that: The automated construction and release management system corresponding to the method includes: User interaction module: used to receive module information, version information, build parameters and deployment environment information input by users, and present module status, version list and historical build records through the web visualization interface; Parameter parsing module: used to parse the build parameters input by the user interaction module, including target branch, dependency, npm package version number and server deployment information, and generate build instructions; Build execution module: used to automatically switch the target branch according to the parsed build parameters, perform dependency parsing, npm package generation and verification, and upload the build product to the remote npm repository; Deployment execution module: used to trigger the deployment process of the web service according to the npm package generated by the build execution module, including dependency installation, source code building, image generation and upload operations; Version management module: used to record module version information, dependencies, build time, operation logs and build status, and supports version backtracking and process replication; Feedback module: used to feed back the execution status of build and deployment to the user interaction module in real time.

10. The method for automated construction and release management of front-end multi-package projects according to claim 9, characterized in that: The user interaction module and the version management module are integrated through the web interface, providing a one-click operation function and supporting the release of the test version or the official version of the module; The deployment execution module is integrated with the image repository and web server, supporting the storage of web build results in the form of images in the internal image repository and deployment to the target server; The system is suitable for multi-module front-end engineering automation management scenarios within the enterprise, including module construction, version updates and rapid deployment of web services.

Images