Automatic test environment deployment method and device, computer equipment and medium

Abstract

The invention relates to a test environment automatic deployment method and device, computer equipment and a medium, and the method comprises the steps: obtaining a target environment identifier of a to-be-deployed environment; target environment parameters and a target database corresponding to the target environment are queried based on a pre-constructed four-level data model, a service-parameter mapping table is generated according to the target environment parameters, and the four-level data model is constructed according to an environment table, a service table, a parameter table and a dependency table; according to the service-parameter mapping table, obtaining a template configuration file corresponding to the service from a preset configuration library, and filling the target environment parameters into the template configuration file to generate a target configuration file; based on the target configuration file, synchronizing data in a preset standard database to the target database; all services corresponding to the target environment are restarted, and automatic deployment of the test environment is completed.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, computer equipment, storage medium, and computer program product for automated deployment of a test environment. Background Technology

[0002] In today's rapidly iterating development of computer applications and software, significantly shortened early-stage iteration cycles for new projects have become a common trend. To ensure software quality, it is necessary to switch testing environments quickly and frequently to support various testing and verification tasks. At the same time, due to the significant differences in testing requirements across different development stages and functional modules, it is often necessary to equip multiple development and testing personnel or teams with independent testing environments, which dramatically increases the workload of operations and maintenance.

[0003] Currently, traditional test environment deployment technologies have significant shortcomings in automation. They only automate a partial process of "parameter loading - service deployment." In the configuration file processing stage, manual replacement of placeholders still relies on manual intervention. For complex application configuration files, manual operation is not only inefficient but also prone to errors due to oversight. Similarly, database synchronization requires manually writing and executing SQL scripts, a time-consuming and labor-intensive process that makes it difficult to guarantee the accuracy and timeliness of test environment deployment.

[0004] High-frequency iteration computer application projects typically require multiple environment switches per day. However, due to the limited automation of traditional test environment deployment technologies, the total time spent on a single environment switch remains high, far from meeting the needs of high-frequency iteration. Therefore, there is a growing demand for an efficient and accurate automated test environment deployment solution. Summary of the Invention

[0005] Therefore, it is necessary to provide an efficient and accurate method, apparatus, computer equipment, computer-readable storage medium, and computer program product for the automated deployment of a testing environment to address the aforementioned technical problems.

[0006] Firstly, this application provides a method for automated deployment of a test environment. The method includes:

[0007] Obtain the target environment identifier for the environment to be deployed;

[0008] Based on the pre-built four-level data model, the target environment parameters and target database corresponding to the target environment are queried, and a service-parameter mapping table is generated according to the target environment parameters. The four-level data model is constructed based on the environment table, service table, parameter table and dependency table.

[0009] Based on the service-parameter mapping table, the template configuration file corresponding to the service is obtained from the preset configuration library, and the target environment parameters are filled into the template configuration file to generate the target configuration file;

[0010] Based on the target configuration file, the data in the preset standard database will be synchronized to the target database;

[0011] Restart all services corresponding to the target environment to complete the automated deployment of the test environment.

[0012] In one embodiment, before querying the target environment parameters and target database corresponding to the target environment based on the pre-built four-level data model, and generating a service-parameter mapping table based on the target environment parameters, the method further includes:

[0013] Create environment tables, service tables, parameter tables, and dependency tables in the central parameter database;

[0014] Generate a batch parameter input script;

[0015] Execute the batch parameter input script to populate the environment table, service table, parameter table and dependency table with the business data corresponding to the actual business scenario;

[0016] Verify the consistency of the environment table, service table, parameter table, and dependency table after data population;

[0017] If the consistency check passes, a four-level data model representing the environment, services, parameters, and dependencies is generated.

[0018] In one embodiment, the step of obtaining the template configuration file corresponding to the service from a preset configuration library according to the service-parameter mapping table and filling the template configuration file with the target environment parameters to generate the target configuration file includes:

[0019] According to the service-parameter mapping table, the corresponding YAML template file is obtained from the preset FTP (File Transfer Protocol) configuration library according to the service type. The YAML template file contains dynamic placeholders.

[0020] Based on the target environment parameters, the FreeMarker engine and template engine are invoked to replace the dynamic placeholders in the YAML template file with the corresponding parameter values, thereby generating the target configuration file.

[0021] In one embodiment, before synchronizing data from the preset standard database to the target database based on the target configuration file, the method further includes:

[0022] Database data is periodically retrieved from the production environment, including synchronized table structures, indexes, foreign keys, and basic data.

[0023] Based on the acquired database data, a preset standard database is generated, and the corresponding version number is recorded.

[0024] In one embodiment, synchronizing data from a preset standard database to the target database based on the target configuration file includes:

[0025] Connect to the target database, execute SQL (Structured Query Language) statements to parse external dependencies between tables, and construct a dependency graph;

[0026] Perform topological sorting on the dependency graph to generate a data cleaning order;

[0027] Clean up the data in the existing tables of the target database based on the data cleaning order;

[0028] The table structure, indexes, and foreign key statements are obtained from a preset standard database, and the execution order is generated according to the topological sorting.

[0029] The table creation and index creation statements are executed sequentially according to the execution order, and the table structure and indexes are rebuilt in the target database.

[0030] Select the appropriate data import method based on the type of the target database;

[0031] Based on the selected data import method, the data in the preset standard database is imported into the target database.

[0032] In one embodiment, the topological sorting of the dependency graph to generate a data cleaning order includes:

[0033] The Kahn algorithm is used to perform topological sorting on the dependency graph to generate a data cleaning order.

[0034] In one embodiment, after restarting all services corresponding to the target environment and completing the automated deployment of the test environment, the method further includes:

[0035] Record the results, time consumption, and exception information during the automated deployment process of the test environment to obtain log records;

[0036] The log records are stored in a preset log database.

[0037] Secondly, this application also provides an automated deployment device for a test environment. The device includes:

[0038] The input module is used to obtain the target environment identifier of the environment to be deployed.

[0039] The query module is used to query the target environment parameters and target database corresponding to the target environment based on the pre-built four-level data model, and generate a service-parameter mapping table according to the target environment parameters. The four-level data model is constructed based on the environment table, service table, parameter table and dependency table.

[0040] The configuration module is used to obtain the template configuration file corresponding to the service from the preset configuration library according to the service-parameter mapping table, and fill the target environment parameters into the template configuration file to generate the target configuration file;

[0041] The synchronization module is used to synchronize data from the preset standard database to the target database based on the target configuration file;

[0042] The restart deployment module is used to restart all services corresponding to the target environment, completing the automated deployment of the test environment.

[0043] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to perform the following steps:

[0044] Obtain the target environment identifier for the environment to be deployed;

[0045] Based on the pre-built four-level data model, the target environment parameters and target database corresponding to the target environment are queried, and a service-parameter mapping table is generated according to the target environment parameters. The four-level data model is constructed based on the environment table, service table, parameter table and dependency table.

[0046] Based on the service-parameter mapping table, the template configuration file corresponding to the service is obtained from the preset configuration library, and the target environment parameters are filled into the template configuration file to generate the target configuration file;

[0047] Based on the target configuration file, the data in the preset standard database will be synchronized to the target database;

[0048] Restart all services corresponding to the target environment to complete the automated deployment of the test environment.

[0049] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, performs the following steps:

[0050] Obtain the target environment identifier for the environment to be deployed;

[0051] Based on the pre-built four-level data model, the target environment parameters and target database corresponding to the target environment are queried, and a service-parameter mapping table is generated according to the target environment parameters. The four-level data model is constructed based on the environment table, service table, parameter table and dependency table.

[0052] Based on the service-parameter mapping table, the template configuration file corresponding to the service is obtained from the preset configuration library, and the target environment parameters are filled into the template configuration file to generate the target configuration file;

[0053] Based on the target configuration file, the data in the preset standard database will be synchronized to the target database;

[0054] Restart all services corresponding to the target environment to complete the automated deployment of the test environment.

[0055] Fifthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, performs the following steps:

[0056] Obtain the target environment identifier for the environment to be deployed;

[0057] Based on the pre-built four-level data model, the target environment parameters and target database corresponding to the target environment are queried, and a service-parameter mapping table is generated according to the target environment parameters. The four-level data model is constructed based on the environment table, service table, parameter table and dependency table.

[0058] Based on the service-parameter mapping table, the template configuration file corresponding to the service is obtained from the preset configuration library, and the target environment parameters are filled into the template configuration file to generate the target configuration file;

[0059] Based on the target configuration file, the data in the preset standard database will be synchronized to the target database;

[0060] Restart all services corresponding to the target environment to complete the automated deployment of the test environment.

[0061] The aforementioned automated deployment method, apparatus, computer equipment, storage media, and computer program products for the test environment acquire the target environment identifier of the environment to be deployed; based on a pre-built four-level data model, query the target environment parameters and target database corresponding to the target environment, and generate a service-parameter mapping table according to the target environment parameters. The four-level data model is constructed based on the environment table, service table, parameter table, and dependency table; according to the service-parameter mapping table, retrieve the template configuration file corresponding to the service from the preset configuration library, and populate the template configuration file with the target environment parameters to generate the target configuration file; based on the target configuration file, synchronize the data in the preset standard database to the target database; restart all services corresponding to the target environment to complete the automated deployment of the test environment. Throughout the process, the four-level data model accurately locates the target environment parameters and database, ensuring the accuracy of the deployment basis; the service-parameter mapping table quickly retrieves and populates the template configuration file, reducing manual configuration errors; and the data synchronization and service restart based on the target configuration file accurately synchronizes the data in the preset standard database to the target database corresponding to the current deployment environment, achieving automatic data synchronization and import, significantly improving the efficiency and accuracy of automated deployment of the test environment. Attached Figure Description

[0062] Figure 1 This is an application environment diagram of an automated deployment method for a test environment in one embodiment;

[0063] Figure 2 This is a flowchart illustrating an automated deployment method for a test environment in one embodiment;

[0064] Figure 3 This is a schematic diagram of a sub-process of S400 in one embodiment;

[0065] Figure 4 This is a flowchart illustrating the automated deployment method for a test environment in a specific application example.

[0066] Figure 5 This is a structural block diagram of an automated deployment device for a test environment in one embodiment;

[0067] Figure 6 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0068] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0069] The automated deployment method for the test environment provided in this application embodiment can be applied to, for example... Figure 1In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated on server 104 or placed on a cloud or other network server. Terminal 102 responds to user operations, generates an automated deployment request for the test environment, and sends the request to server 104. Server 104 parses the request, obtains the target environment identifier of the environment to be deployed, queries the target environment parameters and target database corresponding to the target environment based on a pre-built four-level data model, and generates a service-parameter mapping table based on the target environment parameters. The four-level data model is constructed based on the environment table, service table, parameter table, and dependency table. Based on the service-parameter mapping table, it retrieves the template configuration file corresponding to the service from the preset configuration library, fills the template configuration file with the target environment parameters, and generates the target configuration file. Based on the target configuration file, it synchronizes the data in the preset standard database to the target database. It restarts all services corresponding to the target environment, completing the automated deployment of the test environment. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, and tablets. Server 104 can be implemented using a standalone server or a server cluster composed of multiple servers. Furthermore, the automated deployment method for the test environment of this application can also be directly applied to the terminal, which responds to user operations and executes the processing flow of the above-mentioned automated deployment method for the test environment to achieve automated deployment of the test environment. The specific processing flow is similar to that described above and will not be repeated here.

[0070] In one embodiment, such as Figure 2 As shown, an automated deployment method for a test environment is provided, which can be applied to... Figure 1 Taking server 104 as an example, the following steps are included:

[0071] S100: Obtain the target environment identifier for the environment to be deployed.

[0072] The target environment identifier for the environment to be deployed is obtained from user input, system configuration files, or other relevant data sources through specific interfaces or interaction methods. This identifier uniquely identifies the test environment that needs to be automatically deployed. Specifically, the target environment identifier can be obtained through an API (Application Programming Interface), which can be the name of the test environment. In practice, the user calls the API and inputs the target environment name (e.g., "Test Environment 1"). The terminal then generates a deployment request based on "Test Environment 1" and sends it to the server. The server parses the request and determines that the test environment to be deployed is "Test Environment 1".

[0073] The target environment identifier is the foundation for subsequent steps. It provides key information for querying relevant parameters and databases of the target environment, ensuring that deployment operations can be accurately applied to the specified test environment and avoiding deployment errors caused by environment confusion.

[0074] S200: Based on the pre-built four-level data model, query the target environment parameters and target database corresponding to the target environment, and generate a service-parameter mapping table according to the target environment parameters. The four-level data model is constructed based on the environment table, service table, parameter table and dependency table.

[0075] The four-level data model is constructed from an environment table, a service table, a parameter table, and a dependency table. The environment table stores basic information about different test environments; the service table records relevant information about each service; the parameter table contains various parameters required for service operation; and the dependency table clarifies the dependencies between services and parameters, and between services themselves. Querying is performed within the four-level data model using the target environment identifier. First, the corresponding environment record is found in the environment table based on the environment identifier. Then, through the association between the environment record and the service table, all services running in that environment are located. Next, based on the association between the service record and the parameter table, the target environment parameters for each service are obtained. Simultaneously, relevant information about the target database (such as database address and port) can also be determined based on the environment identifier. The retrieved target environment parameters are organized by service to generate a service-parameter mapping table. This mapping table clearly displays each service and its corresponding parameters, providing a data foundation for subsequent configuration file generation.

[0076] Here, a four-level data model enables comprehensive and accurate acquisition of relevant information about the target environment, avoiding the tedious process of manual data collection and organization, and improving data accuracy and consistency. The generated service-parameter mapping table provides structured data for subsequent steps, making configuration file generation more efficient and accurate.

[0077] S300: Based on the service-parameter mapping table, retrieve the template configuration file corresponding to the service from the preset configuration library, fill the target environment parameters into the template configuration file, and generate the target configuration file.

[0078] The default configuration library stores template configuration files for various services. These template configuration files are pre-written based on the general requirements and best practices of the services, and contain the basic configuration structure and parameter placeholders required for service operation. Based on the service information recorded in the service-parameter mapping table, the corresponding service template configuration file is located in the default configuration library. The target environment parameters from the service-parameter mapping table are then filled into the corresponding placeholders in the template configuration file to generate the target configuration file. This target configuration file contains the specific configuration information required for service operation in a specific test environment.

[0079] Here, a target configuration file is generated using a pre-defined template configuration file and target environment parameters, avoiding the need to manually write configuration files for each test environment and greatly improving the efficiency of configuration file generation. At the same time, parameter population ensures the accuracy and specificity of the configuration file, enabling the service to run correctly in the target environment.

[0080] S400: Based on the target configuration file, synchronize data from the preset standard database to the target database.

[0081] The target configuration file contains key configurations such as database connection information and data synchronization rules. By parsing the target configuration file, the connection parameters between the source database (the default standard database) and the target database, as well as the data tables and fields that need to be synchronized, can be obtained. Based on the configuration information in the target configuration file, a connection is established between the source and target databases, and data from the default standard database is synchronized to the target database according to the specified synchronization rules. The synchronization process can use either full synchronization or incremental synchronization, depending on the data volume and synchronization requirements.

[0082] Here, data from the preset standard database is synchronized to the target database, ensuring that the target database contains the basic data required for testing and providing data support for the normal operation of the service. Synchronizing data based on the target configuration file guarantees the accuracy and consistency of the data, avoiding testing problems caused by data inconsistencies.

[0083] S500: Restart all services corresponding to the target environment to complete the automated deployment of the test environment.

[0084] After data synchronization is complete, all services corresponding to the target environment are restarted via specific service management interfaces or commands. During the restart process, the system starts each service sequentially according to their dependencies, ensuring normal call relationships between services. Restarting services allows them to load the latest configuration files and data, enabling them to run in the target environment. By automating service restarts, the tedious process of manually starting services one by one is avoided, improving deployment efficiency and ensuring the accuracy and consistency of service startup, thus completing the automated deployment of the test environment.

[0085] The above-described automated deployment method for the test environment involves: obtaining the target environment identifier; querying the target environment parameters and target database based on a pre-built four-level data model; generating a service-parameter mapping table based on the target environment parameters; constructing the four-level data model based on the environment table, service table, parameter table, and dependency table; retrieving the template configuration file corresponding to the service from the preset configuration library based on the service-parameter mapping table, and filling the template configuration file with the target environment parameters to generate the target configuration file; synchronizing data from the preset standard database to the target database based on the target configuration file; and restarting all services corresponding to the target environment to complete the automated deployment of the test environment. Throughout this process, the four-level data model accurately locates the target environment parameters and database, ensuring the accuracy of the deployment basis; the service-parameter mapping table quickly retrieves and fills the template configuration file, reducing manual configuration errors; and synchronizing data and restarting services based on the target configuration file accurately synchronizes data from the preset standard database to the target database corresponding to the current deployment environment, achieving automatic data synchronization and import, significantly improving the efficiency and accuracy of automated deployment of the test environment.

[0086] In one embodiment, before querying the target environment parameters and target database corresponding to the target environment based on a pre-built four-level data model, and generating a service-parameter mapping table based on the target environment parameters, the method further includes:

[0087] Step 1: Create environment tables, service tables, parameter tables, and dependency tables in the central parameter database.

[0088] The central parameter database can be managed using MySQL 8.0. The environment table (t_env) stores key information such as environment name and environment type. The environment name uniquely identifies different test environments, while the environment type distinguishes environments for different purposes, such as development, testing, and production. The service table (t_service) stores the service name and the environment to which the service belongs, clearly indicating the specific environment in which each service runs. The parameter table (t_param) stores various parameters, including IP address, port number, and database connection string. Sensitive parameters are encrypted using AES-256 to ensure data security. The dependency table (t_dependency) records startup and configuration dependencies between storage services; for example, a service must start after another service, or the configuration of one service depends on specific parameters of another service.

[0089] Here, creating these four core tables forms the basis for building a four-level data model. It provides a structured data storage framework for the subsequent storage and management of the environment, services, parameters, and their dependencies, and enables standardized storage of parameters, facilitating unified management and querying.

[0090] Step 2: Generate a batch parameter input script.

[0091] By developing a specific batch parameter entry script, it supports batch parameter entry via Excel template upload. The script includes parameter format validation functions, such as validating the IP address format to ensure it conforms to standard IP address formats, and validating the port number range to ensure it remains within a valid range. Furthermore, when storing encrypted parameters, the script interfaces with a hardware encryption device to manage the key, ensuring the security and reliability of the encryption process.

[0092] Here, generating batch parameter entry scripts improves the efficiency of parameter entry, avoiding the tedious process of manually entering parameters one by one. The parameter format validation function ensures the accuracy and standardization of the entered data, preventing problems in subsequent operations due to format errors. Connecting to the hardware encryption machine to manage keys further enhances the security of sensitive parameters.

[0093] Step 3: Execute the batch parameter entry script to populate the environment table, service table, parameter table, and dependency table with the business data corresponding to the actual business scenario.

[0094] After executing the batch parameter entry script, the corresponding business data is accurately populated into the four core tables created earlier, according to the needs of the actual business scenario. For example, the environment names and types of different test environments are populated into the environment table; the names of each service and their respective environment information are populated into the service table; the IP, port, database connection string, and other parameters of the service are populated into the parameter table, where sensitive parameters are encrypted using the AES-256 encryption algorithm before storage; and the startup and configuration dependencies between services are populated into the dependency table.

[0095] Here, actual business data is populated into the core table, enabling the four-level data model to accurately reflect the environment, services, parameters, and relationships between them in the actual business scenario, providing accurate data support for subsequent automated deployment of the test environment based on this model.

[0096] Step 4: Verify the consistency of the environment table, service table, parameter table, and dependency table after data population.

[0097] Consistency checks are performed on the four core tables after data population. The checks include verifying the correctness of relationships between tables; for example, whether the service environment recorded in the service table exists in the environment table; whether the service parameters recorded in the parameter table are associated with their corresponding services; and whether the service dependencies recorded in the dependency table are reasonable and consistent with actual business logic. The server also supports parameter version tracking, retaining modification records for the past 30 days for easy viewing of historical parameter changes; and supports difference comparison functionality, such as comparing parameter differences between test environment 1 and test environment 2, with parameter query response time controlled to ≤100ms.

[0098] Here, consistency checks ensure the accuracy and integrity of data in the Level 4 data model, preventing subsequent deployment errors caused by data inconsistencies. Parameter version tracking and difference comparison functions facilitate data management and troubleshooting, enabling rapid identification of parameter changes and differences between different environments.

[0099] Step 5: If the consistency check passes, a four-level data model representing the environment, services, parameters, and dependencies is generated.

[0100] Once the consistency check passes, the server generates a four-level data model representing the environment, services, parameters, and dependencies based on the data in the four core tables. This model presents the environment, services, parameters, and their dependencies in a structured manner, providing a clear data architecture and query basis for subsequent automated deployment of the test environment based on this model.

[0101] In one embodiment, based on the service-parameter mapping table, a template configuration file corresponding to the service is obtained from a preset configuration library, and the target environment parameters are filled into the template configuration file to generate the target configuration file, including:

[0102] Step 1: Based on the service-parameter mapping table, retrieve the corresponding YAML template file from the preset FTP configuration library according to the service type. The YAML template file contains dynamic placeholders.

[0103] The default FTP configuration library uses vsftpd 3.0+, which centrally stores standard YAML template files for various services. The FTP protocol is characterized by stable file transfer and strong compatibility, meeting the storage and access needs of template files in different system environments. The FTP configuration library categorizes YAML template files according to service type. For example, different types of services, such as database services, web services, and caching services, have corresponding standard YAML template files created. This allows for quick location and retrieval of the appropriate template file based on the service type recorded in the service-parameter mapping table. Dynamic placeholders are set in the YAML template files, with the format {{env.service.[service name].[parameter key]}}. This placeholder design facilitates the filling of target environment parameters into the template file in subsequent steps. For example, if the service name is "mysql" and the parameter key is "port", the placeholder is {{env.service.mysql.port}}, and when filling in the parameters, the actual port number of the service in the target environment will replace this placeholder.

[0104] Here, the corresponding YAML template file is retrieved from the preset FTP configuration repository according to the service type, ensuring the matching of the retrieved template file with the service and laying the foundation for generating an accurate target configuration file. The setting of dynamic placeholders provides a standardized format for the dynamic filling of parameters, making the parameter replacement process more standardized and efficient, realizing the basic structure for preparing configuration file generation through "standard template + dynamic placeholders".

[0105] Step 2: Based on the target environment parameters, call the FreeMarker engine and template engine to replace the dynamic placeholders in the YAML template file with the corresponding parameter values ​​to generate the target configuration file.

[0106] The target environment parameters are obtained through queries based on the four-level data model in the preceding steps. They contain the specific parameter values ​​required for the service to run in the target environment, such as IP address, port number, and database connection information. The FreeMarker 2.3+ template engine, a Java-based engine with powerful template processing capabilities, is used. After the system loads the target environment parameters, it calls the FreeMarker engine. The engine matches the dynamic placeholders in the YAML template file against the target environment parameters, finds the corresponding parameter values, and replaces the placeholders with these values. For example, when encountering the placeholder `{{env.service.mysql.port}}`, the engine finds the MySQL service port number in the target environment parameters and replaces it with the placeholder. After the FreeMarker engine's replacement of the dynamic placeholders, the original YAML template file becomes a target configuration file containing the actual parameter values. This target configuration file can be directly used by the service in the test environment to ensure that the service runs correctly in the target environment.

[0107] Here, the FreeMarker engine and template engine are invoked to replace dynamic placeholders with corresponding parameter values, achieving automatic generation of the configuration file. This approach avoids errors and omissions that may occur when manually writing configuration files, improving the accuracy and efficiency of configuration file generation. Through this automated parameter replacement process, target configuration files that meet the requirements of the target environment can be quickly generated, providing the necessary file support for subsequently distributing the configuration files to the test environment server and starting the service, further promoting the smooth progress of the automated deployment process of the test environment.

[0108] In one embodiment, before synchronizing data from a preset standard database to the target database based on the target configuration file, the method further includes:

[0109] Step 1: Periodically retrieve database data from the production environment. The database data includes synchronized table structures, indexes, foreign keys, and basic data.

[0110] A scheduled task mechanism is employed, with data acquisition operations scheduled to run every Thursday morning. This timing is typically chosen to coincide with a low usage period in the production environment, minimizing impact on actual business operations. The data originates from the actual production environment database, which houses the core business data. During data acquisition, sensitive information is anonymized to ensure data security and compliance, such as masking personal privacy data like phone numbers and ID card numbers to prevent leaks. The database encompasses several key elements, including table structure (defining field names, data types, constraints, etc., forming the basic framework for data organization); indexes (accelerating data retrieval and improving query performance); foreign keys (establishing relationships between tables to ensure data integrity and consistency); and basic data such as dictionary data (standardizing the definition of specific business concepts) and configuration data (containing various configuration parameters required for system operation).

[0111] Here, periodically retrieving this data from the production environment ensures that the data in the pre-defined standard database remains synchronized with the production environment, promptly reflecting the structure and basic data status of the production environment database. Anonymization ensures that the data acquisition process complies with security regulations, preventing the improper dissemination of sensitive information. Obtaining comprehensive database data provides the foundation for subsequently generating an authoritative and accurate pre-defined standard database.

[0112] Step 2: Based on the acquired database data, generate a preset standard database and record the corresponding version number.

[0113] Each update generates a version number in the format "YYYYMMDD.Ver", such as "20250906.V1". This version number generation method clearly records the update time of the standard database, facilitating the management and tracking of different versions. The entire preset standard database supports version rollback operations, allowing rollback to any version within the last 30 days. If problems are found with the current version during subsequent use, or if it is necessary to restore to a previous stable version, a quick and accurate rollback can be performed, ensuring the stability and reliability of the standard database. During requirement testing, newly added SQL statements are updated to the standard database through the database management platform. This allows the standard database to reflect changes in business requirements in a timely manner, ensuring that the database structure remains synchronized with business development. A structure comparison function between the standard and target databases is provided, automatically identifying differences in field types and lengths and generating a difference report. This function clearly shows the structural differences between the standard and target databases, providing strong support for subsequent data synchronization and database maintenance.

[0114] In one embodiment, such as Figure 3 As shown, S400 includes:

[0115] S410: Connects to the target database, executes SQL statements to parse external dependencies between tables, and constructs a dependency graph.

[0116] Specifically, the database synchronization module can be invoked. This module has the ability to establish connections with various types of target databases, ensuring adaptability to different database environments. After connecting to the target database, a specific SQL statement is executed. The core function of this SQL statement is to deeply analyze the foreign key dependencies between tables. For example, in a business scenario, there might be complex dependencies such as "t_pay (payment table) depends on t_order (order table), t_order depends on t_user (user table)". The SQL statement parsing can accurately capture these relationships and present them in the form of an intuitive dependency graph. The dependency graph uses nodes to represent tables in the database and directed edges to represent the direction of foreign key dependencies between tables, clearly showing the relationship logic between data.

[0117] Accurately parsing and constructing the external dependency graph between tables is fundamental to the entire database synchronization process. It provides crucial logical support for subsequent data cleanup and structure synchronization, ensuring correct handling of table relationships during operation, avoiding operational errors caused by foreign key dependencies, and laying the foundation for resolving foreign key conflicts.

[0118] S420: Perform topological sorting on the dependency graph to generate a data cleaning order.

[0119] Specifically, the Kahn algorithm can be used to perform topological sorting on the dependency graph to generate a data cleaning order. The Kahn algorithm is a classic algorithm for topological sorting of directed acyclic graphs (DAGs). It determines the processing order of nodes based on the direction of edges in the dependency graph. The data cleaning order generated by this algorithm follows the principle of "deleting child tables first, then parent tables," for example, the generated order is "t_pay→t_order→t_user." This order ensures that deletion operations will not fail due to foreign key dependencies during data cleaning, guaranteeing the smooth progress of data cleaning.

[0120] Here, generating a reasonable data cleaning order can effectively avoid foreign key conflicts when cleaning existing table data in the target database. Following the order of "deleting child tables first, then parent tables" can prevent the problem of foreign key constraints in child tables being violated due to deleting parent table data first, thus preventing the deletion operation from failing and improving the efficiency and success rate of data cleaning.

[0121] S430: Clean up the data in the existing tables of the target database based on the data cleaning order.

[0122] Based on the data cleanup order generated in the previous step, the `DELETE FROM [table name]` statement is executed sequentially on the tables in the target database. This statement can precisely delete all data in the specified tables, ensuring that no data is missed during the cleanup process. It also operates in a predetermined order to avoid errors caused by foreign key dependencies. Cleaning the existing tables in the target database prepares for subsequent data synchronization from the preset standard database. By cleaning data in a reasonable order, the target database is ensured to be in a clean and conflict-free state, providing a good environment for the accurate import of new data and further improving the overall quality of database synchronization. Specifically, the cleanup time should be ≤2 minutes per 100 tables.

[0123] S440: Retrieves table structure, indexes, and foreign key statements from a preset standard database and generates an execution order based on topological sorting.

[0124] The SQL statements related to table structure, indexes, and foreign keys are extracted from a pre-defined standard database. These statements contain detailed information on creating tables, defining indexes, and setting foreign key constraints. Then, the execution order of these statements is determined according to the topological sort generated earlier using the Kahn algorithm (e.g., "t_user→t_order→t_pay"). This execution order follows the principle of "parent tables first, child tables later," ensuring that table structure and index creation does not fail due to foreign key dependency issues.

[0125] Here, rebuilding table structures and indexes according to a reasonable execution order ensures the correctness and integrity of the database structure. Following the order of "building parent tables first, then child tables" avoids foreign key constraint errors caused by the parent tables not yet being created when creating child tables. This ensures that the target database structure is consistent with the preset standard database, providing structural guarantees for accurate data import. Furthermore, the structure synchronization time is controlled to ≤1 minute / 100 tables, improving synchronization efficiency.

[0126] S450: Execute table creation and index creation statements sequentially according to the execution order, and rebuild the table structure and indexes in the target database.

[0127] The database synchronization module executes the table creation and index creation statements obtained from the preset standard database sequentially, following the execution order determined in the previous step. During execution, it strictly adheres to SQL syntax rules to ensure that each statement is executed correctly, thereby accurately reconstructing the table structure and indexes in the target database.

[0128] S460: Select the appropriate data import method based on the type of the target database.

[0129] For different types of target databases, such as MySQL and Oracle, select the appropriate data import method. For example, choose the LOADDATAINFILE method for MySQL and the IMPDP method for Oracle. These import methods are optimized and verified, and can efficiently import data into the corresponding type of database. Choosing the appropriate data import method can fully leverage the characteristics of different database types, improving the efficiency and compatibility of data import. Different databases differ in their data storage and processing methods; an appropriate import method can better handle these differences, ensuring that data can be accurately and quickly imported into the target database, reducing data errors or import failures caused by improper import methods.

[0130] S470: Based on the selected data import method, import data from the preset standard database into the target database.

[0131] Using the data import method selected in the previous step, the basic data from the preset standard database is accurately imported into the target database. During the import process, the data import specifications and procedures are strictly followed to ensure data integrity and accuracy. Simultaneously, the data import time is controlled to within ≤2 minutes per 1 million data entries, ensuring the efficiency of the import process.

[0132] In one embodiment, after restarting all services corresponding to the target environment and completing the automated deployment of the test environment, the process further includes:

[0133] Step 1: Record the results, time consumption, and exception information during the automated deployment process of the test environment to obtain log records.

[0134] Information collection points are set up at each key stage of the automated deployment in the test environment. These collection points can accurately capture the execution results of each step, such as whether the service has started successfully, whether the configuration file has been loaded correctly, and other explicit success or failure status information.

[0135] The execution time of each step is recorded using a high-precision time statistics tool. This tool can accurately obtain timestamps at the start and end of a step, and calculate the difference between the two timestamps to obtain the actual execution time of the step, ensuring the accuracy of the time consumption data. When anomalies occur during deployment, the system automatically captures anomaly information, including the anomaly type, the time of occurrence, and related error stack information. This anomaly information can reflect the root cause and context of the problem in detail. The collected execution results, time consumption, and anomaly information are integrated to generate a complete log record according to a preset log recording format. The log record format typically includes fields such as timestamp, step identifier, execution result, time consumption, and anomaly information (if present) to facilitate subsequent querying and analysis.

[0136] Step 2: Store the log records to the preset log database.

[0137] The default log database employs a high-performance, highly reliable database management system, such as MySQL or Oracle, possessing robust data storage and management capabilities. Data transmission between the log recording module and the log database occurs via a stable network connection, utilizing an efficient data writing mechanism to ensure timely and accurate storage of log records in the database. During storage, log records are structured and categorized according to different fields (such as step name, execution result, execution time, and exception information) for easy subsequent querying and analysis. Furthermore, the log database includes data backup and recovery functions, periodically backing up log data to prevent data loss.

[0138] In one embodiment, after restarting all services corresponding to the target environment and completing the automated deployment of the test environment, the process further includes:

[0139] Anomaly monitoring is performed on the deployed test environment, including anomaly monitoring for missing parameters, configuration rendering, database synchronization, and server restart.

[0140] Missing Parameter: If a critical service parameter (such as IP address or port) is missing, the process is immediately terminated, returning the error "Parameter Missing: [Parameter Key] for service [service name] is not configured". Configuration Rendering Anomaly: If a placeholder has no corresponding parameter, a rendering failure log is generated, the process is terminated, and the relevant tester is notified. Database Synchronization Anomaly: When SQL execution fails, the executed operation is automatically rolled back (through transaction management), and an error message is returned. Service Restart Anomaly: If the service fails after 3 retries, the system switches to "Manual Intervention Mode" and retains logs for troubleshooting.

[0141] To illustrate the technical solution of the automated deployment method for the test environment in this application, the following example will be used for the automated deployment of test environment 1, and will be combined with... Figure 4 Expand description.

[0142] Before automating the deployment of the test environment, the following pre-processing steps must be performed:

[0143] A. Users store environment information, database information, service information, etc. of test environment 1 into the fourth-level database by calling the API interface.

[0144] B. The FTP configuration library already contains standard templates for all services.

[0145] C. The standard library contains the latest data and table structures.

[0146] Deployment process:

[0147] Step 1, Trigger: The user calls the API interface (POST / api / v1 / env / switch), enters the name "Test Environment 1", and after the system verifies the permissions, it triggers the automatic deployment process.

[0148] Step 2, Parameter Loading: The scheduling module calls the parameter management module to query and load all parameters of "Test Environment 1" and generate a "Service-Parameter" mapping table, which takes ≤100ms.

[0149] Step 3, Configuration Rendering and Distribution: The scheduling module calls the configuration rendering module to execute the configuration generation and distribution logic in Step 2. Upon completion, it returns a "Configuration Ready" signal. At this point, the configuration files (YAML files) for all services corresponding to Test Environment 1 have been configured.

[0150] Step 4: Intelligent database synchronization.

[0151] Step 4.1 Dependency Resolution: Call the database synchronization module, connect to the database corresponding to "Test Environment 1", execute SQL to parse foreign key dependencies between tables, and build a dependency graph.

[0152] Step 4.2, Data Cleaning: Use the Kahn algorithm to perform graph topological sorting on the dependencies, generate the cleanup order (t_pay→t_order→t_user), and execute DELETEFROM [table name] in sequence. The cleanup time is ≤2 minutes / 100 tables.

[0153] Step 4.3, Structure Synchronization: Obtain the table structure, indexes, and foreign key statements from the standard library, generate the execution order by topological sorting (t_user→t_order→t_pay), and execute table creation and index creation. The time taken is ≤1 minute / 100 tables.

[0154] Step 4.4, Data Import: Import basic data using LOADDATAINFILE (MySQL) or IMPDP (Oracle), taking ≤2 minutes / 1 million data entries.

[0155] Step 4.5: At this point, the table structure and data of the database corresponding to "Test Environment 1" are consistent with the standard library.

[0156] Step 5, Service Restart and Verification: The scheduling module calls the service management module to execute systemctlrestart[service name] to restart all services corresponding to "Test Environment 1". It calls the GET / actuator / health interface to verify the service health status. If an error occurs, it will automatically retry 3 times (with a 5-second interval). If the retry fails, it will trigger an SMS / email alarm. The time taken is ≤60 seconds.

[0157] Step 6: Record the execution results, time consumption, and exception information of each step, and store them in the log database, supporting user query and Excel export.

[0158] In the above specific application examples, the automated deployment of the test environment in this application has the following significant technical effects.

[0159] 1) A standardized and automated end-to-end approach enables environment switching within seconds.

[0160] The innovative design of the end-to-end standardized approach of "parameter structured storage - configuration parameterized rendering - intelligent database synchronization - automatic service restart" upgrades the existing technology from "partial automation" to "full-process automation": by connecting each link through unified scheduling logic, no manual intervention is required, and the time for a single environment switch is reduced from 120-240 minutes to ≤8 minutes, which meets the daily environment switch requirements of high-frequency iteration projects of 3+ times.

[0161] 2) Database topology sorting and synchronization method to resolve dependency conflict risks.

[0162] An innovative "graph theory topology sorting algorithm" was introduced to design a database synchronization method of "dependency resolution-sorting-execution": by resolving foreign key dependencies between tables to construct a relationship graph, the Kahn algorithm was used to generate a cleanup order of "deleting child tables first, then deleting parent tables" and a synchronization order of "creating parent tables first, then creating child tables", which completely solves the foreign key conflict problem and reduces the database synchronization failure rate from 15% to ≤0.5% (due to hardware failure only).

[0163] 3) Dynamic parameterization of configuration files to ensure environment consistency.

[0164] The innovative design adopts a "standard template + dynamic placeholder" approach, with one template adapting to all environments: a dedicated standard template is maintained in the FTP configuration library (only 10 templates are needed for 10 services), and the placeholders are automatically replaced by the FreeMarker engine in combination with the target environment parameters to generate a dedicated configuration file. The amount of template maintenance is reduced by 80%, and the consistency difference rate of environment configuration is reduced from 18% to 0%.

[0165] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0166] Based on the same inventive concept, this application also provides an automated test environment deployment apparatus for implementing the aforementioned automated test environment deployment method. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more embodiments of the automated test environment deployment apparatus provided below can be found in the limitations of the automated test environment deployment method described above, and will not be repeated here.

[0167] In one embodiment, such as Figure 5 As shown, an automated deployment device for a test environment is provided, comprising:

[0168] Input module 100 is used to obtain the target environment identifier of the environment to be deployed.

[0169] The query module 200 is used to query the target environment parameters and target database corresponding to the target environment based on the pre-built four-level data model, and generate a service-parameter mapping table according to the target environment parameters. The four-level data model is constructed based on the environment table, service table, parameter table and dependency table.

[0170] Configuration module 300 is used to obtain the template configuration file corresponding to the service from the preset configuration library according to the service-parameter mapping table, and fill the target environment parameters into the template configuration file to generate the target configuration file;

[0171] Synchronization module 400 is used to synchronize data from a preset standard database to a target database based on the target configuration file;

[0172] Restart deployment module 500, used to restart all services corresponding to the target environment, to complete the automated deployment of the test environment.

[0173] In one embodiment, the query module 200 is further configured to create an environment table, a service table, a parameter table, and a dependency table in the central parameter database; generate a batch parameter entry script; execute the batch parameter entry script to fill the environment table, service table, parameter table, and dependency table with business data corresponding to the actual business scenario; verify the consistency of the environment table, service table, parameter table, and dependency table after data filling; and if the consistency verification passes, generate a four-level data model representing the environment-service-parameter-dependency relationship.

[0174] In one embodiment, the configuration module 300 is further configured to obtain the corresponding YAML template file from a preset FTP configuration library according to the service type based on the service-parameter mapping table, wherein the YAML template file contains dynamic placeholders; and based on the target environment parameters, call the FreeMarker engine and the template engine to replace the dynamic placeholders in the YAML template file with the corresponding parameter values ​​to generate the target configuration file.

[0175] In one embodiment, the synchronization module 400 is also used to periodically obtain database data from the production environment. The database data includes synchronized table structures, indexes, foreign keys, and basic data. Based on the obtained database data, a preset standard database is generated, and the corresponding version number is recorded.

[0176] In one embodiment, the synchronization module 400 is further configured to connect to the target database, execute SQL statements to parse external dependencies between tables, and construct a dependency graph; perform topological sorting on the dependency graph to generate a data cleanup order; clean the data of existing tables in the target database based on the data cleanup order; obtain table structures, indexes, and foreign key statements from a preset standard database and generate an execution order according to the topological sorting; execute table creation and index creation statements sequentially according to the execution order to rebuild the table structure and indexes in the target database; select the corresponding data import method according to the type of the target database; and import the data from the preset standard database into the target database based on the selected data import method.

[0177] In one embodiment, the synchronization module 400 is also used to perform topological sorting of the dependency graph using the Kahn algorithm to generate a data cleaning order.

[0178] In one embodiment, the restart deployment module 500 is also used to record the results, time consumption and abnormal information during the automated deployment process of the test environment to obtain log records; and to store the log records in a preset log database.

[0179] Each module in the aforementioned automated deployment device for the testing environment can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0180] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 6 As shown, the computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores preset data. The network interface communicates with external terminals via a network connection. When the computer program is executed by the processor, it implements an automated deployment method for a test environment.

[0181] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0182] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described automated deployment method for the test environment.

[0183] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the above-described automated deployment method for the test environment.

[0184] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the above-described automated deployment method for the test environment.

[0185] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application are relational databases. The processors involved in the embodiments provided in this application can be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited thereto.

[0186] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0187] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for automated deployment of test environments, characterized by, The method comprises: obtaining a target environment identifier of a to-be-deployed environment; querying a target environment parameter and a target database corresponding to the target environment based on a pre-constructed four-level data model, and generating a service-parameter mapping table according to the target environment parameter, wherein the four-level data model is constructed according to an environment table, a service table, a parameter table, and a dependency relationship table; obtaining a template configuration file corresponding to a service from a preset configuration library according to the service-parameter mapping table, filling the target environment parameter into the template configuration file, and generating a target configuration file; synchronizing data in a preset standard database to the target database based on the target configuration file; restarting all services corresponding to the target environment to complete automatic deployment of a test environment.

2. The method of claim 1, wherein, Before the querying of the target environment parameter and the target database based on the pre-constructed four-level data model and the generation of the service-parameter mapping table according to the target environment parameter, the method further comprises: creating the environment table, the service table, the parameter table, and the dependency relationship table in a central parameter database; generating a batch parameter input script; executing the batch parameter input script to fill business data corresponding to an actual business scenario into the environment table, the service table, the parameter table, and the dependency relationship table; verifying consistency of the environment table, the service table, the parameter table, and the dependency relationship table after data filling; if the consistency verification passes, generating a four-level data model representing an environment-service-parameter-dependency relationship.

3. The method of claim 1, wherein, The obtaining of the template configuration file corresponding to the service from the preset configuration library according to the service-parameter mapping table, the filling of the target environment parameter into the template configuration file, and the generation of the target configuration file comprise: obtaining a corresponding yaml template file from a preset FTP configuration library according to a service type according to the service-parameter mapping table, wherein the yaml template file is provided with a dynamic placeholder; based on the target environment parameter, calling a FreeMarker engine and a template engine to replace the dynamic placeholder in the yaml template file with a corresponding parameter value to generate the target configuration file.

4. The method of claim 1, wherein, Before the synchronizing of the data in the preset standard database to the target database based on the target configuration file, the method further comprises: periodically obtaining database data from a production environment, wherein the database data comprises a synchronization table structure, an index, a foreign key, and basic data; based on the obtained database data, generating a preset standard database and recording a corresponding version number.

5. The method of claim 1, wherein, The synchronizing of the data in the preset standard database to the target database based on the target configuration file comprises: connecting the target database, executing a SQL statement to parse an inter-table foreign dependency relationship, and constructing a dependency relationship graph; topologically sorting the dependency relationship graph to generate a data cleaning sequence; cleaning data of an existing table in the target database based on the data cleaning sequence; obtaining a table structure, an index, and a foreign key statement from the preset standard database, and generating an execution sequence according to the topological sorting; sequentially executing table creation and index creation statements according to the execution sequence to reconstruct a table structure and an index in the target database; selecting a corresponding data import mode according to a type of the target database; Based on the selected data import mode, data in the preset standard database is imported into the target database.

6. The method of claim 5, wherein, The topological sorting of the dependency graph to generate a data cleaning sequence comprises: The Kahn algorithm is used to topologically sort the dependency graph to generate a data cleaning sequence.

7. The method of claim 1, wherein, After restarting all services corresponding to the target environment to complete the test environment automatic deployment, the method further comprises: Recording results, time consumption and abnormal information in the test environment automatic deployment process to obtain log records; Storing the log records into a preset log database.

8. A test environment automation deployment apparatus characterized by comprising: The device comprises: An input module configured to obtain a target environment identifier of an environment to be deployed; A query module configured to query a target environment parameter and a target database corresponding to the target environment based on a pre-constructed four-level data model, and to generate a service-parameter mapping table according to the target environment parameter, wherein the four-level data model is constructed according to an environment table, a service table, a parameter table and a dependency relationship table; A configuration module configured to obtain a template configuration file corresponding to a service from a preset configuration library according to the service-parameter mapping table, and to fill the target environment parameter into the template configuration file to generate a target configuration file; A synchronization module configured to synchronize data in a preset standard database to the target database based on the target configuration file; A restart deployment module configured to restart all services corresponding to the target environment to complete the test environment automatic deployment. 9.A computer device, comprising a memory and a processor, wherein the memory stores a computer program, and the computer device is configured to perform the method according to any one of claims 1-8 when the computer program is executed by the processor. The processor implements the steps of the method of any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program implements the steps of the method of any one of claims 1 to 7 when executed by the processor.

Images