Automatic deployment method and equipment of standardized project and storage medium

Abstract

The invention discloses an automatic deployment method and device of a standardized project and a storage medium, and relates to the technical field of computers, and the method comprises the steps: responding to a project deployment request, and calling a target execution file corresponding to the project deployment request; constructing a target development environment based on the operation parameters of the target equipment and the dependent tool of the target execution file; according to a project template determined in the project creation request, constructing a deployment project corresponding to the project template in the target development environment; calling a corresponding deployment component based on the target execution file, and adding a dependency relationship of an application component in the deployment component to a corresponding directory of the deployment project to obtain a configuration file; and configuring parameters of the application component according to the configuration file to obtain a deployed target project. According to the method, project deployment is completed by constructing the target development environment, generating the target project and integrating the deployment component, the problem of low project deployment efficiency is solved, and the deployment automation degree, consistency and reliability are improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more particularly to an automated deployment method, device, and storage medium for a standardized project. Background Technology

[0002] In modern software development and operations practices, software lifecycle management covers key stages such as code development, testing, and deployment. It requires the collaboration of multiple tools to support efficient teamwork and relies heavily on technologies such as version control, automated configuration management, infrastructure as code management, continuous integration, and continuous deployment.

[0003] In related technologies, when deploying developed projects to the production environment, engineers usually rely on manual operation based on their personal experience. However, different engineers have different operating habits and experience levels, which can easily lead to inconsistent parameter configurations, resulting in low project deployment efficiency.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a standardized method, device, and storage medium for automated deployment of projects, aiming to solve the technical problem of low project deployment efficiency.

[0006] To achieve the above objectives, this application proposes an automated deployment method for standardized projects, the method comprising:

[0007] In response to a project deployment request, invoke the target executable file corresponding to the project deployment request; Based on the target device's operating parameters and the target executable file's dependent tools, construct the target development environment; Based on the project template determined in the project creation request, construct the deployment project corresponding to the project template in the target development environment; Based on the target executable file, the corresponding deployment component is called, and the dependencies of the application components in the deployment component are added to the corresponding directory of the deployment project to obtain the configuration file; Configure the parameters of the application components according to the configuration file to obtain the target project after deployment.

[0008] In one embodiment, the operating parameters of the target device and the dependent tools of the target executable file are detected to determine the currently missing dependent tool information of the target device; Based on the currently missing dependency tool information, the corresponding missing dependency tool is retrieved from the preset tool library and deployed to the specified directory of the target device to obtain the dependency tool deployment result; Based on the deployment results of the dependent tools and the parameter set of the dependent tools in the target executable file, the parameters of the deployed dependent tools are configured to obtain the target dependent tools, and the environment configuration parameters of the development environment are determined by the standardized configuration template of the development environment. The target development environment is constructed based on the target dependent tools and the environment configuration parameters.

[0009] In one embodiment, in response to the project creation request, the project template determined in the project creation request is parsed to obtain a template parsing result containing the directory hierarchy, preset configuration file template, and file storage rules; Based on the template parsing results, a directory structure of the corresponding level is created under the specified path of the target development environment, and an initial configuration file, a host manifest storage file, and a list of components to be deployed are set in the corresponding directory structure to obtain the initial deployment project framework; The corresponding project is initialized as a version control repository in the root directory of the initial deployment project framework, and the association information between the version control repository and the remote repository is configured to obtain the deployment project.

[0010] In one embodiment, based on the target executable file, the deployment component corresponding to the deployment project is located and invoked from the component library; Write the dependencies of the application components in the deployment component to a specified location in the deployment project, and verify the compatibility of the dependencies with the existing configuration of the deployment project to obtain a compatibility report; Based on the compatibility report and the preset parameter configuration template, the operating parameters adapted to the target device are selected and assigned values ​​to generate the parameter configuration set of the application component; Based on the parameter configuration set of the application component, establish the calling association between the application component and the deployment project; The parameter configuration set and the corresponding call association are added to the corresponding directory of the deployment project to obtain the configuration file.

[0011] In one embodiment, an interaction request is created based on the component, and the submitted application component deployment-related configuration information is parsed to obtain the core deployment elements; Based on the aforementioned core deployment elements, construct a component encapsulation framework with a preset format; The core deployment elements are integrated into the corresponding positions of the component encapsulation framework according to their functional modules, and the calling logic and adaptation parameters between the core deployment elements are configured to obtain the initial deployment component. The initial deployment component is subjected to a local simulation deployment verification process. After successful verification, the initial deployment component is solidified and pushed to the component library to generate the callable deployment component.

[0012] In one embodiment, a local simulation deployment verification process is performed on the initial deployment component to detect the integrity of the calling logic, the rationality of parameter adaptation, and the compatibility of functional modules of the core deployment elements, and to generate a component verification failure report; Based on the component verification failure report, the logical conflict points, parameter mismatches and module connection vulnerabilities in the core deployment elements are located, and the calling logic rules are adjusted, the adaptation parameter values ​​are corrected and the module association interfaces are supplemented to obtain the optimized initial deployment component. The optimized initial deployment component is subjected to a simulated deployment verification process again until all verification items meet the preset standards, and the deployment component is generated.

[0013] In one embodiment, target projects that have passed verification in the development environment are automatically aggregated, their dependencies are packaged, and an offline deployment package is generated. The project offline deployment package is transmitted to a designated storage location in the user's production environment that is isolated from the development network via a preset online transmission medium, and the deployment package environment migration confirmation result is obtained. Based on the environment migration confirmation results of the deployment package, the executable file is self-extracted on the target server, and the deployment commands and parameters that are completely consistent with the local verification are called to execute the automated deployment task, so as to complete the closed loop of the entire offline deployment process.

[0014] In one embodiment, in response to a user-triggered infrastructure resource request command, a code file describing the cloud host resource requirements is generated based on the configuration file of the target project, and a corresponding code merging request is created; After the code merge request is approved, the code files are merged according to the trunk branch merging specification and the automatic code conflict resolution mechanism to obtain the final code file; Trigger the continuous integration deployment pipeline, call the final code file to execute the resource creation task, and complete the automated deployment of cloud host resources according to the requirements described in the code.

[0015] In addition, to achieve the above objectives, this application also proposes an automated deployment device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the automated deployment method for the standardized project as described above.

[0016] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the automated deployment method for the standardized project as described above.

[0017] This application provides an automated deployment method for standardized projects. The method includes: responding to a project deployment request by invoking the corresponding target executable file; constructing an adaptive target development environment based on the target device's operating parameters and the target executable file's dependencies; building the corresponding deployment project within this environment according to the project template determined by the project creation request; invoking deployment components through the target executable file and adding application component dependencies to the corresponding directory of the deployment project to generate a configuration file; and finally, configuring application component parameters based on the configuration file to obtain the deployed target project. This forms a fully automated deployment chain from environment building to project configuration. By accurately constructing the target development environment using the target device's operating parameters and dependencies, deployment failures caused by environment incompatibility are avoided. Automated addition of application component dependencies and parameter configuration eliminates the risks of errors and dependency omissions associated with manual configuration. Furthermore, the entire process follows a predetermined chain, reducing efficiency losses from fragmented operations. This achieves the technical effects of improving the accuracy of project deployment environment adaptation, ensuring accurate component dependency configuration, shortening the project deployment cycle, and reducing human intervention costs during deployment. Adaptive environment construction avoids environment-related failures from the source, automated dependency and parameter configuration improve deployment accuracy and efficiency, and the fully chained execution reduces time wasted on ineffective operations and labor costs.

[0018] In summary, this application solves the technical problem of low overall process efficiency by calling the target executable file, adapting the development environment to the target device, automating the construction and deployment of the project, and configuring component dependencies and parameters. It improves the automation level of project deployment and the efficiency of process connection, and achieves accurate and efficient deployment results. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0020] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a flowchart illustrating the first embodiment of the automated deployment method for the standardized project of this application; Figure 2 This is a flowchart illustrating the fifth embodiment of the automated deployment method for the standardized project of this application; Figure 3 This is a flowchart illustrating the seventh embodiment of the automated deployment method for the standardized project of this application; Figure 4 This is a flowchart illustrating the eighth embodiment of the automated deployment method for the standardized project of this application; Figure 5 This is a system framework diagram for this application; Figure 6 This is a schematic diagram of the automated deployment equipment of this application.

[0022] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0023] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0024] In related technologies, manual operation by engineers based on their personal experience is often relied upon. However, different engineers have different operating habits and experience levels, which can easily lead to inconsistent parameter configurations and thus low project deployment efficiency.

[0025] This application provides a solution as follows: First, in response to a project deployment request, the target executable file corresponding to the project deployment request is invoked. Then, based on the operating parameters of the target device and the dependent tools of the target executable file, a target development environment is constructed. Next, according to the project template determined in the project creation request, a deployment project corresponding to the project template is constructed in the target development environment. Then, based on the target executable file, the corresponding deployment component is invoked, and the dependencies of the application components in the deployment component are added to the corresponding directory of the deployment project to obtain a configuration file. Finally, the parameters of the application components are configured according to the configuration file to obtain the deployed target project.

[0026] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or automated deployment device capable of performing the above functions. The following description uses an automated deployment device as an example to illustrate this embodiment and the subsequent embodiments.

[0027] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0028] This application provides an automated deployment method for standardized projects, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the automated deployment method for the standardized project of this application.

[0029] In this embodiment, the automated deployment method for the standardized project includes steps S10 to S50: Step S10: Respond to the project deployment request and call the target executable file corresponding to the project deployment request.

[0030] In this embodiment, a project deployment request is a user-initiated instruction to start the entire project deployment process. The target executable file is an executable file that matches the project deployment request and drives the project deployment-related operations.

[0031] As an optional implementation, during the deployment of a project from the development environment to the production environment, upon receiving a project deployment request, the core identification information of the deployment request is extracted. Based on this identification information, a hierarchical and precise search is performed in a pre-set file index. This index categorizes and archives all executable files according to fixed file types and deployment type dimensions. During the search, the primary category dimension is matched first, followed by the secondary category dimension. After locating the matching target executable file, a basic status check is performed on the file. Once it is confirmed that the file is not corrupted or has abnormal execution permissions, a unique association is established between the project deployment request and the target executable file. Subsequently, the file retrieval process is initiated, loading the target executable file into a pre-set execution buffer and generating a basic request-response log, recording the request reception time, core identification information, file retrieval results, etc., thus completing the response to the project deployment request and the invocation of the target executable file. This method features a high degree of standardization in request processing and file retrieval, simple and direct retrieval and matching logic, fewer pre-verification steps, fast overall response and retrieval speed, strong adaptability to regular project deployment requests, and the ability to quickly complete basic request-response operations.

[0032] As an alternative implementation, after receiving and parsing a project deployment request, the core identification information is extracted from the request, along with additional information such as deployment requirements, execution preferences, and adaptation conditions. Multi-dimensional matching retrieval conditions are constructed based on the core identification information and additional information. A retrieval operation combining fuzzy matching and precise matching is performed in a dynamically updated file index. This index dynamically adjusts the weights of the classification dimensions based on the frequency of use of the executable file, the type of associated request, and the adaptability to the deployment scenario. During the retrieval, fuzzy matching is first used to filter candidate executable files that match the retrieval conditions from the index. Then, multiple rounds of precise filtering are performed on the candidate file set based on the additional information to finally determine the target executable file that perfectly matches the project deployment request. This method supports full-dimensional parsing of project deployment requests, can adapt to various requests with personalized additional requirements, and the multi-dimensional retrieval and dynamic weighted index improve the accuracy of file matching.

[0033] Step S20: Based on the operating parameters of the target device and the dependent tools of the target executable file, construct the target development environment.

[0034] In this embodiment, the target device is the hardware carrier that carries out project deployment and subsequent operation. The operating parameters are the basic operating indicators of the target device's own hardware performance, system configuration, and resource allocation rules. The dependent tools of the target executable file are various supporting software tools that support the normal operation of the target executable file and drive the project deployment process. The target development environment is a dedicated standardized operating environment adapted to the running requirements of the target executable file and the entire project deployment process.

[0035] As an optional implementation method, the operating parameters of the target device are extracted, and all basic indicators of the target device's hardware performance and system configuration are comprehensively collected, categorized, and initially organized. The target executable file is then parsed to extract the basic installation requirements, minimum operating requirements, and basic configuration specifications of the tools it depends on. Subsequently, a basic compatibility check is performed to verify whether the target device's basic hardware performance meets the minimum operating standards of all dependent tools. After the check is confirmed to be successful, all dependent tools are deployed on the target device in a pre-set fixed installation order, with standardized basic operating parameters to adapt to the target device's system configuration. After the dependent tools are deployed, a basic environment availability check is performed, individually testing whether each core dependent tool can start normally, and performing a basic reinstallation on any tools that fail to start. Once it is confirmed that all core dependent tools can start normally and independently, the target development environment is built. This method has a fixed and unified process, simple operation steps, fewer compatibility checks and tool configuration steps, fast overall environment building speed, strong adaptability to common types of dependent tools, and a low barrier to entry for basic operations.

[0036] As an alternative implementation method, the operating parameters of the target device are first collected to extract its basic hardware performance and system configuration. The performance characteristics, customized system configurations, resource allocation rules, and total schedulable resources of the target device are then analyzed to complete a refined analysis of the parameters and a summary of performance characteristics. Next, the target executable file is deeply analyzed to extract the installation requirements and operational needs of the dependent tools. The hierarchical dependencies, version compatibility rules, resource consumption requirements, and inter-tool operational standards are then identified. Subsequently, multi-dimensional compatibility verification is conducted to verify the matching degree between the target device's hardware performance, system configuration, and the operational requirements of each dependent tool. This also verifies the version compatibility and operational feasibility between different dependent tools, while anticipating potential resource contention and scheduling conflicts after tool deployment. Next, based on the performance characteristics of the target device and the hierarchical dependencies of the tools, a personalized tool deployment sequence is formulated. Dedicated operating parameters are configured for each dependent tool according to the specific operating parameters of the device. The schedulable resources of the target device are rationally allocated based on the resource consumption requirements of the tools. After deployment, interoperability testing between dependent tools is conducted to verify the stability of multi-tool collaborative operation. Then, based on the actual operating requirements of the target executable file, the system configuration of the target device and the resource scheduling rules of each tool are deeply optimized. Finally, a full-dimensional availability verification of the execution environment is performed, testing both the independent operating status of each dependent tool and verifying the interoperability between tools. After confirming that there are no anomalies, the target development environment is built. This method provides a deeper analysis of target device parameters and dependent tools; multi-dimensional compatibility verification can avoid various adaptation failures from the source; personalized deployment and configuration can highly match the performance characteristics of the target device; deep environment optimization can improve overall operating efficiency; and it has a strong ability to adapt to complex and diverse dependent tools and personalized device parameters.

[0037] Step S30: Based on the project template determined in the project creation request, construct the deployment project corresponding to the project template in the target development environment.

[0038] In this embodiment, a project creation request is a user-initiated instruction to generate a specific project. A project template is a pre-defined, standardized project prototype containing a fixed directory structure, basic configuration items, and a core framework. Deploying a project is a project entity built on the project template within the target development environment, ready for subsequent deployment operations.

[0039] As an optional implementation, the project template identifier information specified in the project creation request is extracted. Based on this identifier, a precise search is performed in a preset template library. After locating the corresponding project template, its integrity is verified. Once it is confirmed that the template contains a complete directory structure, basic configuration files, core scripts, and framework files without any missing or corrupted elements, the template replication process is initiated in the target development environment. Corresponding folders are generated one by one according to the preset directory hierarchy of the project template, and all basic files in the template are synchronously copied to the corresponding directories. Subsequently, the copied files are path-adapted, and basic configurations related to the target development environment path are adjusted to ensure that the files can be read normally in that environment. After completion, a project framework integrity verification is performed to check that the directory hierarchy and file quantity are consistent with the template, with no omissions or incorrect replication. The basic usability of the core configuration files is tested, and after confirming that there are no path errors, format abnormalities, or other issues, the project deployment is completed. This method has a high degree of standardization, fast template replication and adaptation efficiency, strong adaptability to conventional standardized project templates, and a low probability of error.

[0040] As an alternative implementation, the project creation request is first parsed to extract the project template identifier and the personalized adjustment requirements specified in the request. Based on the project template identifier, the corresponding basic template is retrieved from the dynamic template library. Simultaneously, the configurable module list of the template is retrieved to determine the scope of adjustable directory levels, configuration items, and script logic. The basic template is then loaded into a temporary processing space. Based on the personalized requirements and the target development environment's runtime configuration, the template is specifically adjusted. This involves optimizing the directory structure to adapt to the environment's resource scheduling rules, modifying core configuration parameters to match the paths and runtime standards of dependent tools in the environment, adjusting script logic to adapt to the environment's execution mechanism, and adding new files and configurations corresponding to the personalized requirements. After the adjustments are complete, the optimized template content is synchronized to the target development environment. A project folder is generated according to the adjusted directory structure, all files are copied, and the final paths and parameters are adapted. Multi-dimensional verification is then performed to check the integrity of the project framework, test the compatibility of the adjusted configuration files and scripts with the target development environment, and assess the effectiveness of the personalized requirements. Any verification anomalies are corrected. Once all issues are confirmed, the project is deployed and built. This method is highly adaptable, meets diverse and personalized needs, and can deeply fit the operating characteristics of the target development environment, resulting in a more practical project framework.

[0041] Step S40: Based on the target executable file, call the corresponding deployment component, add the application component's dependency relationship in the deployment component to the corresponding directory of the deployment project, and obtain the configuration file.

[0042] In this embodiment, the application component is the component within the deployment component that carries core business functions. Dependencies are the associations between prerequisite components, resources, or configurations required for the normal operation of an application component. The corresponding directory is a designated file directory within the deployment project specifically used to store dependency configurations. The configuration file is a standardized file that records the dependency relationships of application components.

[0043] As an optional implementation, the pre-defined deployment component association identifier in the target executable file is parsed. Based on this identifier, the corresponding deployment component is retrieved from the component library, and after component integrity verification, the deployment component is loaded. Then, the basic dependencies of all application components in the deployment component are extracted, and the first-level associations between application components and core pre-components are identified. Next, the directory corresponding to the pre-defined dependency configuration in the deployment project is located, and the extracted first-level dependencies are entered one by one into a blank configuration file template in that directory according to a fixed format. After entry, the configuration file undergoes basic format verification to check whether the entry format of the dependencies conforms to the template specification. If no format errors are found, the configuration file is saved, completing the addition of dependencies and the generation of the configuration file. This method has a simple operation process, only processes core first-level dependencies, has high efficiency in dependency extraction and entry, a simple format verification step, short overall processing time, and strong adaptability to common simple deployment scenarios.

[0044] As an alternative implementation, the target executable file is deeply analyzed to extract deployment component association identifiers and to identify the pre-defined dependency resolution rules and adaptation requirements within the file. Based on these deployment component association identifiers and rules, the corresponding deployment component is retrieved from the dynamically updated component library. After verifying component integrity and version compatibility, the component is loaded. Subsequently, a full-dimensional dependency resolution is performed on the application components within the deployment component, identifying not only primary dependencies but also multi-level, implicit, and cross-component dependencies, while also noting the version requirements, execution priority, and resource consumption of each dependency. Next, the corresponding directory for the deployment project's dependency configuration is located. Based on the deployment project's directory structure and adaptation requirements, the dependency entry format is customized, and the fully resolved dependencies are entered hierarchically into the configuration file templates of the corresponding directories according to priority. After entry, multi-dimensional verification is performed, checking both the configuration file format specifications and the compatibility between dependencies and the deployment project, as well as the compatibility between dependencies. Any verification anomalies are corrected in real time. After correction, the configuration file is saved, completing the dependency addition and configuration file generation. This method offers comprehensive dependency resolution, covering multi-level, implicit, and cross-component dependencies. Multi-dimensional verification can avoid dependency compatibility failures from the source, and the customized input format can closely match the characteristics of the deployment project, making it highly adaptable to complex deployment scenarios.

[0045] Step S50: Configure the parameters of the application components according to the configuration file to obtain the target project after deployment.

[0046] In this embodiment, parameters are configuration items that determine the running state of application components, the adapted environment, and the implementation of functions. The target project is the final project entity that can run normally after all parameter configurations are completed.

[0047] As an optional implementation, the application component parameter configuration requirements recorded in the configuration file are first read, and the basic parameter items and default configuration values ​​corresponding to each application component are extracted. Basic validation of the parameter format and logical relationships in the configuration file is performed. After confirming that there are no format errors and no missing core parameters, parameter configuration is carried out one by one according to the loading order of the application components, and the default configuration values ​​are synchronously entered into the parameter configuration interface of the corresponding application component. During the configuration process, the parameter entry status is synchronized in real time to avoid duplicate or missed entries. After all component parameter configurations are completed, basic validity validation is initiated to test whether each application component can start normally based on the configured parameters and whether the core functions can be initially implemented. For components with startup anomalies, the accuracy of parameter entry is checked and corrected. After confirming that all application components can start normally and that the core functions are normal, the parameter configuration process is completed, and the deployed target project is obtained. This method has a simple and standardized process, parameter configuration proceeds according to fixed logic, has high operational efficiency, the basic validation step is easy to implement, and it has strong adaptability to simple application components.

[0048] As an alternative implementation, the configuration file is parsed to extract the parameter items and configuration requirements of each application component. The interrelationships between parameters, their compatibility with the target development environment, and performance optimization thresholds are identified. Combined with the dependencies of already loaded deployment components, the priority order of parameter configurations is determined. Subsequently, targeted parameter configuration is performed, adjusting parameter values ​​to adapt to the environment's resource scheduling rules based on the target development environment's operating characteristics and resource allocation. For parameters with interrelationships, configuration is simultaneously optimized to ensure logical consistency. For key parameters of core business components, fine-tuning is conducted based on functional requirements, and the impact of parameter configuration on component operation is monitored in real time during the configuration process. After completing full parameter configuration, multi-dimensional verification is performed. This verifies the validity of each component's parameters and the completeness of its functionality, tests the compatibility of parameter configurations with the environment and dependent components, and conducts performance stress testing. Based on the test results, parameters are fine-tuned to improve operational efficiency. Parameter conflicts and compatibility anomalies are identified and corrected, resulting in a successfully deployed target project. This method configuration aligns with environmental and business needs, and fine-tuning and multi-dimensional verification ensure project stability and performance, adapting to complex application components and diverse scenarios.

[0049] For example, in a project deployment scenario, a user executes the `jetdev env deploy` command on a new machine. The environment management module is invoked, automatically detecting and installing all necessary dependencies and completing relevant configurations (such as Git (Global Information Tracker) information, Ansible configuration files, etc.), quickly building a standardized development environment. Then, for a specific customer environment or cluster, the developer executes the `jetdev sitecreate <environment type><site name>` command. The project template and generation module create a site project locally based on the command parameters. This site has a standardized directory structure for storing the host inventory, variable configurations, and a list of components to be deployed. This site is automatically initialized as a Git repository and pushed to the remote codebase. If a new application (such as Redis) needs to be deployed, the developer can execute the `jetdev role create redis` command to create a role project. This role project encapsulates all the tasks, templates, and default variables required for deploying Redis. In the role project, the developer writes Ansible tasks (YAML, Ain't Markup Language). The development and verification of the component are performed using the `make local-verify` command within the built-in local testing framework (based on the Quick Emulator (QEMU) or Docker container engine) to ensure the correctness of the component's deployment logic. After development, a versioned role is published using the `jetdev rolerelease` command. Subsequently, in the site project (e.g., `cluster-test`), the developer executes the `jetdev site component redis` command. The system automatically adds the versioned redis component dependency to the site project's configuration file. Then, the developer configures specific parameters (such as port number, password, etc.) for the redis component in the site project's host manifest and variable files.Afterwards, in the Site project, developers can execute the `make local-verify` command again to fully verify the entire Site deployment process in a simulated environment. Once verification is successful, execute the packaging command. The offline deployment packaging module will start, packaging all content that the Site project depends on (including all referenced role component code, configuration files, scripts, etc.) into a single, self-extracting executable file (e.g., `cluster-test-v1.2.tar.gz.run`). Then, copy the packaged file generated in the previous step to the customer's production environment, isolated from the development network, via offline transfer media. On the production server, operations personnel only need to execute the file; the file will automatically decompress and use the exact same commands and parameters as during local verification to execute the Ansible deployment task, thus ensuring the consistency and reliability of the deployment process. Furthermore, when cloud server resources are needed, users can execute the `jetdev terraform apply` command. The Infrastructure as Code (IaC) management module will generate Terraform code describing resource requirements based on the configuration file and create a Global Information Tracking System (Git). Once the tracker receives a merge request, the relevant personnel receive an approval notification. After the code review is passed and the merge is completed, the Continuous Integration / Continuous Deployment (CI / CD) pipeline is triggered, automatically invoking Terraform to create cloud resources. The entire process achieves the codification and process-orientation of infrastructure management.

[0050] By standardizing environment construction, generating templated projects, and configuring component-based dependencies, the system solves the problems of slow environment adaptation, chaotic project structure, and complex dependency management in traditional project deployment, thereby improving the automation efficiency and cross-environment consistency of project deployment.

[0051] Based on any of the above embodiments, in Embodiment 2 of this application, step S20 includes steps A11 to A14: Step A11: Detect the operating parameters of the target device and the dependent tools of the target executable file, and determine the currently missing dependent tool information of the target device.

[0052] In this embodiment, the missing dependency tool information refers to the information related to the supporting tools required by the target executable file that are not currently installed on the target device, have an incompatible version, or are abnormally configured.

[0053] As an optional implementation, the operating parameters of the target device are collected, and basic information such as the names and versions of the tools installed on the target device is extracted and compiled into a list. The target executable file is then parsed to extract core information such as the names and minimum version requirements of the tools required for its execution. Subsequently, a basic comparison is performed between the list of tools installed on the device and the information of the tools required by the executable file to verify whether the tool names match completely. Tools with mismatched names are directly identified as missing, and only the names of the missing tools are recorded. After the comparison is completed, a basic verification is performed on the missing tool information to check for duplicate records or name entry errors. After correction, a structured list of missing dependent tools containing only the tool names is compiled. This method has a simple operation process, with parameter collection and tool parsing focusing only on core name and version information. The comparison logic is simple and direct, the overall detection efficiency is high, and it has strong adaptability to the detection of common single-dependency tools.

[0054] As an alternative implementation, the operating parameters of the target device are collected, and the names and versions of installed tools are extracted. The installation paths, configuration status, running permissions, and compatibility with the system environment of these tools are also analyzed to create a multi-dimensional archive of installed tools. The target executable file is then further analyzed to extract comprehensive information on the names, version ranges, installation path requirements, configuration specifications, running permissions, and system environment compatibility standards of dependent tools. Subsequently, a multi-dimensional comparison is conducted to verify whether the tool names and versions match, and to check whether the installation paths and configuration statuses meet the requirements. Simultaneously, the resource support capabilities of the tools are analyzed in conjunction with the operating parameters of the target device to determine whether the tools are functionally missing. Various missing conditions, such as missing names, incompatible versions, and abnormal configurations, are included in the detection scope, and detailed information on the names, types, and compatibility requirements of the missing tools is recorded. After the comparison is completed, a full-dimensional verification is performed to cross-validate the accuracy and completeness of the missing information, correcting errors or omissions, and finally generating a refined report on missing dependency tools that includes the type of missing tool, compatibility requirements, and repair suggestions. This method has comprehensive detection dimensions, can identify various explicit and implicit dependency tool missing situations, generates highly refined information reports, can provide comprehensive basis for subsequent dependency tool completion, and has a strong ability to adapt to complex dependency tool detection scenarios.

[0055] Step A12: Based on the currently missing dependency tool information, retrieve the corresponding missing dependency tool from the preset tool library, and deploy the dependency tool to the specified directory of the target device to obtain the dependency tool deployment result.

[0056] In this embodiment, the preset tool library is a standardized resource library built in advance to store various available dependency tools. The designated directory is a dedicated file directory pre-defined on the target device for storing the deployed dependency tools. The dependency tool deployment result is feedback information that records the status and results of the entire dependency tool retrieval and deployment process.

[0057] As an optional implementation, the missing dependency tool information is parsed, and the core identifier of the tool name is extracted. Based on this core identifier, a precise name matching search is performed in a preset tool library. After locating the corresponding dependency tool, its basic integrity is verified. Once no file corruption is confirmed, the pull process is initiated, and the tool's basic installation files are fully pulled to the target device's temporary cache space. After the pull is complete, the integrity of the pulled files is checked. If no files are missing, the pulled dependency tool installation files are directly copied to a designated directory on the target device according to fixed deployment rules. After the files are stored and deployed, basic path and permission configurations are performed on the tool files in the designated directory, setting general running permissions. Subsequently, a basic verification of the deployment results is performed, checking whether the corresponding tool files exist in the designated directory and whether the number of files matches the number pulled. The verification results, pull status, and deployment path are organized into a structured dependency tool deployment result. This method has a high degree of standardization in its operation process, simple tool retrieval and pull logic, fewer deployment steps, fast overall pull and deployment efficiency, strong adaptability to common basic dependency tools, and easy implementation of basic verification.

[0058] Step A13: Based on the deployment results of the dependent tools and the parameter set of the dependent tools in the target executable file, configure the parameters of the deployed dependent tools to obtain the target dependent tools, and determine the environment configuration parameters of the development environment through the standardized configuration template of the development environment.

[0059] In this embodiment, the deployed dependency tools are the supporting software tools successfully stored in the specified directory of the target device. Parameter configuration is the operation of setting the runtime configuration items for the deployed dependency tools. The target dependency tool is the dependency tool that can normally adapt to the project deployment requirements after the parameter configuration is completed. The standardized configuration template for the development environment is a preset standardized parameter reference template used to standardize the setup of the development environment. Environment configuration parameters are the configuration items for the linkage of various systems, resources, and tools required to set up the development environment.

[0060] As an optional implementation, the deployment results of dependent tools are analyzed to extract basic information such as the names and paths of deployed dependent tools. The tool's running permissions, file association status, and basic compatibility with the target device system are also analyzed to form a detailed tool profile. Further analysis of the dependent tool parameter set in the target executable file extracts the parameter items and configuration requirements of each dependent tool. Simultaneously, the linkage relationships, running priorities, and performance optimization thresholds between parameters are analyzed. Combined with the target device's running parameters, personalized parameter configuration schemes are developed for each deployed dependent tool. The basic parameter values ​​and optimized parameter values ​​adapted to the device characteristics are combined and entered into the configuration interface. Parameters of tools with linkage relationships are configured synchronously to ensure logical consistency. After configuration, multi-dimensional parameter verification is performed to verify the accuracy of parameter input and test the startup status, running stability, and compatibility with the device system of the dependent tools after parameter configuration. After correcting anomalies, highly compatible target dependent tools are obtained. Subsequently, the standardized configuration template for the development environment is retrieved, and its parameter architecture, configuration specifications, and the compatibility range of each parameter are deeply analyzed. Combined with the parameter configurations of the deployed target dependent tools, the operating parameters of the target devices, and the core requirements of the project deployment, the basic environment configuration parameters in the template are specifically adapted and adjusted, optimizing resource allocation and tool linkage parameters. After adjustment, multi-dimensional parameter verification is conducted to check the matching degree between the adjusted parameters and the configurations of the target dependent tools and the operating characteristics of the devices. Simultaneously, the logical correlation and feasibility between parameters are verified. After confirming that there are no adaptation conflicts or logical contradictions, the final environment configuration parameters for the development environment are determined. This method provides a deeper analysis of deployment results and parameter sets. Personalized parameter configurations can highly fit the needs of target devices and projects. Multi-dimensional verification can avoid parameter configuration anomalies from the source. Adapting and adjusting template parameters ensures a deep match between environment configuration parameters and target dependent tools, demonstrating a strong ability to adapt to complex dependent tools and diverse project deployment needs.

[0061] As an alternative implementation, the target executable file and target device's target environment type, host identifier, and business scenario requirements are first semantically decomposed to identify the environment level, core business needs, and potential dependency adaptation requirements required for initialization. Then, a historical environment initialization record library is automatically referenced to match historical cases similar to the current request scenario. The adapted dependency combination schemes, optimal configuration parameter values, anomaly types encountered during initialization, and corresponding mitigation measures are extracted from these historical cases and organized into structured auxiliary decision-making information. Next, based on the parsed core requirements and extracted historical auxiliary information, a pre-verification is performed on the compatibility of the proposed dependent software versions and the matching degree between host configuration and dependency requirements to predict potential initialization risks. Afterward, the semantic parsing results, historical auxiliary decision-making information, and pre-verification conclusions are fed back to the user for confirmation on whether to adopt the recommended dependency scheme and configuration parameters. If the user requests adjustments, user instructions are received and pre-processing results are updated synchronously. Once the user confirms, the environment initialization request is formally responded to, and the subsequent layered dependency installation and configuration process is initiated. This method utilizes pre-semantic parsing, historical experience reuse, and pre-risk verification mechanisms for environment initialization requests.

[0062] Step A14: Construct the target development environment based on the target dependent tools and the environment configuration parameters.

[0063] As an optional implementation method, the types, operating characteristics, and storage paths of the target dependent tools are first identified, and core configuration items in the environment configuration parameters are extracted to establish a basic association between the tools and their corresponding configuration parameters. Following a preset fixed setup sequence, all target dependent tools are loaded into a designated runtime queue, and the tools are started sequentially, applying their corresponding environment configuration parameters. This synchronously completes the basic adaptation between the tools and the system environment, ensuring that the tools can start normally based on the configuration parameters. During the setup process, the tool loading status and parameter application results are recorded in real time. After the basic setup is completed, a basic environment availability check is performed to test whether the core target dependent tools can run independently and whether the configuration parameters are effective. The basic linkage between tools is verified to be normal, and basic corrections are made for startup failures and parameter invalidations. Once it is confirmed that there are no core faults, the construction of the target development environment is complete. This method features a standardized setup process, simple operation steps, no need for complex adaptation adjustments, high overall setup efficiency, strong adaptability to common target dependent tools and basic configuration parameters, and low implementation difficulty.

[0064] As an alternative implementation, the operational requirements, resource consumption characteristics, and hierarchical linkages between the target dependent tools are analyzed. The architecture of the environment configuration parameters, the adaptation range of each parameter, and the matching standards with the target device are broken down. Based on the operating parameters of the target device, the environment configuration parameters are optimized and adjusted to rationally allocate device resources to adapt to the tool's operational needs and avoid resource competition between tools. Subsequently, the deployment priority is divided according to the tool's functional modules. The target dependent tools are loaded module by module, and the adjusted environment configuration parameters are applied synchronously and accurately. After each module is built, the compatibility between the module's tools and configuration parameters, and the linkage effect of tools within the module are tested. The next module is then built. After the inter-module construction is completed, a full-dimensional linkage verification is conducted to test the stability of cross-module tool collaborative operation and the adaptation effect of configuration parameters to the overall environment. Simultaneously, based on potential project deployment needs, the allocation of environment resources and tool operating thresholds are finely optimized, and issues such as parameter conflicts, abnormal tool linkages, and unreasonable resource allocation are investigated and corrected. After confirming stable environment operation, accurate tool adaptation, and efficient resource scheduling, the target development environment is completed. The method's setup process is tailored to the characteristics of the tools and the actual equipment, with well-optimized resource allocation and tool linkage. Multi-dimensional verification can avoid various environmental failures from the source, and it has a strong ability to adapt to complex tool combinations and personalized configuration parameters.

[0065] For example, in a project deployment scenario, in response to the environment initialization request for Redis cluster deployment, a comprehensive detection is performed on the target device's Linux CentOS 7.9 runtime environment. This confirms that 12 types of tools, including Python 3.9 and SSH service, are currently installed. System configuration parameters are obtained (e.g., kernel version 3.10.0-1160.el7.x86_64, 16GB memory, 8 CPU cores). Three missing dependency tools are detected: Ansible 2.15, Git 2.41, and Docker 24.0.6. This information is then integrated to generate an environment detection report containing 32 detection items, a list of missing tools, and detailed system configuration information. Based on the missing tool list in the environment detection report, the corresponding versions of the dependency tools are retrieved from a preset tool repository and deployed to the specified directory ` / usr / local / deploy-tools` on the target device. After deployment, a dependency tool deployment result is generated, containing information on successful deployment of the three types of tools, their storage paths, and integrity verification results. Based on the deployment results, the parameters of the deployed tools are configured (such as Ansible timeout of 30 seconds and Git username configured as deploy-user). The system configuration of the development environment is determined according to the standardized configuration template of the development environment (using the Ansible Playbook configuration model), the permission settings (assigning directory read and write permissions to deploy-user), and the association configuration (establishing collaborative call rules between Docker and Ansible) are completed. Finally, the target development environment adapted for Redis cluster deployment is built.

[0066] By standardizing the environment testing, deployment, and configuration processes, the problems of chaotic environment adaptation, difficulty in identifying missing dependencies, and inconsistent configurations before project deployment are solved, thereby improving the efficiency and adaptability of building the target development environment and ensuring the stability of the subsequent deployment process.

[0067] Based on any of the above embodiments, in Embodiment 3 of this application, step S30 includes steps B11 to B13: Step B11: In response to the project creation request, parse the project template determined in the project creation request to obtain the template parsing result containing the directory hierarchy, preset configuration file template and file storage rules.

[0068] In this embodiment, the directory hierarchy refers to the hierarchical structure of files and folders within the project template. The preset configuration file template is a standardized prototype of a configuration file pre-defined in the template for subsequent configuration. File storage rules are the specifications for file classification, naming, and storage location defined in the template. The template parsing result is a structured output containing the above three types of information obtained after parsing the project template.

[0069] As an optional implementation, a project creation request is obtained, the selected project template identification information carried in the project creation request is extracted, a preset template parsing rule set is invoked, and the project template is structuredly parsed according to the fixed parsing dimensions in the rule set. The preset multi-level directory hierarchy, the format templates of various configuration files, and the storage rules of different types of files in the template are identified in sequence. The parsed information is classified and organized according to the preset output format, the attribute identifiers of various information are supplemented, and the template parsing result containing the complete directory hierarchy, configuration file templates, and file storage rules is integrated to generate a template parsing result containing the complete directory hierarchy, configuration file templates, and file storage rules. The advantages of this implementation are that the parsing process is highly standardized, the execution speed is fast, and the parsing compatibility with conventional templates is good. The disadvantage is that the parsing dimensions are fixed and cannot be adapted to special project templates containing personalized extension nodes. The effect is that it can quickly complete the standardized parsing of conventional project templates and provide a unified and standardized parsing basis for subsequent project creation.

[0070] As another optional implementation, a project creation request is obtained, and the selected project template identification information and associated personalized project requirements carried in the request are extracted. Based on the personalized project requirements, extended parsing dimensions are dynamically generated. The basic parsing dimensions and extended parsing dimensions are combined to perform a full-dimensional in-depth analysis of the project template. This not only identifies the preset basic directory hierarchy, configuration file templates, and file storage rules in the template, but also mines the personalized extended directory nodes, custom configuration file templates, and special file storage rules in the template. The correlation between the parsed basic information and extended information is verified, conflicting information is eliminated, and missing correlation descriptions are supplemented. The results are integrated to generate a structured template parsing result containing basic information and extended information. The advantages of this implementation are that the parsing dimensions are flexible and highly adaptable, and it can accurately parse special project templates containing personalized content. The disadvantages are that the parsing process is complex, requires multiple rounds of verification, and the overall execution time is relatively long. The effect is that it can accurately parse various personalized project templates, providing a comprehensive and detailed parsing basis for subsequent customized project creation.

[0071] Step B12: Based on the template parsing result, create a directory structure of the corresponding level under the specified path of the target development environment, and set the initial configuration file, host manifest storage file and component list file to be deployed in the directory structure to obtain the initial deployment project framework.

[0072] In this embodiment, the specified path is a pre-defined storage location in the target development environment used to store the deployed project. The initial configuration file is the basic configuration information file required for the project to run. The host manifest storage file is a file that records the target deployment host information. The list of components to be deployed is a file that records the names and versions of the components to be deployed. The initial deployment project framework is the project infrastructure formed by integrating the directory structure and various initial files.

[0073] As an optional implementation, the template parsing results are obtained, and the directory hierarchy is optimized and adjusted based on potential project expansion needs. A basic directory hierarchy and an extended directory hierarchy are created in a specified path within the target development environment. Then, based on a preset configuration file template and customized according to expansion needs, initial configuration files, host manifest storage files, and a list of components to be deployed are generated. Extended attribute identifiers are added to various files, and basic files are stored in the basic directory, while extended files are stored in the extended directory. After completion, the compatibility of the directory structure and file content is verified, the validity of the extended directories and files is checked, and the initial deployment project framework is integrated. This method is highly flexible, balancing basic and extended needs, and can construct an initial deployment project framework that is both standardized and scalable, improving the project framework's adaptability to subsequent personalized development.

[0074] Step B13: Initialize the corresponding project as a version control repository in the root directory of the initial deployment project framework, and configure the association information between the version control repository and the remote repository to obtain the deployment project.

[0075] In this embodiment, the version control repository is a storage repository used to track project file changes and manage version iterations. Remote repository association information is configuration information used to establish connections between the local repository and the remote repository.

[0076] As an optional implementation, the root directory path information of the initial deployment project framework is extracted, and a preset version control repository is created in the root directory according to the version control initialization rule set, generating a basic version control configuration file. Then, the preset remote repository address and association parameters are read, and the association parameters are written into the version control configuration file to complete the association configuration between the local and remote repositories. Subsequently, repository initialization verification is performed to confirm that the version control function and remote association status are normal, and the project is then integrated into a deployment. This method has a high degree of standardization in its initialization process, fast execution speed, and can quickly complete the project version management configuration, ensuring the standardization of project version iteration.

[0077] As an alternative implementation, an initial deployment project framework is obtained, and a version control strategy is determined based on the project's subsequent iteration requirements. A version control repository conforming to the strategy is created in the framework's root directory, generating a personalized configuration file containing branch management rules. Next, the multiple remote repository types required by the project within this initial deployment framework are identified, and the addresses, permission parameters, and association priorities of different remote repositories are configured. These multiple sets of association information are written to the configuration file according to priority. After completion, a multi-repository association verification is performed to confirm that all remote repositories can connect and synchronize data normally, integrating them to form the deployment project. This method is highly adaptable, meeting the needs of multi-repository management and personalized version control, and improving the project's adaptability to complex iteration scenarios.

[0078] For example, in a project deployment scenario, in response to a Redis cluster project creation request, the selected 3-node Redis cluster project template is parsed to obtain a template parsing result containing 5 levels of directory hierarchy (root directory, vars variable configuration directory, inventory host manifest directory, roles component storage directory, scripts script directory), 8 preset configuration file templates (including requirements.yml, site.yml, etc.), and 3 types of file storage rules (configuration files are stored in the vars directory, host manifests are stored in the inventory directory, and component files are stored in the roles directory). Based on this template parsing result, a corresponding 5-level directory structure is created under the specified path / usr / local / deploy / projects in the target development environment. The initial configuration file (containing basic project runtime parameters), the host manifest storage file (recording the IP and port information of 8 target deployment hosts), and the component list file to be deployed (listing 4 components to be deployed, including Redis and Nginx) are set to obtain the initial deployment project framework. Based on this initial deployment project framework, the corresponding project is initialized as a Git version control repository, and related information such as remote repository address, access key and synchronization frequency are configured. Three initial branches, namely trunk, development and test, are set up to form the deployment project.

[0079] By using template-based parsing, standardized framework construction, and version control processes, the problems of chaotic project creation processes, inconsistent directory structures, and lack of version management have been solved, thereby improving project creation efficiency and deployment standardization.

[0080] Based on any of the above embodiments, in Embodiment 4 of this application, step S40 includes steps C11 to C15: Step C11: Based on the target executable file, locate and call the deployment component corresponding to the deployment project from the component library.

[0081] In this embodiment, the component library is a pre-established collection of resources that stores various deployment components. Location is the operation of finding the specific storage location of a deployment component within the component library.

[0082] As an optional implementation, the unique identifier information of the deployment component carried in the target executable file is extracted. A preset component matching rule set is invoked, and a precise search is performed in the component library according to the identifier information to locate the deployment component that perfectly matches the identifier. Subsequently, the version integrity and storage status of the deployment component are verified. Once confirmed, the deployment component is directly extracted from the component library to a preset temporary storage path, completing the component retrieval operation. This method offers high retrieval efficiency, high component matching accuracy, and good adaptability to standardized component retrieval needs. It can quickly complete the retrieval of deployment components with clear identifiers, ensuring efficiency and accuracy in common component referencing scenarios.

[0083] As an alternative implementation, the functional description information and adaptation requirements of the deployment components carried in the target executable file are extracted. Based on the functional description information, the core features of the components are parsed, and multi-dimensional component retrieval rules are invoked. A comprehensive search is performed in the component library according to multiple dimensions such as functional features, adaptation scenarios, and version compatibility, filtering out multiple candidate deployment components that meet the requirements. Then, the candidate components are prioritized according to the adaptation requirements, the optimal component is selected, and its matching degree with the target scenario is verified. After confirmation, the deployment component is extracted from the component library to a specified path, completing the component retrieval operation. This method has a wide range of applicability, can handle fuzzy retrieval requirements without clear identification, and can accurately match deployment components with complex functional requirements, improving the flexibility and adaptability of component retrieval.

[0084] Step C12: Write the dependencies of the application components in the deployment component to a specified location in the deployment project, and verify the compatibility of the dependencies with the existing configuration of the deployment project to obtain a compatibility report.

[0085] In this embodiment, dependencies refer to the various components or resources involved in the dependency relationship. Existing project configuration refers to the configuration information that is currently in effect for deploying the project. Compatibility refers to the degree of matching and adaptation between dependencies and the project's existing configuration. The updated configuration file is the configuration file after the dependencies have been written and compatibility checks have been completed. The compatibility report is a standardized document that records the results of dependency and existing configuration checks.

[0086] As an optional implementation, the dependencies of application components in the deployment components are extracted and hierarchically resolved to determine the priority and associated constraints of each dependency. These dependencies are then written into a designated location in the deployment project configuration file according to a custom structured format. After writing, a multi-dimensional compatibility verification mechanism is initiated, comprehensively comparing the newly added dependencies with the existing project configuration from multiple dimensions, including version compatibility, functional relevance, and resource usage conflicts. Optimization suggestions are generated for conflicts discovered during verification, and a detailed compatibility report containing verification results, conflict analysis, and optimization solutions is integrated, simultaneously generating an updated configuration file. This method offers comprehensive compatibility verification dimensions, can identify potential hidden conflicts, adapts to complex dependency entry scenarios, and reduces the probability of subsequent deployment failures caused by configuration conflicts.

[0087] Step C13: Based on the compatibility report and the preset parameter configuration template, filter and assign values ​​to the operating parameters that are compatible with the target device to generate the parameter configuration set of the application component.

[0088] In this embodiment, the preset parameter configuration template is a sample file containing pre-defined standardized parameter configuration rules and value ranges. Assignment is the operation of setting corresponding running values ​​for the selected parameter items. The application component's parameter configuration set is a standardized parameter set that integrates all compatible parameter items and their corresponding values.

[0089] As an optional implementation, the core identifiers of application component parameter items that are compatible with the target device and are marked in the compatibility report are extracted, and basic parameter items without compatibility conflicts are identified. Then, a preset parameter configuration template is parsed to extract the basic definitions, configuration ranges, and default values ​​of all parameter items in the template. A basic matching relationship is established between the template parameter items and the compatible parameter items in the compatibility report. Operating parameters compatible with the target device are selected based on the principle of consistent identifiers, and the default values ​​in the preset parameter configuration template are uniformly assigned to the selected parameters. After assignment, the parameter configuration content undergoes basic format validation to check the accuracy of the correspondence between parameter items and assigned values, and to verify whether there are any omissions or duplicate assignments. After correcting format-level anomalies, all assigned compatible parameters are integrated and sorted according to the preset structure of the template to form a structured application component parameter configuration set. This method has a high degree of standardization in parameter parsing, filtering, and assignment processes, simple operation steps, and only performs basic identifier matching and default assignment. It has fast overall processing efficiency and strong adaptability to common basic adaptation scenarios.

[0090] As an alternative implementation, the compatibility report is parsed to extract the application component parameter identifiers compatible with the target device. The performance compatibility thresholds, device resource matching standards, and conflict avoidance requirements for each parameter are then identified, along with the priority of core business-related parameters. Next, the preset parameter configuration template is parsed to extract the complete configuration specifications and adjustable value ranges for all parameter items. The hierarchical relationships, numerical matching logic, and performance optimization thresholds between parameter items are analyzed. Based on the actual operating parameter characteristics of the target device, operating parameters that meet both the compatibility report's compatibility requirements and match the device's hardware performance and system configuration are selected from the preset parameter configuration template. Personalized assignment schemes are developed for parameters of different priorities. Core business parameters are assigned precise values ​​based on device performance compatibility thresholds and optimization requirements, while regular parameters are assigned values ​​within adjustable ranges based on device resource scheduling rules. Simultaneously, the interrelationships between parameters are considered to ensure consistent assignment logic for related parameters. After assignment, multi-dimensional verification is performed. This checks the accuracy of the correspondence between parameter items and assigned values, verifies whether the assigned parameters meet the compatibility report's adaptation requirements and match the target device's operating parameters, and tests the rationality of the linkage operation of related parameters. Targeted corrections are made for adaptation conflicts, unreasonable values, and contradictory linkage logic issues discovered during verification. Once all anomalies are confirmed, all parameter items are categorized and integrated according to business function modules and priorities, forming a refined and structured application component parameter configuration set. This method offers comprehensive parameter selection dimensions, accurately matches the actual operating characteristics of the target device, and its personalized assignment balances business priorities and parameter linkage relationships. Multi-dimensional verification can avoid parameter adaptation anomalies from the source, adapting to various complex performance requirements and multi-parameter linkage project deployment scenarios.

[0091] Step C14: Based on the parameter configuration set of the application component, establish the calling association between the application component and the deployment project.

[0092] In this embodiment, the call association relationship is the association rule and mapping relationship that ensures that the application component can be correctly called by the deployed project.

[0093] As an optional implementation, the parameter configuration set of application components is parsed to extract basic information such as component name, parameter items, and assigned values. The running priority, parameter linkage rules, functional implementation logic, and resource usage requirements of each application component are then analyzed to form a refined component call profile. A full-dimensional analysis of the deployment project is then conducted to extract all call interfaces, the business directory nodes to which the interfaces belong, the interface call triggering logic, the interface resource capacity, and the collaborative call rules between multiple interfaces. Combined with the business logic and directory structure of the deployment project, a personalized call matching scheme is formulated. According to the running priority and functional implementation logic of the application components, appropriate call interfaces under the corresponding business directory nodes are matched. Simultaneously, interface call resources are reasonably allocated based on the component call resource usage requirements and interface resource capacity. All parameters and parameter linkage rules in the parameter configuration set are synchronized to the corresponding call interfaces and adapted. Subsequently, call levels are divided according to component running priority, establishing a multi-dimensional call association mapping system that includes component name, interface identifier, parameter synchronization path, call priority, resource allocation rules, and parameter linkage logic. After establishing the mapping relationship, multi-dimensional verification is performed. This includes checking the uniqueness and accuracy of the mapping relationship, testing the smoothness of component call triggering and the effectiveness of parameters during the call process, and verifying whether there are conflicts in collaborative calls between multiple components and whether resource allocation is reasonable. Targeted corrections are made for various anomalies discovered during verification. Once it is confirmed that there are no call conflicts, parameters are correctly adapted, and resource allocation is reasonable, the association between application components and the deployment project is established. This method provides a deeper analysis of the configuration set and the deployment project, and the personalized matching scheme can highly match the business logic of the deployment project and the operational characteristics of the components. The multi-dimensional mapping system takes into account both call priority and resource allocation.

[0094] Step C15: Add the parameter configuration set and the corresponding call association to the corresponding directory of the deployment project to obtain the configuration file.

[0095] As an optional implementation, the method first parses the parameter configuration set and its associated relationships, extracting the core content of both types of information. A one-to-one correspondence is established based on parameter item identifiers and associated relationship identifiers to ensure accurate information matching. Next, the corresponding directory of the deployment project is located, and the accuracy of the directory path and access permissions are verified. Once confirmed, the corresponding information is added item by item to the blank configuration template in the directory according to a fixed format. Parameter configuration sets are entered according to component names, and associated relationships are supplemented by sorting by interface identifiers. The entry status is synchronized in real time during the addition process to avoid omissions or errors. After addition, a basic integrity check is performed to verify whether the number of entered parameter items and associated relationships is complete, whether the correspondence is accurate, and whether the configuration file in the directory has been successfully generated. If there are no format errors or missing information, the configuration file is archived with basic naming, and the associated component and project information is labeled according to preset rules, completing the addition process and obtaining the configuration file. This method features a standardized process, simple operation steps, straightforward information addition and verification logic, high overall efficiency, strong adaptability to common basic configuration information, and easy implementation.

[0096] For example, in a project deployment scenario, based on a Redis component reference request, the Redis 6.2 deployment component is located and retrieved from the component library. The dependencies of the application components within this deployment component are written to a specified location in the `requirements.yml` configuration file of the `cluster-redis` deployment project. The dependencies are verified to be compatible with two existing configurations and conflicting with one version, resulting in an updated configuration file and a compatibility report containing conflict analysis. Based on the updated configuration file, the compatibility report, and the Ansible parameter configuration template, 12 parameters adapted to the target device's Linux CentOS 7.9 runtime environment are selected and assigned values ​​(e.g., port 6379, timeout 30s), generating a parameter configuration set for the application components. Based on this parameter configuration set, the calling relationship between the Redis application components and the `cluster-redis` deployment project is established to complete the development and deployment of the `cluster-redis` deployment project.

[0097] By accurately retrieving components, verifying dependency compatibility, configuring parameter adaptation, and implementing call association processes, the system solves the problems of chaotic component dependencies, mismatched parameters, and invalid call associations during project deployment, thereby improving the automation level and operational stability of project deployment.

[0098] Based on any of the above embodiments, in Embodiment 5 of this application, referring to Figure 2 , Figure 2 This is a flowchart illustrating the fifth embodiment of the automated deployment method for the standardized project of this application. Before step S40, steps D11-D14 are also included: Step D11: Create an interaction request based on the component, parse the submitted application component deployment-related configuration information, and obtain the core deployment elements.

[0099] In this embodiment, the component creation interaction request is an instruction that triggers the parsing of application component deployment configuration information. The submitted application component deployment-related configuration information consists of various deployment rules and runtime parameter data submitted by the user for creating the application component. The core deployment elements are a set of key information supporting the completion of application component deployment.

[0100] As an optional implementation, this method extracts application component deployment-related configuration information carried in the component creation interaction request. It then invokes a pre-defined standardized parsing rule set and, based on the fixed parsing dimensions defined in this set, structurally decomposes the configuration information, sequentially identifying key elements such as deployment process rules, resource consumption requirements, and operational constraints. These key elements are then categorized and integrated according to a pre-defined format, eliminating duplicate and invalid redundant information to ultimately form the core deployment elements. This method features a standardized and consistent parsing process, high execution efficiency, and good adaptability to parsing common configuration information, ensuring the smooth progress of the basic application component creation process.

[0101] As an alternative implementation, the application component deployment-related configuration information and associated personalized creation requirements carried in the component creation interaction request are obtained and extracted. Based on these personalized requirements, a multi-dimensional parsing framework is dynamically generated, covering multiple parsing levels including basic deployment rules, extended functional requirements, and special operational constraints. The component deployment-related configuration information is then deeply deconstructed across all dimensions to identify core deployment content, uncover hidden personalized configuration details, and perform correlation verification and supplementary explanations on the various types of information obtained from the deconstruction. Ultimately, this results in core deployment elements containing both basic and personalized elements. This method offers flexible and comprehensive parsing dimensions, strong adaptability, and can accurately parse complex personalized configuration information, improving the application component's adaptability to diverse deployment scenarios.

[0102] Step D12: Based on the core deployment elements, construct a component encapsulation framework with a preset format.

[0103] In this embodiment, the component encapsulation framework is a component infrastructure formed by integrating and deploying core elements according to a preset format.

[0104] As an optional implementation, basic deployment information and core functional requirements are extracted from the core deployment elements. A pre-defined standardized encapsulation format template is invoked, and the core deployment elements are integrated one by one into the various pre-defined modules of the template according to the fixed directory structure, file naming rules, and content filling specifications in the standardized encapsulation format template. After integration, the integrity of the framework structure and the matching degree of elements are verified, and redundant information with adaptation anomalies is removed. Finally, a component encapsulation framework in the pre-defined format is constructed. This method has a high degree of standardization in the construction process, fast execution efficiency, and can ensure the uniformity of the framework, providing stable support for the encapsulation of basic application components.

[0105] Step D13: Integrate the core deployment elements into the corresponding positions of the component encapsulation framework according to the functional module classification, and configure the calling logic and adaptation parameters between the core deployment elements to obtain the initial deployment component.

[0106] In this embodiment, functional modules are independent units divided according to component functions. The invocation logic refers to the invocation association rules between core deployment elements. The initial deployment component is the basic component unit after element integration and logic configuration are completed.

[0107] As an optional implementation, the core deployment elements are obtained and broken down into different modules—deployment process, resource requirements, and operational constraints—according to a preset functional module division standard. Then, based on the structural specifications of the component encapsulation framework, the elements of each functional module are integrated one by one into the corresponding positions of the framework. A preset standardized call logic template is invoked, and fixed call association rules are configured for each element, while default adaptation parameters are loaded to complete parameter assignment. After completion, the completeness of element integration and the validity of the call logic are verified. Once no conflicts are confirmed, the initial deployment component is obtained. This method has a high degree of standardization in the integration process, fast execution efficiency, and can ensure the uniformity of the component framework, providing stable support for the development of basic application components.

[0108] Step D14: Perform a local simulation deployment verification process on the initial deployment component. After successful verification, solidify the initial deployment component and push it to the component library to generate the callable deployment component.

[0109] In this embodiment, the local simulation deployment verification process is an operation process that verifies the functionality and compatibility of components by simulating an actual deployment environment locally. Solidification is the operation of fixing the structure, configuration, and functionality of the initially deployed components. Callable deployment components are standardized components that can be referenced in subsequent projects after verification and solidification.

[0110] As an optional implementation, an initial deployment component is obtained, and a pre-defined standardized local simulation deployment verification rule set is invoked. Following the fixed deployment steps, verification dimensions, and judgment criteria in this rule set, the simulated installation, runtime triggering, and functional verification of the component are executed sequentially. The operational status and result data of each stage are recorded, and the verification is completed by comparing them with the pre-defined pass / fail criteria. After successful verification, a fixed component solidification template is invoked to lock the component's structure, configuration, and functional parameters, generating a standardized component version. The solidified component is then pushed to a pre-defined storage location in the component library, completing the component's registration and generating a callable deployment component. This method features a high degree of standardization in the verification and solidification process, fast execution efficiency, good adaptability to common components, and ensures the supply efficiency and standardization of basic components in the component library.

[0111] As an alternative implementation, the functional characteristics and adaptation requirements of the initial deployment components are analyzed. Based on the personalized attributes of the components, multi-dimensional local simulated deployment verification scenarios are dynamically generated, covering normal operation scenarios, resource limit scenarios, and abnormal triggering scenarios. Simulated deployment and deep verification of the components are performed step-by-step according to the scenarios, recording the component's operating data and adaptation performance in different scenarios. After completing full-scenario verification, the component's qualification is comprehensively determined. If the verification passes, a customized solidification scheme is developed based on the component's functional characteristics, locking the core configuration of the component and adding scenario adaptation instructions and version identifiers. Subsequently, the solidified component is pushed to the corresponding category area in the component library, completing the detailed information registration and retrieval tag configuration of the component, generating a callable deployment component. This method provides comprehensive verification scenarios and strong adaptability, meeting the verification needs of personalized components and improving the diversity and adaptation accuracy of components in the component library.

[0112] For example, in a project deployment scenario, an interactive request is created based on the Redis application component. The submitted deployment steps, resource requirements, and operational constraints are parsed to obtain core deployment elements containing three categories of core content. Based on these core deployment elements, a pre-formatted component encapsulation framework is constructed, comprising five functional modules: basic configuration, operational monitoring, and exception handling. The core deployment elements are integrated into the corresponding positions within the framework according to their functional modules. The startup order, dependency-related call logic and timeout times, and resource quota adaptation parameters between elements are configured to obtain the initial deployment component. A local simulated deployment verification model is used to perform 10 rounds of full-process verification on the initial deployment component. After a 100% pass rate, the component is solidified, a version identifier V1.0 is added, and it is pushed to the enterprise-level component library, generating a callable Redis deployment component.

[0113] By standardizing the process of element analysis, framework construction, integration configuration, and verification and database entry, the problems of unstandardized component creation, insufficient verification, and low reusability have been solved, thereby improving the standardization of components and the efficiency of component invocation in project deployment.

[0114] Based on any of the above embodiments, in Embodiment Six of this application, step D14 includes steps E11 to E13: Step E11 involves performing a local simulation deployment verification process on the initial deployment component to check the integrity of the calling logic, the rationality of parameter adaptation, and the compatibility of functional modules of the core deployment elements, and generating a component verification failure report.

[0115] In this embodiment, call logic integrity refers to the completeness of the call association rules between core deployment elements. Parameter fit rationality refers to the degree to which the fit parameters match the component's operational requirements. Functional module compatibility refers to the degree of compatibility between functional modules during collaborative operation. The component validation failure report is a standardized document that records the non-compliant items in component validation and the analysis of the problems.

[0116] As an optional implementation, the initial deployment components are obtained, and a pre-defined standardized verification rule set is invoked. Following the fixed verification dimensions within this set, the completeness of the core deployment element's calling logic, the compliance of parameter adaptation with basic standards, and the presence of significant conflicts between functional modules are checked sequentially. Non-compliant items at each verification stage are recorded, along with the problem type and basic location information, and integrated into a concise component verification failure report. This method features a simple verification process, high execution efficiency, and the ability to quickly locate fundamental issues, providing a basis for rectifying problems in routine components.

[0117] As an alternative implementation, this method analyzes the functional architecture of the initial deployment components and the correlation characteristics of the core deployment elements to dynamically generate a multi-dimensional verification framework. This framework covers verification aspects such as the integrity of the call logic chain, parameter adaptation to scenario compatibility, and deep collaborative compatibility of functional modules. A full-process local simulation deployment verification is performed, tracking the operational trajectory of the core deployment elements, accurately locating the root causes of non-compliance items, recording the problem manifestations, related elements, and scope of impact, supplementing targeted rectification suggestions, and integrating them into a detailed component verification failure report. This method offers comprehensive verification dimensions, accurate problem location, and can identify hidden and complex faults. It can output verification failure reports that include both problem details and rectification directions, providing comprehensive support for the precise rectification of complex components.

[0118] Step E12: Based on the component verification failure report, locate the logical conflict points, parameter mismatches, and module connection vulnerabilities in the core deployment elements, and adjust the calling logic rules, correct the adaptation parameter values, and supplement the module association interfaces accordingly to obtain the optimized initial deployment component.

[0119] In this embodiment, logical conflict points are contradictions or breakpoints in the core element deployment call logic. Parameter mismatches are entries where the adapted parameter values ​​do not match the component's operational requirements. Module connection loopholes are missing or defective interactions between functional modules. Call logic rules are the call association criteria between core elements. Adapted parameter values ​​are parameter values ​​that ensure the coordinated operation of elements. Module association interfaces are the channels through which functional modules achieve data interaction and calls. The optimized initial deployment component is the basic component unit after the problem rectification is completed.

[0120] As an optional implementation, a component validation failure report is obtained, and a list of logical conflicts, parameter mismatches, and module connection vulnerabilities recorded in the report is extracted. A pre-defined standardized problem rectification rule set is invoked, and according to the fixed adjustment scheme in this set, the specific location of various problems in the core deployment elements is identified in batches. Conflicting call logic rules are uniformly adjusted, adaptation parameter values ​​deviating from standard values ​​are corrected, and general module association interfaces are supplemented. After rectification, basic validation is performed to confirm that the problems have been eliminated, resulting in an optimized initial deployment component. This method has a high degree of standardization in the rectification process, fast execution efficiency, and can quickly resolve common problems.

[0121] As an alternative implementation method, the detailed content of component validation failure reports is analyzed to uncover the root causes of various problems. Combining the functional attributes of core deployment elements with the subsequent application requirements of the component, the core contradictions of logical conflicts, the reasons for parameter mismatches, and the key deficiencies in module connections are identified one by one. Customized rectification strategies are then implemented, adjusting the priority and execution path of calling logic rules, correcting adaptation parameter values ​​to accurately match operational requirements, and supplementing customized module association interfaces to achieve deep module integration. After rectification, multi-dimensional validation is initiated to verify the rectification effect and the overall compatibility of the component. Residual issues are optimized and adjusted to obtain an optimized initial deployment component. This method offers high rectification accuracy, can solve complex and personalized problems, significantly optimizes components, and improves the component's operational stability and adaptability to diverse scenarios.

[0122] Step E13: Perform the simulated deployment verification process again on the optimized initial deployment component until all verification items meet the preset standards, and generate the deployment component.

[0123] In this embodiment, the simulated deployment verification process is a component functionality and compatibility verification operation conducted locally in a simulated actual deployment environment. Verification items are specific checkpoints used to measure whether a component meets deployment requirements. Preset standards are pre-defined criteria for determining whether a component passes verification.

[0124] As an optional implementation, the optimized initial deployment component is obtained, and a pre-defined standardized simulation deployment verification rule set is invoked. Following the fixed verification items and judgment criteria in this set, the component's simulated installation, runtime triggering, and functional verification are executed round by round. Non-compliant items in each round are recorded and fed back to the rectification phase. After rectification, the same verification process is repeated until all verification items meet the pre-defined standards. Then, the component's structure and configuration parameters are locked, generating a standardized deployment component. This method features a unified and standardized verification process, high execution efficiency, and can quickly advance component compliance and deployment, ensuring efficient component invocation in routine projects.

[0125] As an alternative implementation method, the functional architecture and adaptation features of the optimized initial deployment components are analyzed. Extended verification dimensions are dynamically generated based on the components' personalized attributes, supplementing potential risk points not covered by conventional verification items. Full-dimensional simulated deployment verification is performed round by round, not only checking the basic functional compliance of the components but also analyzing their stability and compatibility under extreme operating scenarios. Customized rectification plans are developed for issues discovered in each round of verification, and deep verification is performed again after rectification until all basic and extended verification items meet preset standards. Adaptation scenario identifiers are then added based on component characteristics to generate high-quality deployment components. This method offers comprehensive verification dimensions and strict component quality control, avoiding hidden faults in complex scenarios and improving the reliability of complex project deployments.

[0126] For example, in a project deployment scenario, a local simulated deployment verification process is performed on the initial deployment component. A multi-dimensional component verification model is used to detect the integrity of the call logic, the rationality of parameter adaptation, and the compatibility of functional modules in the core elements of the deployment. Two call logic breakpoints, three parameter mismatches, and one module connection vulnerability are detected, generating a component verification failure report containing the problem location, type, and basic analysis. Based on this report, the conflict points between the startup logic and dependency loading logic, the mismatch between memory quota parameters and runtime requirements, and the connection vulnerability between the data transmission module and the monitoring module in the core elements of the deployment are located. The call logic execution order rules are adjusted accordingly, the memory quota parameter value is corrected from 2GB to 4GB, and RESTful module association interfaces are added, resulting in an optimized initial deployment component. The optimized initial deployment component is then subjected to a simulated deployment verification process again. After three rounds of verification, all 12 verification items meet the preset standards, generating a callable deployment component.

[0127] By employing a closed-loop process of verification, location optimization, and iterative verification, the problems of inaccurate troubleshooting and incomplete rectification of deployment component issues have been resolved, thereby improving the stability and adaptability of deployment components and ensuring the smooth deployment of subsequent projects.

[0128] Based on any of the above embodiments, in Embodiment Seven of this application, referring to Figure 3 , Figure 3 This is a flowchart illustrating the seventh embodiment of the automated deployment method for the standardized project of this application. Following step S50, steps F11-F13 are also included: Step F11: Automatically aggregate the target projects that have passed verification in the development environment, package the dependencies of the verified target projects, and generate an offline deployment package for the projects.

[0129] In this embodiment, the development environment is a dedicated, standardized environment adapted for project deployment and operation. The verified target project is a deployable project that has completed all functional, compatibility, and parameter adaptation verifications and whose results meet preset standards. Automatic aggregation processing is the operation of automatically collecting and organizing project-related files and resources according to preset rules. Dependencies are the various components, configurations, and resource files required to support the normal operation of the target project. The offline deployment package is a compressed file package that integrates the target project itself and all its dependencies, and can be deployed in an offline environment.

[0130] As an optional implementation, the target project, validated in the development environment, is retrieved. A pre-defined standardized automatic aggregation rule set is invoked. Following the fixed file classification standards and path specifications within this rule set, all files in the project directory are automatically scanned, and the project entity files, configuration files, and various dependencies are aggregated into a pre-defined directory structure. After aggregation, a standardized packaging process is initiated, integrating and compressing all aggregated content to generate a uniformly structured offline deployment package. Simultaneously, the package's file list and basic deployment instructions are recorded. This method offers a high degree of standardization and fast execution efficiency in its aggregation and packaging process, ensuring the uniformity and standardization of the offline package and meeting the needs of typical offline deployment scenarios.

[0131] As an alternative implementation, a dependency identification and tagging process is first initiated for the target project. During the automatic aggregation process, each valid dependency is verified one by one, and the version information and upstream and downstream dependency hierarchy are tagged for each dependency to obtain the verified target projects. Then, a structured dependency version mapping table is constructed based on this tagging information to complete the classification, aggregation, and orderly storage of dependencies, avoiding the chaotic accumulation of dependencies. When the verified target project needs to be updated to generate a new offline deployment package, the historically retained old dependency version mapping table is retrieved and compared with the dependency scan results of the new version project item by item to identify incrementally added, version-itemized, and invalidated dependencies. Only incrementally added and version-itemized dependencies are automatically aggregated and packaged, and the generated incremental offline package is assigned a unique identifier and associated with the original base offline package to ensure that the two can automatically match and seamlessly integrate during the deployment process. In addition, the dependency version traceability function is embedded in the final generated offline deployment package. During the automatic collection and packaging process, information such as the source channel, collection time, and packaging parameters of the dependencies are entered into the dependency version mapping table. Whether it is package body verification before deployment, anomaly investigation during deployment, or audit traceability after deployment, the mapping table can be retrieved at any time to clearly view the complete information of each dependency and the history of each change, realizing full-link traceability of the offline deployment package from dependency collection to final deployment.

[0132] Step F12: The offline deployment package of the project is transmitted to a designated storage location in the user's production environment that is isolated from the development network via a preset online transmission medium, and the deployment package environment migration confirmation result is obtained.

[0133] In this embodiment, the preset wired transmission medium is a pre-configured wired data transmission carrier. The user production environment with network isolation is the user's actual business operation environment that is physically or logically isolated from the development side network. The deployment package environment migration confirmation result is feedback information recording the deployment package transmission status, integrity, and storage location accuracy.

[0134] As an optional implementation, a pre-defined standardized transmission medium is invoked, a pre-configured fixed transmission protocol and channel are activated, the basic identification information of the project's offline deployment package is read, and the deployment package is transmitted to a designated storage location in the user's production environment according to a pre-defined path. After transmission, integrity verification and storage path matching verification of the deployment package are performed to check whether the package size is consistent with the preset value and whether the storage location meets the defined requirements. After verification, a deployment package environment migration confirmation result containing a transmission success identifier and storage location information is generated. This method has a high degree of standardization in the transmission process and fast execution efficiency, which can quickly complete the environment migration of regular deployment packages and ensure the efficiency of basic business deployment.

[0135] As an alternative implementation, the specifications and transmission priority requirements of the offline deployment package are analyzed. A suitable transmission medium and protocol are dynamically matched from a preset online transmission medium. A fragmented transmission strategy is used for large deployment packages, and a dedicated transmission channel is used for high-priority deployment packages. The deployment package is transmitted to the user's designated storage location in the production environment in fragmented or complete package form. After transmission, multi-dimensional verification is performed, checking not only the integrity of the deployment package and the accuracy of the storage location, but also the system compatibility between the package and the production environment. Detailed explanations are generated for verification anomalies, and finally, a deployment package environment migration confirmation result is generated, including transmission status, verification results, and anomaly explanations. This method is highly adaptable and can meet the migration needs of deployment packages of different specifications and priorities, improving the reliability of deployment package migration in complex business scenarios.

[0136] As an alternative implementation, when migrating project offline deployment packages to a designated storage location in the isolated user's production environment via a preset online transmission medium, the entire transmission process is divided into three layers: a basic package transmission layer, an incremental package transmission layer, and a verification and confirmation layer. Taking advantage of the split nature of the basic and incremental packages in the offline deployment, transmission is initiated sequentially according to these three layers: First, the basic package transmission is completed. After transmission, a transmission snapshot for that layer is automatically generated, recording the transmission duration, package body checksum, storage path, and core information of the transmission medium status. Next, incremental package layered transmission is performed. The transmission snapshot is updated after each incremental package transmission, supplementing the associated binding information of the incremental package. Finally, the verification and confirmation layer is entered, where the integrity and accuracy of the package bodies transmitted at each layer are verified. When an anomaly occurs during transmission, the transmission layer to which the anomaly belongs is automatically located. Instead of retransmitting the entire deployment package, precise retransmission is initiated only for the package body of the anomaly layer. Simultaneously, the current transmission status is compared with the corresponding layer's transmission snapshot to generate a transmission difference adjustment log, clarifying the cause of the anomaly, the scope of retransmission, and the repair results. Once the entire transfer is complete, the generated deployment package environment migration confirmation result will synchronously include snapshot information for each transfer layer, difference adjustment logs, and the final verification conclusion, ensuring that the migration process is traceable and that anomaly handling is accurate and efficient. This method features layered control of the transfer process, construction of layered transfer snapshots, and precise retransmission at the anomaly level.

[0137] Step F13: Based on the environment migration confirmation result of the deployment package, the executable file is self-extracted on the target server, and the deployment commands and parameters that are completely consistent with the local verification are called to execute the automated deployment task, so as to complete the closed loop of the entire offline deployment process.

[0138] In this embodiment, the target server is the server device in the user's production environment that hosts the deployment task. The self-extracting executable file is a deployment package associated file with automatic decompression functionality. The deployment commands and parameters completely identical to those used in local verification are the same deployment instructions and configuration parameters used during local simulated deployment verification. The automated deployment task is a process that automatically completes the decompression of the deployment package, configuration loading, and startup. The offline deployment process loop is a complete closed loop from deployment package migration to final deployment completion.

[0139] As an optional implementation, after obtaining the deployment package environment migration confirmation result and confirming that the deployment package has been transmitted completely and stored in the correct location, the startup command of the self-extracting executable file on the target server is triggered. The deployment package content is automatically decompressed and its directory is organized according to preset decompression rules. Pre-stored deployment commands and parameter sets that are completely consistent with local verification are directly retrieved. A standardized automated deployment task is started, sequentially executing the processes of configuration loading, component installation, and service startup. After deployment is complete, basic deployment status information is output, completing the offline deployment process loop. This method has a high degree of standardization, fast execution efficiency, and good adaptability to common deployment scenarios. It can quickly complete the closed loop of common offline deployments, ensuring the efficiency and consistency of basic deployment scenarios.

[0140] As an alternative implementation, the target server environment characteristic information in the deployment package environment migration confirmation result is parsed. Based on the environment characteristics, the decompression strategy of the self-extracting executable file is dynamically adjusted, and the decompression path and permission configuration are set to adapt to the target server system. After the deployment package is accurately decompressed, the deployment commands and parameter set that are completely consistent with the local verification are retrieved, and the parameters are adaptively calibrated in combination with the target environment characteristics. A customized automated deployment task is started, and the running status of each stage is monitored in real time during the deployment process. An emergency adjustment mechanism is triggered for potential environment adaptation issues. After deployment is completed, the consistency verification between the deployment result and the local verification result is performed, and a detailed deployment report is output, completing the offline deployment process loop. This method has strong environment adaptability, can cope with the special environmental differences of the target server, has high deployment reliability, ensures that the deployment result is consistent with the local verification, and improves the stability and adaptation accuracy of offline deployment.

[0141] For example, in a project deployment scenario, verified distributed service target projects are automatically aggregated. The project entity, six types of core dependency components, and associated configuration files are categorized by project modules and dependency types. All dependency content is packaged and compressed using a layered compression strategy to generate an offline deployment package with an integrity checksum. The offline deployment package is transmitted to a designated storage directory in the user's production environment, isolated from the development network, via a pre-set encrypted wired transmission medium. Dual verification of package size and checksum is performed, achieving a 100% pass rate, thus obtaining a deployment package environment migration confirmation result. Based on this confirmation result, a self-extracting executable file is triggered on the target server, calling deployment commands and parameters identical to those used in local verification to execute an automated deployment task. This sequentially completes component installation, configuration loading, and service startup, thus completing the entire offline deployment process loop.

[0142] By adopting a standardized closed-loop process of aggregation and packaging, encrypted transmission, and consistent deployment, the problems of missing dependencies in offline deployment, inconsistent parameters in cross-environment deployment, and fragmented deployment process are solved, thereby improving the efficiency and consistency of offline deployment.

[0143] Based on any of the above embodiments, in Embodiment Eight of this application, referring to Figure 4 , Figure 4 This is a flowchart illustrating the eighth embodiment of the automated deployment method for the standardized project of this application. Following step S50, steps G11-G13 are also included: Step G11: In response to the user-triggered infrastructure resource request command, generate a code file describing the cloud host resource requirements based on the configuration file of the target project, and create a corresponding code merging request.

[0144] In this embodiment, the user-triggered infrastructure resource request command is an instruction initiated by the user to request the infrastructure resources required for project deployment. The cloud server resource requirement code file is a programmatic file describing the specifications, quantity, and other requirements of the cloud servers supporting the project's operation. The code merge request is a standardized request to merge the newly created cloud server resource requirement code file into a specified code repository.

[0145] As an optional implementation, this method obtains the infrastructure resource request command triggered by the user and extracts the target project identifier and personalized cloud server resource requirement supplementary description from the command. It then deeply analyzes the target project's configuration file to uncover the core requirements, extended requirements, and implicit operational constraints of the cloud server resources. Based on the analysis results, it dynamically generates a personalized code structure and field configuration, filling in precise resource requirement information to generate a cloud server resource requirement code file containing personalized configuration items. Subsequently, based on the code file's functional attributes, merging priority, and potential risks, it fills in detailed code descriptions, merging adaptation suggestions, and risk assessment reports, creating a customized code merging request. This method is highly adaptable, can meet complex personalized cloud server resource requirements, and has high accuracy in both code and request, improving the success rate and adaptation accuracy of infrastructure resource requests for complex projects.

[0146] Step G12: After the code merge request is approved, the code files are merged according to the trunk branch merging specification and the automatic code conflict resolution mechanism to obtain the final code file.

[0147] In this embodiment, the trunk branch merging specification refers to the pre-defined code merging process, format, and quality assessment standards. The automatic code conflict resolution mechanism is a programmatic mechanism that automatically identifies and resolves overlapping contradictions between code. The code file is a programmatic file describing the resource requirements of the cloud host. The final code file is a standardized code file that can be used for subsequent resource requests after merging and conflict resolution are completed.

[0148] As an optional implementation, this method obtains approved code merge requests and extracts the corresponding code files and target branch information. It then invokes the fixed processes and format requirements of the preset branch merge specifications, performing code file format verification and branch compatibility pre-checks. Subsequently, an automatic basic code conflict resolution mechanism is activated to identify and handle simple conflicts at the syntax and field overlap levels, automatically resolving conflicts using preset priority rules. After completion, a merge integrity check is performed, and upon confirmation of compliance with specifications, a final code file with a unified structure is generated. This method features a standardized merge process, high execution efficiency, and can quickly complete routine code merges, ensuring the basic progress efficiency of infrastructure resource applications.

[0149] As an alternative implementation, the method obtains approved code merge requests, deeply analyzes the functional logic of the code files and their relationship with existing code in the main branch, dynamically adapts to the extended process of the main branch merging specification, and supplements logical compatibility checks. Subsequently, an enhanced automatic code conflict resolution mechanism is activated to handle simple syntax field conflicts, resolve complex conflicts at the logical association and dependency constraint levels, and adopt differentiated resolution strategies for different conflicts. After merging, multi-dimensional verification is performed to optimize potential conflicts and generate a logically complete final code file. This method has strong conflict resolution capabilities and high merging accuracy, can meet the needs of complex code merging, and improves the success rate and adaptation accuracy of subsequent resource requests.

[0150] Step G13 triggers the continuous integration deployment pipeline, calls the final code file to execute the resource creation task, and completes the automated deployment of cloud host resources according to the requirements described in the code.

[0151] In this embodiment, the continuous integration deployment pipeline is a pre-configured automated process chain that completes code execution, resource creation, and deployment. The resource creation task is an automated task that creates corresponding cloud server resources based on the code file description. Cloud server resource requirements are the specifications, quantity, and other requirements of the cloud servers needed to support the target project's operation.

[0152] As an optional implementation, the final code file is obtained, triggering a pre-defined standardized continuous integration deployment pipeline. Following the fixed execution steps in the pipeline, the final code file is sequentially called for syntax validation and resource requirement parsing. A standardized resource creation task is then initiated, automatically executing the specification configuration, quantity creation, and basic network deployment of cloud hosts according to the basic requirements described in the code. Upon completion, a simple check of resource readiness is performed; after confirming that the resources meet the basic requirements, the automated deployment of cloud host resources is completed. This method features a standardized process, high execution efficiency, good adaptability to common cloud host requirements, and ensures the basic efficiency and standardization of infrastructure resource supply.

[0153] As an alternative implementation, the complex resource requirements and constraints described in the final code file are parsed, triggering a dynamically adjustable continuous integration deployment pipeline. This pipeline adapts to new requirements by adding extended steps such as resource dependency verification and cross-regional coordination. The final code file is called for full-dimensional parsing and logical verification, initiating a customized resource creation task. This automatically executes cloud host specification customization, cross-regional deployment, dedicated network configuration, and resource association binding, with real-time monitoring and anomaly handling during deployment. Upon completion, multi-dimensional adaptability verification is performed, configuration details are optimized, and the automated deployment of cloud host resources is achieved. This method offers strong adaptability and high deployment accuracy, meeting complex and personalized needs. It can complete high-quality deployment of complex cloud hosts, improving the resource adaptability and stability for complex projects.

[0154] For example, in a project deployment scenario, in response to a user-triggered infrastructure resource request command, based on the configuration file of the distributed target project, the cloud resource code generation model is invoked to extract requirements such as 8-core 16G specifications, 5 units, and dedicated subnet binding. This generates a cloud host resource requirement code file conforming to Infrastructure as Code syntax. Information such as the target trunk branch to be merged and code function descriptions are filled in, and a corresponding code merge request is created. After the code merge request passes review (100% pass rate), two overlapping code conflicts are resolved according to the trunk branch merging specifications and the automatic code conflict resolution mechanism. The code file is then merged to obtain the final code file. The continuous integration deployment pipeline is triggered, invoking the final code file to execute resource creation tasks. This sequentially completes cloud host specification configuration, network binding, and system initialization, taking 25 minutes. Based on the requirements described in the code, the automated deployment of 5 cloud host resources is completed, achieving a 100% resource readiness rate.

[0155] By standardizing the application generation, code merging, and pipeline deployment processes, the problems of non-standard cloud host resource applications, inefficient code conflict handling, and manual deployment processes have been solved, thereby improving the efficiency and standardization of automated provisioning of cloud resources required for project deployment.

[0156] Based on any of the above embodiments, in Embodiment Nine of this application, referring to Figure 5 , Figure 5 This is a system framework diagram for this application. The automated deployment method for standardized projects is applied to the automated deployment system, which includes a unified command-line interface module, an environment management module, a project template and generation module, an automated orchestration and execution module, an offline deployment and packaging module, and an infrastructure as code management module.

[0157] As an optional implementation, a modular deployment combination command is input through a unified command-line interface module. The desired functional modules and corresponding execution strategies are selected, triggering the environment management module to load and configure the corresponding versions of dependent software based on the selected modules' dependency requirements, skipping the initialization process of unnecessary dependencies. Subsequently, the project template and generation module is invoked, selecting and combining "component templates" and "site templates" adapted to the current deployment scenario from the template library to generate a project framework containing a hybrid directory structure and adaptation configuration files. Next, the automated orchestration and execution module dynamically filters and concatenates the execution logic of the corresponding "Role" components based on the template combination results, adjusting the parallel / serial execution strategy of the tasks. Then, the offline deployment and packaging module scans the project's core and optional dependencies based on the dependency scope of the selected modules, packaging the core dependencies into a basic self-executing package and the optional dependencies into additional packages. Finally, the infrastructure-as-code management module, combined with the selected resource type, generates lightweight infrastructure code adapted to a single cloud platform, simplifying the approval process by retaining only core node verification, and completing code submission and merging. This method balances process flexibility and execution efficiency, allowing for the combination of module functions as needed, avoiding redundant operations, and meeting a certain degree of personalized needs while ensuring deployment efficiency, thus balancing the deployment costs of standardization and customization.

[0158] As an alternative implementation, the "layered deployment" command is input through the unified command-line interface module, triggering the environment management module to first complete the full dependency initialization of the local development environment, and then configure differentiated dependency versions in batches according to the layer of the remote target host (e.g., test layer, pre-release layer, production layer). Subsequently, the project template and generation module is invoked to generate multiple project frameworks with environment isolation configurations according to the layer, each framework corresponding to different layer deployment rules and test cases. Next, the automated orchestration and execution module executes deployment tasks sequentially according to the layer order, first completing the deployment and verification of the test layer, synchronizing the verification results to the pre-release layer framework and adjusting the configuration, and then executing the pre-release layer deployment. Finally, based on the verification data from the first two layers, the "Role" component calling logic of the production layer is optimized, and the offline deployment and packaging module generates corresponding offline packages according to the layer, adding multiple integrity checks and encryption mechanisms to the production layer packages. Finally, the infrastructure-as-code management module generates infrastructure code of different specifications according to the layer, with temporary resource configurations used for the test layer code, high availability constraints added to the production layer code, and multi-level approval processes configured for the production layer code. This method offers controllable deployment risks. By employing layered verification, it reduces the probability of production environment failures, achieves layered risk management during the deployment process, and enhances the reliability of production environment deployment.

[0159] For example, in a project deployment scenario, the unified command-line interface (CLI) module serves as the sole entry point for users to interact with the system. It encapsulates complex low-level operations into simple, workflow-oriented commands (such as `jetdev site create`, `jetdev role create`, `jetdev site component`, packaging commands, `jetdev terraform apply`, etc.). The environment management module is responsible for the automated initialization of the local development environment and remote target hosts. It can install and configure all necessary dependent software (such as Ansible, Python, Terraform, GitLab-Runner, etc.) with one click, ensuring that all team members have a standardized working environment. The project template and generation module includes standardized project templates, such as "Role" templates for defining deployment units and "Site" templates for managing specific deployment environments. Users can quickly generate project frameworks containing standard directory structures, configuration files, test cases, and continuous integration / continuous deployment (CI / CD) scripts via commands. The automation orchestration and execution module, based on Ansible, executes specific automated deployment tasks. It parses the configurations in the "Site" project, calls the corresponding "Role" components, and completes the configuration and deployment on the target server. The offline deployment packaging module, a key innovation of the system, scans all dependencies of the "Site" project, including code, AnsibleRole, configuration files, scripts, etc., and packages them into a single self-extracting, self-executing file. This file can be run directly in the target production environment without a network connection, performing deployment operations completely identical to those used during local verification. The Infrastructure as Code (IaC) management module is deeply integrated with Terraform and its Provider, abstracting infrastructure resources (virtual machines, networks, security groups, etc.) of multi-cloud platforms into code. At the same time, it combines Git's version control and merge request mechanism to automate, versionize, and streamline the approval process for infrastructure application, modification, and release.

[0160] By implementing an automated deployment process with interconnected modules, the problems of inconsistent project deployment dependencies, fragmented manual processes, and poor offline deployment compatibility have been solved, thereby improving project deployment efficiency and environmental consistency, and reducing the operational costs of cross-scenario deployment.

[0161] This application provides an automated deployment device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the automated deployment method of the standardized project in Embodiment 1 above.

[0162] The following is for reference. Figure 6 The diagram illustrates a structural schematic suitable for implementing the automated deployment device of the embodiments of this application. The automated deployment device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, test servers, personal digital assistants (PDAs), tablet computers (PADs), portable media players (PMPs), deployment execution core devices, etc., as well as fixed terminals such as automated deployment servers, desktop computers, etc. Figure 6 The automated deployment device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0163] like Figure 6As shown, the automated deployment device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the automated deployment device. The processing unit 1001, the ROM 1002, and the RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the automated deployment equipment to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows automated deployment equipment with various systems, it should be understood that implementing or having all of the systems shown is not required. More or fewer systems may be implemented alternatively.

[0164] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0165] The automated deployment device provided in this application, employing the automated deployment method for standardized projects in the above embodiments, can solve the technical problem of low project deployment efficiency. Compared with the prior art, the beneficial effects of the automated deployment device provided in this application are the same as those of the automated deployment method for standardized projects provided in the above embodiments, and other technical features of the automated deployment device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0166] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0167] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0168] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the automated deployment method of the standardized project in the above embodiments.

[0169] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0170] The aforementioned computer-readable storage medium may be included in the automated deployment device; or it may exist independently and not be assembled into the automated deployment device.

[0171] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by an automated deployment device, the automated deployment device: responds to a project deployment request by invoking the target executable file corresponding to the project deployment request; constructs a target development environment based on the target device's operating parameters and the dependent tools of the target executable file; constructs a deployment project corresponding to the project template in the target development environment according to the project template determined in the project creation request; invokes the corresponding deployment component based on the target executable file, adds the dependencies of the application components in the deployment component to the corresponding directory of the deployment project, and obtains a configuration file; configures the parameters of the application components according to the configuration file, and obtains the deployed target project.

[0172] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0173] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0174] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0175] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the automated deployment method of the aforementioned standardized project, thereby solving the technical problem of low project deployment efficiency. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the automated deployment method of the standardized project provided in the above embodiments, and will not be repeated here.

[0176] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for automated deployment of standardized projects, characterized in that, The method comprises: in response to a project deployment request, calling a target execution file corresponding to the project deployment request; based on the running parameters of the target device and the dependent tools of the target execution file, constructing a target development environment; according to the project template determined in the project creation request, constructing a deployment project corresponding to the project template in the target development environment; based on the target execution file, calling a corresponding deployment component, adding the dependency relationship of an application component in the deployment component to the corresponding directory of the deployment project to obtain a configuration file; according to the configuration file, configuring the parameters of the application component to obtain a deployed target project.

2. The method for automated deployment of standardized projects of claim 1, wherein, The step of constructing a target development environment based on the running parameters of the target device and the dependent tools of the target execution file comprises: detecting the running parameters of the target device and the dependent tools of the target execution file to determine the currently missing dependent tool information of the target device; according to the currently missing dependent tool information, pulling the corresponding missing dependent tools from a preset tool library and deploying the dependent tools to a specified directory of the target device to obtain a dependent tool deployment result; based on the dependent tool deployment result and the dependent tool parameter set in the target execution file, configuring the parameters of the deployed dependent tools to obtain a target dependent tool, and determining the environment configuration parameters of the development environment through a development environment standardization configuration template; constructing the target development environment according to the target dependent tool and the environment configuration parameters.

3. The method for automated deployment of standardized projects of claim 1, wherein, The step of constructing a deployment project corresponding to the project template in the target development environment according to the project template determined in the project creation request comprises: in response to the project creation request, parsing the project template determined in the project creation request to obtain a template analysis result containing directory hierarchy, preset configuration file template and file storage rule; based on the template analysis result, creating a directory structure of corresponding hierarchy under a specified path of the target development environment, and setting an initial configuration file, a host inventory storage file and a to-be-deployed component list file in the directory structure to obtain an initial deployment project framework; initializing the corresponding project as a version control repository under the root directory of the initial deployment project framework, and configuring the association information between the version control repository and a remote repository to obtain the deployment project.

4. The method for automated deployment of standardized projects of claim 1, wherein, The step of obtaining a configuration file based on the target execution file calling a corresponding deployment component and adding the dependency relationship of an application component in the deployment component to the corresponding directory of the deployment project comprises: based on the target execution file, locating and calling the deployment component corresponding to the deployment project from a component library; writing the dependency relationship of the application component in the deployment component to a specified position in the deployment project, and verifying the compatibility of the dependency relationship with the existing configuration of the deployment project to obtain a compatibility report; according to the compatibility report and a preset parameter configuration template, filtering and assigning the parameters of the application component that adapt to the running parameters of the target device to generate a parameter configuration set of the application component; establish a calling association relationship between the application component and the deployment project based on the parameter configuration set of the application component; add the parameter configuration set and the calling association relationship to the corresponding directory of the deployment project, to obtain the configuration file.

5. The method for automated deployment of standardized projects of claim 1, wherein, Before the step of calling the deployment component corresponding to the target execution file, the automatic deployment method of the standardized project further includes: based on the component creation interaction request, parse the submitted application component deployment related configuration information to obtain the deployment core element; construct a component packaging framework in a preset format according to the deployment core element; integrate the deployment core element to the corresponding position of the component packaging framework according to the function module classification set, and configure the calling logic and adaptation parameters between the deployment core elements, to obtain an initial deployment component; perform a local simulation deployment verification process on the initial deployment component, and after verification, solidify the initial deployment component and push it to the component library to generate a callable deployment component.

6. The method for automated deployment of standardized projects of claim 5, wherein, The step of performing a local simulation deployment verification process on the initial deployment component, and after verification, solidifying the initial deployment component and pushing it to the component library to generate a callable deployment component includes: perform a local simulation deployment verification process on the initial deployment component, and detect the calling logic integrity, parameter adaptation rationality and function module compatibility of the deployment core element to generate a component verification failure report; based on the component verification failure report, locate the logical conflict points, parameter mismatch items and module connection vulnerabilities existing in the deployment core element, and adjust the calling logic rules, correct the adaptation parameter values and supplement the module associated interfaces to obtain an optimized initial deployment component; perform a simulation deployment verification process on the optimized initial deployment component again until all verification items meet the preset standard to generate the deployment component.

7. The method for automated deployment of standardized projects of claim 1, wherein, After the step of configuring the parameters of the application component according to the configuration file to obtain the deployed target project, the automatic deployment method of the standardized project further includes: perform automatic collection processing on the target project verified in the development environment, package the dependent content of the target project verified to generate a project offline deployment package; transmit the project offline deployment package to a specified storage location of a user production environment isolated from the development network through a preset line transmission medium to obtain a deployment package environment migration confirmation result; based on the deployment package environment migration confirmation result, self-decompress executable files on the target server, and call the deployment command and parameters consistent with the local verification to execute an automatic deployment task to complete the entire offline deployment process closed loop.

8. The method for automated deployment of standardized projects of claim 1, wherein, After the step of configuring the parameters of the application component according to the configuration file to obtain the deployed target project, the automatic deployment method of the standardized project further includes: in response to a user triggered infrastructure resource application command, generate a code file describing cloud host resource requirements according to the configuration file of the target project, and create a corresponding code merging request; After the code merging request is passed, the code files are merged according to the trunk branch merging specification and the code conflict automatic resolution mechanism to obtain code final files; Triggering a continuous integration and deployment pipeline, calling the code final files to perform a resource creation task, and automatically deploying cloud host resources according to requirements described by the code.

9. An automated deployment device, characterized by The automatic deployment device comprises a memory, a processor, and a computer program stored on the memory and executable on the processor, and the computer program is configured to implement the steps of the standardized project automatic deployment method according to any one of claims 1 to 8.

10. A storage medium, characterized by The storage medium is a computer readable storage medium, and the storage medium stores a computer program. When the computer program is executed by the processor, the steps of the standardized project automatic deployment method according to any one of claims 1 to 8 are implemented.

Images