Database script deployment method and device, equipment and storage medium

Abstract

The invention discloses a database script deployment method and device, equipment and a storage medium, and relates to the technical field of database management, and the method comprises the steps: sending a database change script for a target product to a user side, and carrying out the data extraction, so as to obtain a target script identifier and product version information; determining a complete script corresponding to the database change script based on the target script identifier and the product version information, and generating a script execution sequence corresponding to the complete script based on the product version information; generating a corresponding script deployment environment in a preset sandbox, and executing deployment of a complete script in the preset sandbox based on the script execution sequence to obtain a script deployment sandbox simulation result; checking based on a preset auditing verification method; and if the verification is passed, determining a current to-be-deployed script from the complete scripts based on the current to-be-deployed environment of the target product, and deploying the current to-be-deployed script to the current to-be-deployed environment. In this way, the script execution consistency and security under multiple database types and multiple environments can be ensured.

Description

Technical Field

[0001] This invention relates to the field of database management technology, and in particular to a database script deployment method, apparatus, device, and storage medium. Background Technology

[0002] In existing technologies, database change management methods based on versioned migration scripts are widely used. This involves a documented script version management mechanism that requires developers to store database change scripts according to specific naming conventions and use the version number in the filename to determine the execution order. Each script contains complete DDL (Data Definition Language) or DML (Data Manipulation Language) statements, which can be traced historically through a version control system. To track execution status, the tool creates a metadata table in the target database to record executed scripts. The automated migration process includes steps such as scanning script files, querying execution history, calculating scripts to be executed, executing them sequentially, and handling exceptions. It also provides basic script verification functions, such as duplicate execution detection, script tampering detection, and version order verification. Furthermore, existing solutions support baseline version settings, facilitating the gradual introduction of version control on existing databases, and some tools even provide the ability to roll back versions by reverting scripts. While this method provides basic version control and automated deployment support for database changes, it still has significant limitations when facing the complex requirements of modern continuous integration environments. Mainstream continuous integration platforms typically lack proactive management capabilities for database scripts, failing to automatically detect script changes or ensure synchronization across multiple environments. Furthermore, their verification mechanisms are often limited to static syntax checking, making it difficult to identify data dependency conflicts and performance impacts in real-world environments. Simultaneously, existing tools often cannot simulate the full execution of scripts starting from an empty database, thus hindering the identification of cumulative effects and interactions between scripts. These shortcomings mean that database script management in continuous integration scenarios still relies on manual processes, making omissions and errors likely, and preventing the achievement of reliable, automated end-to-end solutions.

[0003] Therefore, how to generate a reliable database script management method needs to be addressed. Summary of the Invention

[0004] In view of this, the purpose of this invention is to provide a database script deployment method, apparatus, device, and storage medium, which can realize a complete automated closed-loop process from script creation to development and deployment, ensuring the consistency and security of script execution across multiple database types and environments. The specific solution is as follows:

[0005] Firstly, this application discloses a database script deployment method, including:

[0006] The system obtains the database change script sent by the user terminal for the target product, and extracts data from the database change script to obtain the target script identifier and product version information.

[0007] Based on the target script identifier and the artifact version information, the complete script corresponding to the database change script is determined, and based on the artifact version information, the script execution sequence corresponding to the complete script is generated; the complete script includes the database change script;

[0008] A script deployment environment corresponding to the complete script is generated in a preset sandbox, and the deployment of the complete script is executed in the preset sandbox based on the script execution sequence to obtain the script deployment sandbox simulation results;

[0009] The script deployment sandbox simulation results are verified based on a preset audit and verification method.

[0010] If the script deployment sandbox simulation results pass the verification, then the current script to be deployed is determined from the complete script based on the current deployment environment of the target artifact, and the current script to be deployed is deployed to the current deployment environment.

[0011] Optionally, the step of obtaining the database change script sent by the user terminal for the target product, and extracting data from the database change script to obtain the target script identifier and product version information, includes:

[0012] The application components selected by the user on the visual interface are obtained; the application components are stored in a preset component management repository and displayed in a list on the visual interface.

[0013] The target artifact is determined based on the application components, and all historical scripts and version information of the target artifact are retrieved.

[0014] The database change script sent by the user terminal for the target product is obtained based on the preset script upload interface, so as to obtain the target script identifier and product version information; the database change script includes database scripts corresponding to several types of databases.

[0015] Optionally, after obtaining the database change script for the target product sent by the user terminal based on the preset script upload interface, the method further includes:

[0016] The database change script is subjected to basic verification. The basic verification includes: determining whether the database change script contains scripts corresponding to all target database types, whether the syntax format and operation type of the database change script conform to preset standards, and whether the database change script contains risky operation behaviors; the risky operation behaviors are pre-set prohibited operation behaviors.

[0017] If the database change script passes the basic verification, the database change script, all historical scripts, and historical version information are stored in the preset component management repository.

[0018] Optionally, the step of determining the complete script corresponding to the database change script based on the target script identifier and the artifact version information, and generating the script execution sequence corresponding to the complete script based on the artifact version information, includes:

[0019] The target script identifier and the product version information are bound to the target product.

[0020] The target script to be processed is determined from all historical scripts corresponding to the target script based on the target script identifier, the product version information, and the historical version information; the historical version information corresponding to the target script to be processed has a version dependency relationship with the product version information of the database change script;

[0021] The complete script is determined based on the database change script and the target script to be processed, and the script execution sequence corresponding to the complete script is generated based on the artifact version information.

[0022] Optionally, generating a script deployment environment corresponding to the complete script in a preset sandbox, and deploying the complete script in the preset sandbox based on the script execution sequence to obtain script deployment sandbox simulation results includes:

[0023] The preset sandbox is initialized based on the database types corresponding to the complete script, so as to generate the script deployment environment corresponding to the complete script in the preset sandbox respectively;

[0024] Based on the script execution sequence, the deployment of the historical script in the complete script is executed sequentially in the preset sandbox to obtain a first simulation result. Then, the deployment of the database change script is executed in the preset sandbox to obtain a second simulation result.

[0025] The first simulation result and the second simulation result are determined as the script deployment sandbox simulation results.

[0026] Optionally, the verification of the script deployment sandbox simulation results based on the preset audit verification method includes:

[0027] Based on the script deployment sandbox simulation results, a script execution audit package is generated and sent to the visualization interface to obtain the user's audit results for the script deployment sandbox simulation results.

[0028] Optionally, determining the current deployment script from the complete script based on the current deployment environment of the target artifact, and deploying the current deployment script to the current deployment environment, includes:

[0029] Determine whether the script execution history of the target artifact exists in the current deployment environment;

[0030] If the script execution history does not contain any script deployment information related to the target artifact, then the complete script is determined as the current script to be deployed, based on the script execution sequence corresponding to the complete script, and the current script to be deployed is deployed to the current deployment environment.

[0031] If the script execution history contains script deployment information related to the target artifact, then the current script to be deployed is determined from the complete script based on the relevant script deployment information, and the current script to be deployed is deployed to the current deployment environment; the difference between the complete script and the script corresponding to the relevant script deployment information is the current script to be deployed.

[0032] Secondly, this application discloses a database script deployment apparatus, comprising:

[0033] The script acquisition module is used to acquire the database change script sent by the user terminal for the target product, and to extract data from the database change script to obtain the target script identifier and product version information.

[0034] The script execution sequence determination module is used to determine the complete script corresponding to the database change script based on the target script identifier and the product version information, and to generate the script execution sequence corresponding to the complete script based on the product version information; the complete script includes the database change script;

[0035] The sandbox simulation module is used to generate a script deployment environment corresponding to the complete script in a preset sandbox, and to execute the deployment of the complete script in the preset sandbox based on the script execution sequence, so as to obtain the script deployment sandbox simulation result;

[0036] The script verification module is used to verify the script deployment sandbox simulation results based on a preset audit verification method;

[0037] The script deployment module is used to determine the current script to be deployed from the complete script based on the current deployment environment of the target artifact if the script deployment sandbox simulation result passes the verification, and to deploy the current script to be deployed to the current deployment environment.

[0038] Thirdly, this application discloses an electronic device, including:

[0039] Memory, used to store computer programs;

[0040] A processor for executing the computer program to implement the aforementioned database script deployment method.

[0041] Fourthly, this application discloses a computer-readable storage medium for storing a computer program, which, when executed by a processor, implements the aforementioned database script deployment method.

[0042] As can be seen, in this embodiment, a database change script for a target artifact sent by the user is obtained, and data is extracted from the database change script to obtain a target script identifier and artifact version information; based on the target script identifier and the artifact version information, a complete script corresponding to the database change script is determined, and a script execution sequence corresponding to the complete script is generated based on the artifact version information; the complete script contains the database change script; a script deployment environment corresponding to the complete script is generated in a preset sandbox, and the deployment of the complete script is executed in the preset sandbox based on the script execution sequence to obtain a script deployment sandbox simulation result; the script deployment sandbox simulation result is verified based on a preset audit and verification method; if the script deployment sandbox simulation result passes the verification, a current script to be deployed is determined from the complete script based on the current deployment environment of the target artifact, and the current script to be deployed is deployed to the current deployment environment. That is, a corresponding complete script is generated based on the database change script sent by the user and the version information contained in the database change script; the complete script is simulated using a simulation sandbox environment, and finally, if the simulation result passes the verification, the script is deployed accordingly. This achieves a complete automated closed-loop process from script creation to development and deployment, ensuring consistency and security of script execution across multiple database types and environments. Attached Figure Description

[0043] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0044] Figure 1 This is a flowchart of a database script deployment method disclosed in this application;

[0045] Figure 2 This is a schematic diagram of a specific product version evolution tree disclosed in this application;

[0046] Figure 3 This is a flowchart of a specific sandbox simulation method disclosed in this application;

[0047] Figure 4 This is a schematic diagram of the structure of a database script deployment device disclosed in this application;

[0048] Figure 5 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0049] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0050] Existing tools based on versioned migration scripts support automated deployment and version tracking. However, in continuous integration environments, they lack proactive script management, struggle to verify execution issues in real-world environments, and cannot perform full script pre-execution verification, resulting in low management efficiency and a high risk of errors. Therefore, this application will specifically introduce a database script deployment method that can solve the above problems.

[0051] See Figure 1 As shown in the figure, this application discloses a database script deployment method, including:

[0052] Step S11: Obtain the database change script sent by the user terminal for the target product, and extract data from the database change script to obtain the target script identifier and product version information.

[0053] In this embodiment, the step of obtaining the database change script sent by the user terminal for the target product and extracting data from the database change script to obtain the target script identifier and product version information includes: obtaining the application component selected by the user terminal on the visual interface; the application component is stored in a preset component management repository and displayed in a list form on the visual interface; determining the target product based on the application component and calling all historical scripts and historical version information of the target product; obtaining the database change script sent by the user terminal for the target product based on a preset script upload interface to obtain the target script identifier and product version information; the database change script includes database scripts corresponding to several types of databases.

[0054] First, it's important to clarify that in the context of software development, "artifacts" typically refer to binary or executable files generated during the compilation, packaging, or building of source code. These files can be deployed to servers, used as dependencies for other projects, or run directly. Databases are usually used for their management. As data is continuously updated and the system evolves, each artifact has a complete version evolution history.

[0055] This application maintains a centralized, pre-defined component management repository that stores information on all application components connected to the system. When a user enters the script creation process, the list of components the user has permission to access is retrieved by querying the pre-defined component management repository and presented to the user in the form of a drop-down selection box on the web front-end page (i.e., the visual interface). After the user selects a specific component, the selected component identifier and component metadata (including component name, component code, affiliated team, technology stack type, etc.) are determined accordingly. After determining the component identifier of the application component of the target artifact, all registered artifact information under that component is retrieved through a pre-defined query interface. Each artifact contains a complete version evolution history, and this version information is then sorted according to semantic version numbers (such as 1.0.0, 1.1.0, 1.2.0) or custom version identifiers and displayed in the user interface in the form of a table or list. After the user selects a specific artifact and its target version, this application determines the precise artifact version associated with the current script based on the artifact identifier, artifact version number, and artifact metadata (including artifact name, Git repository address, dependencies, build status, etc.). Specifically, based on the current artifact version information, the target version that the current script will be associated with is clearly displayed in the visualization. Simultaneously, the dependency graph of the artifact version is queried to obtain the version information of all upstream dependent artifacts. This dependency information will be used to determine the complete historical script execution sequence in the subsequent sandbox pre-execution phase. After version confirmation, the artifact version binding information (including artifact ID, version number, and list of dependent artifacts) is stored. SQL (Structured Query Language) script files for three database types are received from users through a preset script upload interface. According to the technical requirements of this invention, each database structure change must simultaneously provide implementation scripts for MySQL (Relational Database Management System), Oracle, and PostgreSQL (Object-Relational Database Management System) to ensure that the system can be verified and deployed in multiple database environments. This application provides three independent script input areas in the user interface, each corresponding to a database type. Users can choose to directly enter SQL statements in a text editor or import local SQL files via file upload. In this way, 1. script management for MySQL, Oracle, and PostgreSQL database types is supported on a unified platform, achieving unified management and parallel verification across database types, ensuring the consistency of the execution of the same business logic in different databases.

[0056] In this embodiment, after obtaining the database change script for the target product sent by the user terminal based on the preset script upload interface, the method further includes: performing basic verification on the database change script; the basic verification includes: determining whether the database change script contains scripts corresponding to all target database types, whether the syntax format and operation type of the database change script conform to preset standards, and whether the database change script contains risky operation behaviors; the risky operation behaviors are pre-set prohibited operation behaviors; if the database change script passes the basic verification, the database change script, all historical scripts, and historical version information are stored in the preset component management repository. Specifically, after obtaining the database change script, basic verification needs to be performed on the script, including: integrity check, i.e., verifying whether all scripts for the three database types are provided, and the absence of any type will prevent the script from being submitted; format verification, i.e., checking the basic syntax format of the SQL statement and identifying obvious syntax errors; keyword detection, i.e., scanning the SQL keywords in the script and identifying the operation type of the script (DDL, DML, DCL, etc.); and dangerous operation warning, providing warning prompts for high-risk operations such as DROP TABLE and TRUNCATE. Once verified, the script content, along with all previously collected metadata (component information, artifact information, version information), is submitted to the central script management repository. The system generates a unique script identifier for each script and records complete metadata information, including the script's creation time, creator, and associated artifact version. Once submitted, a script becomes immutable; any modifications require creating a new script version, ensuring the complete traceability of the change history.

[0057] Step S12: Determine the complete script corresponding to the database change script based on the target script identifier and the artifact version information, and generate the script execution sequence corresponding to the complete script based on the artifact version information; the complete script includes the database change script.

[0058] In this embodiment, determining the complete script corresponding to the database change script based on the target script identifier and the artifact version information, and generating the script execution sequence corresponding to the complete script based on the artifact version information, includes: binding the target script identifier and the artifact version information to the target artifact; determining the target script to be processed from all historical scripts corresponding to the target artifact based on the target script identifier, the artifact version information, and the historical version information; the historical version information corresponding to the target script to be processed has a version dependency relationship with the artifact version information of the database change script; determining the complete script based on the database change script and the target script to be processed, and generating the script execution sequence corresponding to the complete script based on the artifact version information. Specifically, this application achieves intelligent management of script execution order through an artifact dependency graph. Figure 2 This demonstrates a typical artifact version evolution tree, where version 1.0.x serves as the initial baseline version, version 1.1.x depends on version 1.0.x, and version 1.2.x depends on version 1.1.x, forming the main version evolution path. Simultaneously, version 1.1.x Custom 1 is derived from version 1.1.x, and two branch versions, 1.2.x Custom 1 and 1.2.x Custom 2, are derived from version 1.2.x, along with subsequent main versions such as 2.0.x and 2.1.x. After obtaining the target script identifier and artifact version information, a precise association is first established between the script and the specified artifact version. This application maintains a script-artifact-version association table in the preset component management repository, recording information such as the artifact to which each script belongs, the associated version number, and the execution order of the script in that version. Dependency resolution mechanism: By recursively traversing the artifact dependency tree, the complete set of scripts required to execute for any version is calculated. Figure 2Taking version 2.0.x as an example, when deploying from an empty database to version 2.0.x, the system identifies the complete dependency path through dependency resolution: 1.0.x → 1.1.x → 1.2.x → 2.0.x. This embodiment sequentially collects all scripts associated with this path and sorts them according to version dependency order and script creation time to generate the final script execution sequence. For customized branch versions, this application adopts a differentiated script set calculation strategy. For example, when deploying customized version 1.2.x, all scripts from 1.0.x → 1.1.x → 1.2.x are first collected along the main path, and then additional scripts specific to the customized branch 1.2.x are added. This mechanism ensures that the customized version includes all the functions of the main path while also fulfilling specific customization requirements. Furthermore, this embodiment accurately identifies the incremental scripts that need to be executed by comparing the dependency paths between the current version of the environment and the target version. Assuming an environment currently running version 1.1.x needs to be upgraded to version 2.0.x, the incremental path is calculated using the dependency tree: 1.1.x → 1.2.x → 2.0.x. Only scripts added along this incremental path are collected to avoid repeatedly executing previously deployed scripts. Furthermore, this application performs version compatibility checks when generating the script execution sequence. The system maintains compatibility rules between versions, such as prohibiting direct rollback from version 2.x to version 1.x, or restricting direct upgrades across multiple major versions. When an incompatible version jump is detected, the artifact binding module warns the user and suggests a reasonable upgrade path. Finally, the corresponding script execution sequence is obtained.

[0059] Step S13: Generate the script deployment environment corresponding to the complete script in the preset sandbox, and execute the deployment of the complete script in the preset sandbox based on the script execution sequence to obtain the script deployment sandbox simulation result.

[0060] In this embodiment, the step of generating the script deployment environment corresponding to the complete script in a preset sandbox, and executing the deployment of the complete script in the preset sandbox based on the script execution sequence to obtain the script deployment sandbox simulation result includes: initializing the preset sandbox based on each database type corresponding to the complete script to generate the script deployment environment corresponding to the complete script in the preset sandbox respectively; sequentially executing the deployment of the historical scripts in the complete script in the preset sandbox based on the script execution sequence to obtain a first simulation result; then executing the deployment of the database change script in the preset sandbox to obtain a second simulation result; and determining the first simulation result and the second simulation result as the script deployment sandbox simulation result. (See attached...) Figure 3As shown, completely isolated temporary database instances for MySQL, Oracle, and PostgreSQL are created simultaneously within a sandbox. The creation process employs lightweight virtualization technology, quickly starting the database process using a predefined database template image. Each sandbox environment contains an independent database instance process, independent storage space, independent network port, and independent user permission configuration. A unique identifier is assigned to each sandbox instance, and the instance's connection information (such as IP address, port number, username, and password) is recorded. This connection information will be passed to subsequent initialization and execution mechanisms.

[0061] As attached Figure 3As shown, the creation process of the three database sandbox environments is completely parallel, significantly shortening the environment preparation time. During operation, the startup status of each instance is monitored, and subsequent operations are only performed after all three database instances have successfully started and entered a ready state. If the creation of any database instance fails, this application will immediately clean up all created resources and report the error to the user. The initialization operations include: basic object creation, i.e., creating the database schema or database user required for testing; permission configuration, i.e., granting the necessary DDL and DML permissions to the test user to ensure that subsequent scripts can execute table structure changes and data operations; character set setting, i.e., configuring the database character set to UTF-8 to ensure the correct storage of multilingual data; and connection parameter optimization, i.e., setting reasonable connection timeouts and transaction isolation levels. The above initialization operations are executed in parallel in the three databases, and the atomicity of the operation process is ensured through a transaction mechanism. After initialization, connection tests and basic functional verifications are performed on each database to confirm that the database is in a state where SQL scripts can be executed normally. Then, the complete historical script sequence is executed in parallel in the three sandbox environments. First, the device receives a pre-calculated complete script execution sequence from the artifact binding module. This sequence contains all historical scripts from the initial baseline version to the current target version (excluding newly added scripts). The execution process employs a strict sequential control mechanism: script sequence loading, where device 53 sorts scripts according to artifact dependency order and script creation time to generate a complete historical script execution queue; parallel execution control, where for each script in the queue, SQL statements corresponding to the database type are simultaneously sent to three sandbox environments: MySQL, Oracle, and PostgreSQL; script-by-script verification, where after each script is executed, the execution results of the three databases are checked, and the next script is only executed if all databases return a success status; and failure-based stop, where if any database fails to execute a historical script, all subsequent executions are immediately stopped, the current environment is preserved for problem diagnosis, and a detailed error report is generated. Then, the SQL statements are executed through the `executeUpdate()` or `execute()` methods of the database connection driver, capturing the execution results and error information returned by the database. For each script execution, this application records a detailed execution log, including script content, start time, end time, execution time, number of affected rows, and returned messages. These log messages will be compiled into the final verification report for user analysis and review. After all historical scripts have been executed, the structure and data state of the three sandbox databases should be completely identical (except for database system-specific system tables and metadata). At this point, the database state represents the baseline state of the target version.

[0062] Then, the newly added script was executed in parallel in three sandbox environments. The three submitted script files (MySQL, Oracle, and PostgreSQL versions) were retrieved, and the corresponding SQL statements were sent to the three sandbox databases simultaneously. The execution process was similar to previous script executions, but with more detailed result verification: execution result capture, which records detailed execution results returned by each database, including the number of tables created, modified fields, added indexes, and other structural change information; cross-database consistency verification, which compares whether the structural changes after execution in the three databases are consistent, for example, whether tables created in MySQL are also successfully created in Oracle and PostgreSQL, and whether the number and types of fields match; data integrity check, which verifies the integrity and correctness of data migration for scripts involving data migration; and performance metric collection, which records the execution time of the script in different databases to identify potential performance issues. After execution, a final comprehensive evaluation of the results is required: if all three databases execute successfully and the structural changes are consistent, the sandbox pre-execution verification is considered passed; if any database fails to execute or the structural changes are inconsistent, the verification is considered failed, a detailed error report containing error details, failure reasons, and repair suggestions is generated, and the script status is marked as "sandbox verification failed," preventing the script from entering the subsequent review process. After sandbox pre-execution verification is completed, all temporarily created sandbox environments are automatically cleaned up, releasing database instance resources and storage space to ensure efficient utilization of system resources. Verification logs and execution reports are permanently stored in the audit log system for subsequent querying and analysis. In this way, by adopting the sandbox pre-execution verification mechanism, executing the complete historical script sequence plus the newly added script starting from an empty database, the limitations of traditional static syntax checking are overcome, enabling the detection of dependency errors, data conflicts, and business logic problems between scripts, thus improving the reliability of script verification.

[0063] Step S14: Verify the script deployment sandbox simulation results based on the preset audit verification method.

[0064] In this embodiment, the verification of the script deployment sandbox simulation results based on the preset audit verification method includes: generating a script execution audit package based on the script deployment sandbox simulation results, and sending the script execution audit package to the visualization interface to obtain the user's audit results for the script deployment sandbox simulation results. Specifically, the script status is first updated from "in sandbox verification" to "pending audit". A complete script execution audit package is generated, which specifically includes: basic script information (script name, creator, creation time, associated artifacts and versions); script content display (SQL statements for MySQL, Oracle, and PostgreSQL versions are displayed in code highlighting); sandbox verification report (containing detailed execution logs, execution time, and structural change information for the three databases); impact scope analysis (automatically analyzing the impact scope of changes based on the script content, identifying modified tables, fields, indexes, and other objects); and a list of associated environments (listing all environments that reference the artifact, showing the target environment to be deployed to after the script audit is passed). The review materials package is then pushed to the component owner's to-do list, and system notification mechanisms (such as email, DingTalk, etc.) are used to remind reviewers that a new script is pending review, awaiting their approval decision. During the review process, reviewers can: view complete review materials; browse all review information; check the script's rationality and assess whether the database structure change meets business needs from a business perspective; assess change risks and, combined with impact scope analysis, evaluate the potential business risks of the change; and refer to historical cases to view historical review records and execution results of similar changes. When the reviewer clicks the "Approve" button, the script status is updated to "Approved," the reviewer, review time, and review comments are recorded, and control is transferred to the automatic execution judgment module, triggering the automatic deployment process. When the reviewer clicks the "Disapproved" button, the script status is updated to "Disapproved," the reason for rejection and modification suggestions are recorded, and the script is returned to the creator. The process ends directly, and the script creator needs to modify the script content or adjust the change plan according to the review comments, and then resubmit a new script to enter the review process.

[0065] After approval, the automated execution judgment module attempts to automatically deploy the script to all associated environments and determines process branches based on the execution results. Upon receiving the approval status, it executes the script deployment operation on all environments referencing the artifact. The automated execution process includes: environment list retrieval (querying the artifact management module to find all environments referencing the artifact); parallel deployment control (using a parallel deployment strategy for multiple environments, simultaneously sending SQL execution commands to each environment's database); execution status monitoring (monitoring the script execution status of each environment in real time, collecting execution results and error information); and result summary statistics (counting the number of successfully deployed environments and the number of failed environments). Finally, the automated deployment results are judged: if all environments execute the script successfully, the script status is updated to "deployed," the deployment completion time and the list of deployed environments are recorded, and the process ends normally; if any environment fails to execute, the script status is updated to "automatic execution failed," the failure scenario and error logs are preserved, and control is transferred to the reviewers. Specifically, it displays detailed information such as error logs, error codes, and failure times for each failed environment; allows administrators to query the database connection status, permission configuration, and resource usage of failed environments; after troubleshooting, administrators can manually trigger script re-execution in failed environments through the interface; for special cases (such as temporary environment unavailability or needing to skip execution), administrators can manually mark the script's execution status in that environment as "executed" or "skipped"; if script execution causes environment anomalies, administrators can trigger a script rollback operation to restore the state before execution. This application sets up an operation log to record all administrator interventions in detail, including operation type, operation time, and operation reason, ensuring complete audit traceability of the change process. After the administrator has completed the handling of all failed environments, they can manually confirm the deployment completion, and the process finally ends.

[0066] Step S15: If the script deployment sandbox simulation result passes the verification, then the current script to be deployed is determined from the complete script based on the current deployment environment of the target artifact, and the current script to be deployed is deployed to the current deployment environment.

[0067] In this embodiment, determining the current deployment script from the complete script based on the current deployment environment of the target artifact and deploying the current deployment script to the current deployment environment includes: determining whether there is relevant script deployment information for the target artifact in the script execution history of the current deployment environment; if there is no relevant script deployment information for the target artifact in the script execution history, then determining the complete script as the current deployment script based on the script execution sequence corresponding to the complete script and deploying the current deployment script to the current deployment environment; if there is relevant script deployment information for the target artifact in the script execution history, then determining the current deployment script from the complete script based on the relevant script deployment information and deploying the current deployment script to the current deployment environment; the difference between the complete script and the script corresponding to the relevant script deployment information is the current deployment script.

[0068] When deploying environment information, the system first queries the artifact reference relationship table in the artifact management module to obtain a list of all environments that reference the artifact. The environment list includes: environment identifier and name, such as DEV-01 (development environment 1), TEST-02 (test environment 2), PROD-01 (production environment 1), etc.; environment type, such as development environment, test environment, pre-production environment, production environment; environment status, such as running, stopped, under maintenance, etc.; database connection information, such as database type, IP address, port, database name, and connection credentials; and artifact version information, such as the artifact version number currently running in the environment. After obtaining the environment list, the system creates an independent deployment task thread for each environment. Subsequent judgment and execution operations will be performed in parallel within their respective threads, significantly improving the efficiency of multi-environment deployment. During deployment, the system first determines whether each environment is deploying the artifact for the first time. The first deployment judgment device 72 receives the environment list transmitted by the scanning reference environment device 71, queries the script execution history table for each environment, and checks whether any script execution records for the artifact exist in that environment. The judgment logic is as follows: if there is no execution record of the artifact in the script execution history table of the environment, or the artifact version field of the environment is empty, it is determined to be the first deployment (yes); if the script execution record of the artifact already exists in the environment, it means that the artifact has been deployed in this environment before, and it is determined to be a non-first deployment (no).

[0069] For environments deployed for the first time, it is necessary to start from an empty database state and execute all historical scripts of the artifact from the initial baseline version to the current latest version (including the scripts added this time).

[0070] The full execution process includes: calculating the complete script set, calling the dependency resolution function of the artifact binding module to calculate the complete script sequence of the artifact and all its dependent artifacts, and generating an execution queue according to version dependency order and script creation time; establishing a database connection, using the corresponding database connection driver to establish a connection to the target environment database based on the database type of the environment (MySQL, Oracle, or PostgreSQL); executing scripts sequentially, executing the SQL statements corresponding to the database type version of each script one by one according to the order of the execution queue; immediately inserting a record into the script execution history table after each script is executed, marking that the script has been completed in this environment, recording information such as execution time, execution result, and number of rows affected; and error handling, if a script fails to execute, immediately stopping the execution of subsequent scripts, rolling back the current transaction, recording detailed error information, and reporting the failure.

[0071] After the full script execution is complete, the database structure of this environment will be completely consistent with the latest version, the artifact version field of the environment will be updated to the latest version number, and the process will end. For environments that are not being deployed for the first time, it is necessary to determine whether there are any new scripts that need to be executed in this environment.

[0072] The judgment logic is as follows: Obtain the list of executed scripts in the environment; query the script execution history table to find all script IDs (unique identifiers) that have been executed in this environment for this artifact. Obtain the complete script list for the artifact; query the script management repository to find all currently approved script IDs for this artifact. Calculate the difference script set; perform a difference calculation between the complete script list for the artifact and the list of executed scripts in the environment to obtain the set of new scripts that have not yet been executed in this environment. Sort the difference scripts; sort the difference script set by script creation time to generate an incremental execution queue. The judgment result is: if the difference script set is empty, it means that all scripts for this artifact have been executed in this environment, and no further action is needed; the process ends directly. If the difference script set is not empty (yes), it means that there are new scripts that need to be executed.

[0073] The incremental execution process is essentially the same as the full execution process of historical scripts, with the following differences: Execution scope: only newly added scripts in the incremental execution queue are executed; previously executed historical scripts are not repeated. Initial database state: the environment database already contains the table structure and data from previous versions; new scripts typically involve incremental changes to the existing structure. Compatibility verification: the execution of incremental scripts must ensure compatibility with the existing database structure to avoid conflicts and data loss. After all newly added scripts have been executed, the script execution history table is updated to mark these scripts as completed in this environment, and the process ends.

[0074] This approach executes all historical scripts for newly deployed environments and only incremental scripts for already deployed environments, ensuring that the database state and artifact version remain consistent across all environments while avoiding duplicate executions and resource waste. Through an intelligent incremental synchronization algorithm, the system automatically identifies differences in script execution status across environments, executing all historical scripts for newly deployed environments and only incremental scripts for already deployed environments, reducing manual intervention and the risk of errors by operations personnel.

[0075] As can be seen, in this embodiment, a database change script for a target artifact sent by the user is obtained, and data is extracted from the database change script to obtain a target script identifier and artifact version information; based on the target script identifier and the artifact version information, a complete script corresponding to the database change script is determined, and a script execution sequence corresponding to the complete script is generated based on the artifact version information; the complete script contains the database change script; a script deployment environment corresponding to the complete script is generated in a preset sandbox, and the deployment of the complete script is executed in the preset sandbox based on the script execution sequence to obtain a script deployment sandbox simulation result; the script deployment sandbox simulation result is verified based on a preset audit and verification method; if the script deployment sandbox simulation result passes the verification, a current script to be deployed is determined from the complete script based on the current deployment environment of the target artifact, and the current script to be deployed is deployed to the current deployment environment. That is, a corresponding complete script is generated based on the database change script sent by the user and the version information contained in the database change script; the complete script is simulated using a simulation sandbox environment, and finally, if the simulation result passes the verification, the script is deployed accordingly. This achieves a complete automated closed-loop process from script creation to development and deployment, ensuring consistency and security of script execution across multiple database types and environments.

[0076] refer to Figure 4 The present application also discloses a database script deployment device, comprising:

[0077] The script acquisition module 11 is used to acquire the database change script sent by the user terminal for the target product, and to extract data from the database change script to obtain the target script identifier and product version information.

[0078] The script execution sequence determination module 12 is used to determine the complete script corresponding to the database change script based on the target script identifier and the product version information, and to generate the script execution sequence corresponding to the complete script based on the product version information; the complete script includes the database change script;

[0079] The sandbox simulation module 13 is used to generate a script deployment environment corresponding to the complete script in a preset sandbox, and to execute the deployment of the complete script in the preset sandbox based on the script execution sequence, so as to obtain the script deployment sandbox simulation result;

[0080] Script verification module 14 is used to verify the script deployment sandbox simulation results based on a preset audit verification method;

[0081] The script deployment module 15 is used to determine the current script to be deployed from the complete script based on the current deployment environment of the target artifact if the script deployment sandbox simulation result passes the verification, and to deploy the current script to be deployed to the current deployment environment.

[0082] As can be seen, in this embodiment, a complete script is generated based on the database change script sent by the user and the version information contained in the database change script; the complete script is simulated using a simulation sandbox environment; and finally, the script is deployed after the simulation results are verified. This achieves a complete automated closed-loop process from script creation to development and deployment, ensuring consistency and security of script execution across multiple database types and environments.

[0083] In some specific embodiments, the script acquisition module 11 may specifically include:

[0084] The component acquisition unit is used to acquire the application components selected by the user on the visual interface; the application components are stored in a preset component management repository and displayed in a list form on the visual interface.

[0085] The target artifact determination unit is used to determine the target artifact based on the application component and to retrieve all historical scripts and historical version information of the target artifact.

[0086] The script acquisition unit is used to acquire the database change script sent by the user terminal for the target product based on the preset script upload interface, so as to obtain the target script identifier and product version information; the database change script includes database scripts corresponding to several types of databases.

[0087] In some specific embodiments, the database script deployment device may further include:

[0088] The script verification module is used to perform basic verification on the database change script. The basic verification includes: determining whether the database change script contains scripts corresponding to all target database types, whether the syntax format and operation type of the database change script conform to preset standards, and whether the database change script contains risky operation behaviors. The risky operation behaviors are pre-set prohibited operation behaviors.

[0089] The script storage module is used to store the database change script, all historical scripts, and historical version information in the preset component management repository if the database change script passes the basic verification.

[0090] In some specific embodiments, the script execution sequence determination module 12 may specifically include:

[0091] An information binding unit is used to bind the target script identifier and the product version information to the target product;

[0092] The script determination unit is used to determine the target script to be processed from all historical scripts corresponding to the target product based on the target script identifier, the product version information, and the historical version information; the historical version information corresponding to the target script to be processed has a version dependency relationship with the product version information of the database change script;

[0093] The sequence generation unit is used to determine the complete script based on the database change script and the target script to be processed, and to generate the script execution sequence corresponding to the complete script based on the product version information.

[0094] In some specific embodiments, the sandbox simulation module 13 may specifically include:

[0095] An environment initialization unit is used to perform initialization processing on a preset sandbox based on each database type corresponding to the complete script, so as to generate a script deployment environment corresponding to the complete script in the preset sandbox respectively;

[0096] The script simulation unit is used to sequentially execute the deployment of the historical script in the complete script in the preset sandbox based on the script execution sequence to obtain a first simulation result, and then execute the deployment of the database change script in the preset sandbox to obtain a second simulation result;

[0097] The result determination unit is used to determine the first simulation result and the second simulation result as the script deployment sandbox simulation result.

[0098] In some specific embodiments, the script verification module 14 may specifically include:

[0099] The script review unit is used to generate a script execution review package based on the script deployment sandbox simulation results, and send the script execution review package to the visualization interface to obtain the review results of the user terminal for the script deployment sandbox simulation results.

[0100] In some specific embodiments, the script deployment module 15 may specifically include:

[0101] The information judgment unit is used to determine whether there is relevant script deployment information for the target artifact in the script execution history of the current deployment environment;

[0102] The first script deployment unit is configured to, if there is no relevant script deployment information for the target artifact in the script execution history, determine the complete script as the current script to be deployed based on the script execution sequence corresponding to the complete script, and deploy the current script to be deployed to the current deployment environment.

[0103] The second script deployment unit is configured to determine the current script to be deployed from the complete script based on the relevant script deployment information if the script execution history contains relevant script deployment information for the target artifact, and deploy the current script to be deployed to the current deployment environment; the difference between the complete script and the script corresponding to the relevant script deployment information is the current script to be deployed.

[0104] Furthermore, embodiments of this application also disclose an electronic device, Figure 5 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.

[0105] Figure 5 This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the database script deployment method disclosed in any of the foregoing embodiments. Alternatively, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0106] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0107] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 221, computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0108] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the database script deployment method executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include a computer program capable of performing other specific tasks.

[0109] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned disclosed database script deployment method. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0110] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0111] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0112] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

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

[0114] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A database script deployment method, characterized in that, include: The system obtains the database change script sent by the user terminal for the target product, and extracts data from the database change script to obtain the target script identifier and product version information. Based on the target script identifier and the product version information, determine the complete script corresponding to the database change script, and generate the script execution sequence corresponding to the complete script based on the product version information; The complete script includes the database change script; A script deployment environment corresponding to the complete script is generated in a preset sandbox, and the deployment of the complete script is executed in the preset sandbox based on the script execution sequence to obtain the script deployment sandbox simulation results; The script deployment sandbox simulation results are verified based on a preset audit and verification method. If the script deployment sandbox simulation results pass the verification, then the current script to be deployed is determined from the complete script based on the current deployment environment of the target artifact, and the current script to be deployed is deployed to the current deployment environment.

2. The database script deployment method according to claim 1, characterized in that, The step of obtaining the database change script sent by the user terminal for the target product, and extracting data from the database change script to obtain the target script identifier and product version information, includes: The application components selected by the user on the visual interface are obtained; the application components are stored in a preset component management repository and displayed in a list on the visual interface. The target artifact is determined based on the application components, and all historical scripts and version information of the target artifact are retrieved. The database change script sent by the user terminal for the target product is obtained based on the preset script upload interface, so as to obtain the target script identifier and product version information; the database change script includes database scripts corresponding to several types of databases.

3. The database script deployment method according to claim 2, characterized in that, After obtaining the database change script for the target product sent by the user terminal based on the preset script upload interface, the process also includes: The database change script is subjected to basic verification. The basic verification includes: determining whether the database change script contains scripts corresponding to all target database types, whether the syntax format and operation type of the database change script conform to preset standards, and whether the database change script contains risky operation behaviors; the risky operation behaviors are pre-set prohibited operation behaviors. If the database change script passes the basic verification, the database change script, all historical scripts, and historical version information are stored in the preset component management repository.

4. The database script deployment method according to claim 2, characterized in that, The step of determining the complete script corresponding to the database change script based on the target script identifier and the artifact version information, and generating the script execution sequence corresponding to the complete script based on the artifact version information, includes: The target script identifier and the product version information are bound to the target product. The target script to be processed is determined from all historical scripts corresponding to the target script based on the target script identifier, the product version information, and the historical version information; the historical version information corresponding to the target script to be processed has a version dependency relationship with the product version information of the database change script; The complete script is determined based on the database change script and the target script to be processed, and the script execution sequence corresponding to the complete script is generated based on the artifact version information.

5. The database script deployment method according to claim 2, characterized in that, The process of generating a script deployment environment corresponding to the complete script in a preset sandbox, and deploying the complete script in the preset sandbox based on the script execution sequence to obtain script deployment sandbox simulation results includes: The preset sandbox is initialized based on the database types corresponding to the complete script, so as to generate the script deployment environment corresponding to the complete script in the preset sandbox respectively; Based on the script execution sequence, the deployment of the historical script in the complete script is executed sequentially in the preset sandbox to obtain a first simulation result. Then, the deployment of the database change script is executed in the preset sandbox to obtain a second simulation result. The first simulation result and the second simulation result are determined as the script deployment sandbox simulation results.

6. The database script deployment method according to claim 2, characterized in that, The verification of the script deployment sandbox simulation results based on the preset audit and verification method includes: Based on the script deployment sandbox simulation results, a script execution audit package is generated and sent to the visualization interface to obtain the user's audit results for the script deployment sandbox simulation results.

7. The database script deployment method according to any one of claims 2 to 6, characterized in that, The step of determining the current deployment script from the complete script based on the target artifact's current deployment environment and deploying the current deployment script to the current deployment environment includes: Determine whether the script execution history of the target artifact exists in the current deployment environment; If the script execution history does not contain any script deployment information related to the target artifact, then the complete script is determined as the current script to be deployed, based on the script execution sequence corresponding to the complete script, and the current script to be deployed is deployed to the current deployment environment. If the script execution history contains script deployment information related to the target artifact, then the current script to be deployed is determined from the complete script based on the relevant script deployment information, and the current script to be deployed is deployed to the current deployment environment; the difference between the complete script and the script corresponding to the relevant script deployment information is the current script to be deployed.

8. A database script deployment device, characterized in that, include: The script acquisition module is used to acquire the database change script sent by the user terminal for the target product, and to extract data from the database change script to obtain the target script identifier and product version information. The script execution sequence determination module is used to determine the complete script corresponding to the database change script based on the target script identifier and the product version information, and to generate the script execution sequence corresponding to the complete script based on the product version information; The complete script includes the database change script; The sandbox simulation module is used to generate a script deployment environment corresponding to the complete script in a preset sandbox, and to execute the deployment of the complete script in the preset sandbox based on the script execution sequence, so as to obtain the script deployment sandbox simulation result; The script verification module is used to verify the script deployment sandbox simulation results based on a preset audit verification method; The script deployment module is used to determine the current script to be deployed from the complete script based on the current deployment environment of the target artifact if the script deployment sandbox simulation result passes the verification, and then deploy the current script to be deployed to the current deployment environment.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the database script deployment method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Used to store computer programs, which, when executed by a processor, implement the database script deployment method as described in any one of claims 1 to 7.

Images