Project management method and device, electronic equipment, storage medium and program product

Abstract

The invention discloses a project management method and device, electronic equipment, a storage medium and a program product, and relates to the technical field of software development control, and the method comprises the steps: managing the construction path, output path and other information of a nested warehouse project through a unified configuration file, and achieving the centralized definition of a multi-project construction process; the problem of packaging dispersion caused by separate management of the sub-modules is avoided; the unified construction environment is initialized based on project information of centralized configuration, it is ensured that the dependency relationship of all modules and the construction process are coordinated and consistent, and the stability and reliability of the construction process are enhanced; command generation logic is constructed in a standardized mode, configuration complexity and later maintenance cost are reduced, and unified management and control of the process are achieved; through a centralized management mode driven by configuration, the defect of processing multi-warehouse construction deployment depending on manual scripts is eliminated, repeated labor is reduced, and development efficiency and project agility are improved.

Description

Technical Field

[0001] This application relates to the field of software development, and more particularly to a project management method, apparatus, electronic device, storage medium, and program product. Background Technology

[0002] In the software development field, as project scale increases and modularity improves, code repository management significantly impacts development efficiency and the smoothness of the Continuous Integration / Continuous Deployment (CI / CD) process. Currently, the mainstream single-repository management model often uses Git Submodules to associate and manage legacy modules. However, Git Submodules still faces many significant challenges in practical applications, especially in CI / CD process integration, where the problems are particularly pronounced.

[0003] First, the multi-project packaging process is complex. Since the build process and dependency updates for each submodule need to be managed separately, unified packaging is difficult, increasing the difficulty of collaborative building across multiple modules. Second, CI / CD processes are difficult to manage uniformly. Traditional solutions often rely on shell scripts for manual maintenance, which not only increases configuration complexity but also raises later maintenance costs. Third, the efficiency of automated build processes is weakened. The lack of a centralized management method makes it difficult to coordinate and maintain consistent dependencies and build processes between different modules, failing to ensure the stability and reliability of the build process. Finally, this model is difficult to scale efficiently. As project size increases and the number of modules grows, existing CI / CD solutions often face scalability bottlenecks, leading to process stagnation or inefficiency.

[0004] In this context, relying on manual scripts to handle the build and deployment processes of multiple repositories not only increases operational complexity but also leads to a significant amount of repetitive work, severely impacting development efficiency and project agility. More importantly, as team size and project complexity continue to grow, traditional CI / CD management solutions are increasingly unable to support the efficient operation of continuous delivery. Therefore, there is an urgent need in this field for a more efficient and automated solution to support unified packaging and pipeline integration of multiple projects, thereby addressing the aforementioned technical challenges. Summary of the Invention

[0005] In view of the above problems, this application provides a project management method, apparatus, electronic device, storage medium, and program product that overcomes or at least partially solves the above problems. The technical solution is as follows:

[0006] This application provides a project management method, which includes: obtaining a configuration file; wherein the configuration file includes project information of multiple projects under nested repository management, the project information including project name, project build path, result output path and build script; initializing the build environment of each project according to the project information of the multiple projects; generating build commands for each project according to the build script and the result output path; executing the build commands in the build environment to obtain the project build results of each project.

[0007] As an optional implementation method provided in this application, the step of obtaining the configuration file includes: when a user performs an initialization configuration operation on a terminal, calling an interactive command-line tool to ask the user questions related to project information; obtaining the user's answers to the questions; and generating the configuration file based on the answers.

[0008] As an optional implementation provided in this application, obtaining the configuration file includes: checking whether a user-specified configuration file path exists; if a user-specified configuration file path exists, then loading the configuration file from the configuration file path;

[0009] If the user-specified configuration file path does not exist, the configuration file is loaded from the project root directory.

[0010] As an optional implementation method provided in this application, the step of initializing the build environment of each project according to the project information of the plurality of projects includes: extracting the project build path of each project; creating sub-processes of each project and setting the working directory of the sub-processes, wherein the working directory corresponds to the project build path; and executing the build script of each project through the sub-processes of each project to complete the build environment initialization process of all projects.

[0011] As an optional implementation provided in this application, the project construction result includes log information; after executing the construction command in the construction environment to obtain the project construction results of each project, the method further includes: determining the progress identifier of each project based on the log information of each project; and sending the progress identifier of each project to the user terminal to present the construction progress of each project on the user terminal.

[0012] As an optional implementation provided in this application, the project construction result includes error information; after executing the construction command in the construction environment to obtain the project construction results of each project, the method further includes: writing the error information into an error log file; obtaining the error handling strategy corresponding to the error information; and executing the error handling strategy.

[0013] This application provides a project management device, the device comprising:

[0014] The acquisition module is used to acquire the configuration file; wherein, the configuration file includes project information of multiple projects in nested repository management, and the project information includes project name, project build path, result output path and build script;

[0015] An initialization module is used to initialize the build environment of each project based on the project information of the multiple projects;

[0016] The command generation module is used to generate build commands for each project based on the build script and the result output path;

[0017] The execution module is used to execute the build commands in the build environment to obtain the project build results for each project.

[0018] This application provides a computer-readable storage medium having a program stored thereon, which, when executed by a processor, implements the project management method described in any of the preceding claims.

[0019] This application provides a vehicle that includes an onboard oxygen generator and the aforementioned project management device.

[0020] This application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described project management methods.

[0021] This application manages the build paths and output paths of all nested repository projects through a unified configuration file, enabling centralized definition of multi-project build processes and avoiding the packaging issues caused by managing submodules separately. It replaces the traditional manual maintenance method of shell scripts with configuration files, standardizing the build command generation logic, reducing configuration complexity and later maintenance costs, and achieving unified process control. A unified build environment is initialized based on the centrally configured project information, ensuring consistency in module dependencies and build processes, enhancing the stability and reliability of the build process. Through the structured management mode of configuration files, when the project scale expands or the number of modules increases, only the configuration information needs to be extended to adapt to new requirements, breaking through the scalability bottleneck of traditional solutions and avoiding process stagnation or efficiency decline. Overall, this method, through a configuration-driven centralized management mode, eliminates the drawbacks of Git Submodules relying on manual scripts to handle multi-repository build deployments, reduces repetitive work, improves development efficiency and project agility, and can support efficient continuous delivery as team size and project complexity increase.

[0022] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0023] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0024] Figure 1 A schematic diagram of the specific system architecture on which the execution of a project management method provided in this application depends;

[0025] Figure 2 A schematic flowchart illustrating a project management method provided in an embodiment of this application is shown;

[0026] Figure 3 This illustration shows a schematic structural diagram of a project management device provided in an embodiment of this application;

[0027] Figure 4 A schematic structural diagram of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0028] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete, and will fully convey the scope of the present application to those skilled in the art.

[0029] To more clearly illustrate the embodiments of this application, the technical terms used in the embodiments will be briefly introduced below:

[0030] Single repository management, also known as monolithic repository mode, refers to storing all the code, modules, and even code from multiple related projects in the same Git (or other version control tool) repository for unified management.

[0031] Git Submodules is a built-in Git feature for managing sub-repositories. It allows multiple independent sub-repositories to be embedded within a main repository, and each sub-repository can maintain its own version and be independently associated with remote repositories. Simply put, its core functionality is that the main repository manages references, while the sub-repositories manage the code. The main repository only stores the current version number (commit ID) and path information of the sub-repository, while the actual code of the sub-repository is stored in a separate directory.

[0032] Currently, the mainstream single-repository management model in the industry often uses Git Submodules to associate and manage legacy modules. However, Git Submodules still faces many significant challenges in practical applications, especially in CI / CD process integration, where the problems are more pronounced: First, the multi-project packaging process is complex. Since the build process and dependency updates of each submodule need to be managed separately, unified packaging is difficult, increasing the difficulty of collaborative building across multiple modules; second, CI / CD processes are difficult to manage uniformly. Traditional solutions often rely on shell scripts for manual maintenance, which not only increases configuration complexity but also raises later maintenance costs; third, the efficiency of automated build processes is weakened. The lack of a centralized management method makes it difficult to coordinate and maintain consistent dependencies and build processes between different modules, failing to ensure the stability and reliability of the build process; finally, this model is difficult to scale efficiently. As project scale increases and the number of modules grows, existing CI / CD solutions often face scalability bottlenecks, leading to process stagnation or inefficiency.

[0033] In this context, relying on manual scripts to handle the build and deployment processes of multiple repositories not only increases operational complexity but also leads to a significant amount of repetitive work, severely impacting development efficiency and project agility. More importantly, as team size and project complexity continue to grow, traditional CI / CD management solutions become increasingly inadequate to support efficient continuous delivery.

[0034] To overcome or at least partially solve the aforementioned problems, this application provides a project management method. This method centrally manages key information of all nested repository projects through configuration files, including project name, project build path, result output path, and build script, breaking down the barriers of decentralized submodule management. In actual execution, the system can automatically identify the dependencies and build rules of each project based on the configuration files, achieving a shift from decentralized packaging to unified scheduling packaging, avoiding the complexity of manually handling submodule builds one by one. Standardizing project information through configuration files and generating build commands based on unified logic replaces fragmented script operations. This standardization mechanism reduces manual intervention, lowers the coordination costs caused by configuration differences between different projects, and enables the entire CI / CD process to be controlled through a unified framework, improving process consistency and maintainability. The steps of initializing a unified build environment and automatically generating build commands according to configuration ensure that all projects execute builds in a consistent environment and strictly follow the dependencies and process rules defined in the configuration files. This centralized management approach avoids problems such as environment inconsistencies and dependency conflicts that may occur when submodules are built independently, enhancing the reliability of the automated process. As the project scales up or the number of modules increases, simply adding project information to the configuration file allows the system to automatically adapt and integrate into the unified build process, without requiring modifications to the core logic. This configuration-driven design pattern overcomes the scalability bottleneck of traditional script-based solutions, enabling the CI / CD process to scale linearly with project size and avoiding the problem of decreased process efficiency as the project grows.

[0035] In summary, this method fundamentally solves the problems of complex management, poor consistency, and weak scalability of GitSubmodules in multi-project CI / CD integration by centralizing configuration, standardizing processes, and automating operations. It reduces manual operation costs and improves the efficiency and stability of continuous delivery.

[0036] like Figure 1 As shown, Figure 1 This is a schematic diagram of the specific system architecture on which the execution of a project management method provided in this application depends.

[0037] As the core hub, the scaffolding receives configuration files on one hand and ultimately generates the project build artifacts on the other.

[0038] The underlying framework relies on Node.js to provide the foundation for the upper layers to run.

[0039] The service layer uses a JSON schema validator (ajv) for data validation, a configuration file loader (cosmiconfig) for easy reading of configuration files, and a TypeScript helper library (tslib) to support TypeScript-related functions, ensuring the reliable execution of services such as configuration processing.

[0040] The interaction layer utilizes a terminal style library (chalk) to beautify terminal output, a command-line argument parser (commander) to parse command-line instructions, an interactive command-line tool (inquirer) to implement interactive questioning, a terminal loading animation library (ora) to display loading status, a semantic versioning tool (semver) to handle versions, and a path processing module (path) to operate on paths, thereby facilitating user interaction and process guidance.

[0041] The kernel layer extends file system operations through the enhanced file system module (fs-extra) and optimizes the compilation cache through the V8 compile-cache tool (v8-compile-cache), providing efficient support for core operations such as project building.

[0042] This system architecture receives configuration files (such as JS or JSON formats) on one hand and generates project build artifacts (dest) on the other, realizing a complete process from user interaction to obtain and process configurations to execute the build and output artifacts, thus improving the efficiency and standardization of project building.

[0043] like Figure 2 As shown, Figure 2 This application provides a schematic flowchart of a project management method, which includes:

[0044] S201. Obtain the configuration file.

[0045] This configuration file contains project information for multiple projects managed by nested repositories. Project information includes the project name, build path, output path, and build script. It can contain multiple projects managed by Git Submodules. The build path is the working directory for executing the build command, relative to the project root directory; the output path is the location where the build results are stored.

[0046] In some embodiments, when a user performs an initialization configuration operation on a terminal, an interactive command-line tool is invoked to ask the user questions related to project information, in order to obtain the user's answers to the questions, and then generate a configuration file based on the answers to the questions.

[0047] Specifically, when a user executes the `init` command in the terminal, the system first triggers a pre-defined command parsing logic to identify the user's intent as initialization configuration and then invokes an interactive command-line tool (such as `inquirer`) to initiate a question-and-answer process. This process will ask the user key questions related to project configuration in a pre-defined order, including the project name, build path, output path, and project build command. Every piece of information entered by the user is validated in real time for format validity (e.g., whether the path format is correct and whether the command conforms to basic syntax). If any abnormalities are found, the user is prompted to re-enter the information to ensure that the collected information is standardized and valid.

[0048] After all information is collected, optionally, the user's answers to the questions can be filled into the corresponding fields of a preset configuration file template to generate a standardized JavaScript configuration file. The JavaScript configuration file can be in .js or .json format. The JS file will contain export statements for configuration objects (e.g., module.exports = {...}) and include field description comments for easy manual modification later; the JSON file stores data in a pure data structure to ensure efficient machine parsing.

[0049] When generating the file, the system automatically checks if a configuration file with the same name already exists in the project root directory. If it does, the system prompts the user to overwrite it to avoid configuration loss due to accidental operations. After the file is generated, the system will report the operation results through the terminal log, including the storage path of the configuration file and a summary of key configuration items. It will also prompt the user that project parameters can be adjusted by editing the file, providing a standardized configuration basis for subsequent build processes.

[0050] Interactively obtaining project information and generating configuration files significantly improves the convenience and accuracy of configuration file creation. For users, there's no need to manually write complex configuration structures; they can simply answer project-related questions via the terminal to generate the configuration file, lowering the barrier to entry. Simultaneously, the interactive process guides users to provide complete key information such as the project name and build path through pre-defined question logic, avoiding information omissions or formatting errors that may occur during manual writing, ensuring the integrity and standardization of the configuration file. From a process efficiency perspective, this method standardizes and streamlines the configuration file creation process, reducing repetitive work for users in formatting adjustments and information completion, accelerating configuration preparation during the project initialization phase, and laying a reliable foundation for subsequent unified build and management processes based on configuration files.

[0051] In some embodiments, when retrieving the configuration file, the system first checks if a user-specified configuration file path exists; if it exists, the configuration file is loaded from that path; if it does not exist, the configuration file is loaded from the project root directory.

[0052] The loadConfig module loads a configuration file containing information about multiple projects from a specified path. If no path is specified, the path to the configuration file in the project root directory is used.

[0053] Specifically, when the loadConfig module is invoked, the system first checks if the user-specified configuration file path exists. If the user passes a specific path as a parameter (e.g., appending `--config. / custom / config.js` to the command), the module will first verify the validity of the path, including checking if the file exists and if the path format is correct, such as whether it is an absolute path or a relative path to the current working directory. If the path is invalid, the module will throw a clear error message such as "The specified path does not exist or cannot be accessed" and terminate the loading process.

[0054] If no path is specified, the module will automatically trigger the default path search mechanism, searching for standard-named configuration files in the project root directory according to the preset priority order. The default files searched include JavaScript format (such as config.js, build.config.js) and JSON format (such as config.json, build.config.json), and the search order can be adjusted through internal module parameters.

[0055] After finding a matching configuration file, the module determines the type based on the file extension: for JS format files, it loads and executes them directly through Node.js's require mechanism, supporting dynamic logic contained in the file (such as conditional statements, function calculations, etc.), and finally exports a configuration object; for JSON format files, it uses the JSON.parse method to parse them into a configuration object, ensuring the integrity of the data structure.

[0056] During loading, the module also performs basic validation on the configuration content, checking for necessary fields such as project name and build path. If any critical fields are missing, a warning log will be generated, prompting the user to supplement the configuration. After the configuration file is successfully loaded, the module standardizes the parsed configuration object, such as unifying the path format to absolute paths and converting relative paths to paths based on the project root directory. Finally, it returns the configuration data to the caller, providing a consistent configuration data foundation for subsequent build environment initialization and task execution.

[0057] This configuration file retrieval mechanism balances flexibility and standardization, effectively improving the adaptability and reliability of the configuration loading process. On one hand, it allows users to specify configuration file paths, meeting the needs of personalized scenarios. For example, in multi-environment deployments and temporary testing, users can quickly switch between different configurations without modifying the project structure, enhancing process flexibility. On the other hand, when no path is specified, it loads from the project root directory by default, establishing a standardized configuration storage specification. This avoids management chaos caused by scattered configuration files and reduces communication costs arising from inconsistent configuration locations during team collaboration. This configuration file retrieval mechanism ensures convenient operation in special scenarios while maintaining the overall order of project configurations, providing a stable configuration source for subsequent processes such as build environment initialization and command generation.

[0058] S202. Initialize the build environment for each project based on the project information of multiple projects.

[0059] Based on the project information in the configuration file, the build environment for each project is initialized sequentially, the project build script is executed using the child_process.exec method, and the working directory is dynamically adjusted to match the project path.

[0060] In some embodiments, when performing step S202, the project build path of each project is first extracted, then sub-processes of each project are created, and the working directories of these sub-processes are set; the working directories correspond to the project build paths. Then, the build scripts of each project are executed through the sub-processes of each project to complete the initialization process of the build environment for all projects.

[0061] Specifically, when initializing the build environment for each project based on the configuration file, the system first parses all project information recorded in the configuration file and processes them one by one in a preset order, which can be the order in which the projects are defined in the configuration file. For each project, the system first extracts its build path (entry) information. This path may be a relative path or an absolute path relative to the project root directory. The system will standardize it to an absolute path to ensure accuracy.

[0062] Subsequently, a child process is created using the `exec` method in Node.js's `child_process` module to execute the project's build scripts (commands defined in the `scripts` field, such as "npm run build" or custom scripts). To ensure the build scripts execute in the correct context, the system dynamically specifies the child process's working directory using the `cwd` (current working directory) property in the `options` parameter when calling the `exec` method, ensuring it precisely matches the build path of the currently processed project. This adjustment guarantees that relative path references, dependency looks, and other operations during script execution are based on the project's own directory structure, avoiding environmental interference between different projects.

[0063] The build environment initialization method described above effectively solves the problems of environment isolation and conflict during parallel builds of multiple projects through the design of subprocesses and independent working directories. First, an independent subprocess is created for each project, and its working directory is set as the project's build path. This ensures that the build operations of each project are performed in a dedicated environment, avoiding mutual interference between different projects due to dependency versions, temporary files, or environment variables, thus guaranteeing the purity of the build process. Second, the parallel processing capability of subprocesses improves initialization efficiency, especially in multi-module projects where the preparation of multiple build environments can be advanced simultaneously, shortening the overall initialization time. Furthermore, this method decouples the execution process of the build scripts for each project, ensuring that the initialization status of each project does not affect other projects. This facilitates individual monitoring and retrying of the initialization process of a specific project, enhancing the flexibility and fault tolerance of the build environment preparation.

[0064] Before executing the build script, the system performs a pre-processing environment check, including verifying the existence of the build path, the installation of required build tools, and sufficient permissions. If the check fails, the system immediately terminates the environment initialization of the current project, records the error information, and sends feedback to the user. The build can be retried once the problem is resolved. If the check passes, the `exec` method asynchronously executes the build script and captures the script's output log information (stdout) and error information (stderr) in real time. The former is used for progress display, and the latter is used for exception handling, thus completing the initialization of the build environment and script execution for a single project. The system then processes the next project according to the same logic until the environment initialization process for all projects is complete.

[0065] S203. Generate build commands for each project based on the build script and the output path.

[0066] For each project, a build command is generated based on its configuration information, for example...<project.script> ----dest=<project.outputDir> .

[0067] Specifically, the build script (project.script, such as "npm runbuild") and output path (project.outputDir, such as ". / dist") of the current project are first extracted from the configuration file. Then, according to the preset command concatenation rules, the two are combined into a complete executable command.

[0068] The project's build command "<project.script> ----dest=<project.outputDir> For example, the build script is used as the base command, and the output path parameter is appended by the "--" separator to form a command string like "npm runbuild----dest=. / dist".

[0069] This command generation method improves the consistency and reliability of build commands across multiple projects through structured configuration extraction and rule-based command concatenation. First, it accurately extracts key information such as build scripts and output paths from configuration files, avoiding issues like path errors and misspelled script names that can occur when manually entering commands, ensuring the accuracy of the basic command elements. Second, preset command concatenation rules transform scattered configuration items into standardized executable commands, ensuring that build commands across different projects follow a unified format. This eliminates command format confusion caused by differences in team members' operating habits, reducing communication costs and comprehension difficulties in collaborative builds across multiple projects. Furthermore, this method decouples command generation logic from specific project configurations. When command formats need adjustment, only preset rules need to be modified to apply the changes to all projects, improving the maintainability and scalability of the process.

[0070] For scenarios with more custom parameters, the system will automatically iterate through the list of additional parameters in the configuration and append them to the command in key-value pairs (such as "--mode=production") to ensure that all build requirements are passed correctly.

[0071] S204. Execute the build command in the build environment to obtain the project build results for each project.

[0072] The project build results include log information and error information.

[0073] After the command is generated, the system starts a child process to execute the command using the child_process.exec method, while specifying the working directory (cwd) that matches the project in the options configuration to ensure that the command runs in the correct context.

[0074] To achieve real-time output capture, the `child_process.exec` method binds stdout (standard output) and stderr (error output) event listeners: when the child process outputs log information, the stdout listener captures the content immediately, processes it through formatting (such as adding a project name prefix and distinguishing information levels), and then prints it to the terminal, making it convenient for users to track the build progress of each project; if an error occurs during execution (such as missing dependencies or syntax errors), the stderr listener captures the error information, records it synchronously to the logging system, and triggers warning prompts (such as highlighting the error content in the terminal).

[0075] In addition, the system sets a command execution timeout mechanism (the timeout period can be customized via a configuration file). If a build command for a single project fails to complete within a long time, the child process will be forcibly terminated and marked as a timeout error. After the command execution is complete, the system will determine the execution result based on the child process's exit code: an exit code of 0 indicates success, and the system continues processing the next project; a non-zero code indicates failure, and detailed error information is recorded, subsequent builds are paused, and the system awaits user confirmation on whether to continue or terminate the process. This allows for fine-grained control and visual tracking of the build process.

[0076] In some embodiments, after performing step S204, the method further includes: if the project build result includes log information, determining the project's progress identifier based on the project's log information, and then sending the progress identifier to the user terminal to present the project's build progress on the user terminal. If the project build result includes error information, first writing the error information to an error log file, simultaneously obtaining the error handling policy corresponding to the error information, and then executing the error handling policy. The error information includes, but is not limited to, stack trace information and error type. The error handling policy is set in a configuration file, such as "terminate when an error is encountered" or "continue executing other projects".

[0077] The system can provide real-time feedback on the build status to the user via a progress bar or logs; if the build is successful, the information is recorded; if it fails, the error information is captured and subsequent build tasks are terminated.

[0078] Specifically, the progress display component, such as a dynamic progress bar based on the ora library, is first initialized. Each project is assigned an independent progress indicator, and the name of the currently processed project, its current stage (such as "Building" or "Environment Check"), and the percentage of completion are displayed in a visual manner in the terminal.

[0079] Meanwhile, the logging system will output key nodes in the build process, such as "start executing script" and "dependency installation completed", to the terminal in the format of timestamp + project name. For detailed script execution logs, a hierarchical logging strategy will be used to selectively display them, which will ensure information transparency and avoid output redundancy.

[0080] Optionally, when a single project completes its build, the system will branch based on the exit status code of the subprocess: if the status code is 0, it indicates that the project build was successful, the progress bar will switch to the completion indicator, the logging system will record key information such as the build time and result path of the project to the local log file, and it will automatically enter the build process of the next project. If the status code is not 0, it indicates that the project build failed, the progress bar will immediately switch to the error indicator, and the error capture mechanism will be triggered. Error details collected through stderr events will be output to the terminal in real time and written to the error log file simultaneously. At this time, the system will perform subsequent operations according to the preset error handling strategy: by default, the entire build process will be terminated to prevent the error from spreading, and the user will be prompted in the terminal to check the error log, fix the problem, and then re-execute the build command to ensure the reliability of the build result.

[0081] This build result processing mechanism enhances the controllability and fault tolerance of multi-project build processes through refined progress feedback and flexible error handling strategies. Regarding progress presentation, progress indicators are extracted from log information and fed back to the user terminal in real time, allowing users to intuitively grasp the build status of each project. This solves the problem of opaque progress during parallel multi-project builds, enhancing the visibility and user experience of the process. For error handling, error information (including stack traces and error types) is written to log files for easy traceability. Simultaneously, automated processing is performed based on preset handling strategies in the configuration file (such as "termination" or "continue to other projects"). This avoids the rigidity of the overall process due to errors in a single project and allows for flexible control of the process according to actual needs, reducing the frequency and cost of manual intervention. This design balances process transparency and exception handling flexibility, effectively alleviating the inefficiency caused by ambiguous progress and rigid error handling in Git Submodules multi-project builds, further ensuring the stability and controllability of the build process.

[0082] In summary, the project management method provided in this application manages the build paths and output paths of all nested repository projects through a unified configuration file, enabling centralized definition of multi-project build processes and avoiding the packaging issues caused by managing submodules separately. It replaces the traditional manual maintenance method using shell scripts with configuration files, standardizing the build command generation logic, reducing configuration complexity and later maintenance costs, and achieving unified process control. It initializes a unified build environment based on centrally configured project information, ensuring consistency in module dependencies and build processes, enhancing the stability and reliability of the build process. Through the structured management mode of configuration files, when the project scale expands or the number of modules increases, only the configuration information needs to be extended to adapt to new requirements, breaking through the scalability bottleneck of traditional solutions and avoiding process stagnation or efficiency decline. Overall, this method, through a configuration-driven centralized management mode, eliminates the drawbacks of Git Submodules relying on manual scripts to handle multi-repository build deployments, reduces repetitive work, improves development efficiency and project agility, and can support efficient continuous delivery as team size and project complexity increase.

[0083] like Figure 3 As shown, embodiments of this application also provide a project management device, which includes:

[0084] The acquisition module 301 is used to acquire a configuration file; wherein, the configuration file includes project information of multiple projects in nested repository management, and the project information includes project name, project build path, result output path and build script;

[0085] Initialization module 302 is used to initialize the build environment of each project based on the project information of the multiple projects;

[0086] The command generation module 303 is used to generate build commands for each project based on the build script and the result output path;

[0087] Execution module 304 is used to execute the build command in the build environment to obtain the project build results of each project.

[0088] As an optional implementation provided in this application, the acquisition module 301 is specifically used for: when a user performs an initialization configuration operation on a terminal, calling an interactive command-line tool to ask the user questions related to project information; acquiring the user's answers to the questions; and generating the configuration file based on the answers.

[0089] As an optional implementation provided in this application, the acquisition module 301 is specifically used to: check whether a user-specified configuration file path exists; if a user-specified configuration file path exists, load the configuration file from the configuration file path; if a user-specified configuration file path does not exist, load the configuration file from the project root directory.

[0090] As an optional implementation provided in this application, the initialization module 302 is specifically used for: extracting the project build path of each project; creating sub-processes of each project and setting the working directory of the sub-processes, wherein the working directory corresponds to the project build path; and executing the build script of each project through the sub-processes of each project to complete the initialization process of the build environment of all projects.

[0091] As an optional implementation provided in this application, the project construction result includes log information; the execution module 304 is further configured to: determine the progress identifier of each project based on the log information of each project; and send the progress identifier of each project to the user terminal to present the construction progress of each project on the user terminal.

[0092] As an optional implementation provided in this application, the project construction result includes error information; the execution module 304 is further configured to: write the error information into an error log file; obtain the error handling strategy corresponding to the error information; and execute the error handling strategy.

[0093] Regarding the apparatus in the above embodiments, the specific manner in which each unit performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0094] like Figure 4 As shown, embodiments of this application also provide an electronic device, including a memory 401 and a processor 402, wherein the memory 401 stores a computer program and the processor 402 is configured to run the computer program to perform the steps in any of the above-described project management method embodiments.

[0095] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described project management method embodiments at runtime.

[0096] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0097] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described project management method embodiments.

[0098] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps in any of the above-described project management method embodiments.

[0099] The beneficial effects of the above embodiments can be referred to the beneficial effects of the corresponding methods provided above, and will not be repeated here.

[0100] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0101] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0102] In the description of this application, it should be understood that if the terms "upper", "lower", "front", "rear", "left" and "right" are used to indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, they are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the position or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application.

[0103] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0104] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A project management method, characterized in that, include: Obtain the configuration file; wherein the configuration file includes project information for multiple projects under nested repository management, and the project information includes project name, project build path, result output path, and build script; Based on the project information of the multiple projects, initialize the build environment for each project; Based on the build script and the result output path, generate build commands for each project; The build command is executed in the build environment to obtain the project build results for each project.

2. The method according to claim 1, characterized in that, The process of obtaining the configuration file includes: When a user performs initial configuration operations in the terminal, an interactive command-line tool is invoked to ask the user questions related to project information; Obtain the user's answer to the question; The configuration file is generated based on the answer.

3. The method according to claim 1, characterized in that, The process of obtaining the configuration file includes: Check if the user-specified configuration file path exists; If a user-specified configuration file path exists, then the configuration file is loaded from that configuration file path; If the user-specified configuration file path does not exist, the configuration file is loaded from the project root directory.

4. The method according to claim 1, characterized in that, The step of initializing the build environment for each project based on the project information of the multiple projects includes: Extract the project build path for each project; Create subprocesses for each of the projects and set the working directory of each subprocess, the working directory corresponding to the project build path; Each project's subprocess executes its own build script to complete the build environment initialization process for all projects.

5. The method according to claim 1, characterized in that, The project build results include log information; After executing the build command in the build environment and obtaining the project build results for each project, the method further includes: Based on the log information of each project, determine the progress indicator of each project; The progress indicators of each project are sent to the user terminal so that the construction progress of each project is displayed on the user terminal.

6. The method according to claim 1, characterized in that, The project build results include error messages; After executing the build command in the build environment and obtaining the project build results for each project, the method further includes: Write the error message to the error log file; Obtain the error handling strategy corresponding to the error information; Implement the error handling strategy.

7. A project management device, characterized in that, include; The acquisition module is used to acquire the configuration file; wherein, the configuration file includes project information of multiple projects in nested repository management, and the project information includes project name, project build path, result output path and build script; An initialization module is used to initialize the build environment of each project based on the project information of the multiple projects; The command generation module is used to generate build commands for each project based on the build script and the result output path; The execution module is used to execute the build commands in the build environment to obtain the project build results for each project.

8. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the project management method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the project management method as described in any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the project management method as described in any one of claims 1 to 6.

Images