Data processing method and device, equipment, storage medium and program product

Abstract

This application provides a data processing method, apparatus, device, storage medium, and program product, relating to the fintech field or other related fields. The method includes: capturing corresponding deployment operation events for target deployment content submitted by a user; parsing the deployment operation events into a structured operation tree; and finally generating verification cases for the target deployment content based on the structured operation tree. By combining an event-driven architecture with dynamic version verification rules, the automation level and accuracy of the verification process are significantly improved, solving the problems of incomplete coverage, low efficiency, and rigid version verification in traditional verification models, and meeting the needs of integrated development and operations environments for high-frequency deployment and rapid iteration.

Description

Technical Field

[0001] This application relates to the field of financial technology or other related fields, and in particular to a data processing method, apparatus, device, storage medium and program product. Background Technology

[0002] In a DevOps environment, software development teams need to frequently iterate and continuously deploy software products and features. This is especially true for fintech software products. Currently, to ensure functional security, developers typically need to manually write verification cases, import them into the system, and then execute tests one by one.

[0003] The existing methods for generating verification cases suffer from low efficiency and poor accuracy in generating verification cases. Summary of the Invention

[0004] This application provides a data processing method, apparatus, device, storage medium, and program product to solve the problems of low efficiency and poor accuracy in generating verification cases.

[0005] Firstly, this application provides a data processing method, including:

[0006] The system obtains the target deployment content submitted by the user and captures the deployment operation events corresponding to the deployment content in real time through an event-driven architecture; it parses the deployment operation events into a structured operation tree, which contains the operation type, operation parameters and dependencies corresponding to the deployment operation events; and it generates verification cases for the target deployment content based on the structured operation tree.

[0007] Secondly, this application provides a data processing apparatus, comprising:

[0008] The acquisition module is used to acquire the target deployment content submitted by the user and capture the deployment operation events corresponding to the deployment content in real time through an event-driven architecture.

[0009] The parsing module is used to parse the deployment operation event into a structured operation tree, wherein the structured operation tree contains the operation type, operation parameters and dependencies corresponding to the deployment operation event;

[0010] The processing module is used to generate verification cases for the target deployment content based on the structured operation tree.

[0011] Thirdly, this application provides an electronic device, including: a processor and a memory communicatively connected to the processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory to implement the data processing method provided in any of the implementations of the first aspect above.

[0012] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the data processing method provided in any of the implementations of the first aspect above.

[0013] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the data processing method provided by any of the implementations of the first aspect above.

[0014] The image processing method, apparatus, device, storage medium, and program product provided in this application capture corresponding deployment operation events for user-submitted target deployment content, parse the deployment operation events into a structured operation tree, and finally generate verification cases for the target deployment content based on the structured operation tree. By combining an event-driven architecture with dynamic version verification rules, the automation level and accuracy of the verification process are significantly improved, solving the problems of incomplete coverage, low efficiency, and rigid version verification in traditional verification models, and meeting the needs of integrated development and operations environments for high-frequency deployment and rapid iteration. Attached Figure Description

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

[0016] Figure 1 A schematic diagram illustrating a common scenario for continuous integration / continuous deployment provided by an embodiment of this disclosure;

[0017] Figure 2 A flowchart illustrating a data processing method provided in an embodiment of this disclosure;

[0018] Figure 3 for Figure 2 A flowchart illustrating the specific implementation of step S102 in the illustrated embodiment;

[0019] Figure 4 A flowchart illustrating another data processing method provided in an embodiment of this disclosure;

[0020] Figure 5 This is a structural block diagram of the image processing apparatus provided in the embodiments of this application;

[0021] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0022] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0023] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0024] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize or refuse.

[0025] Furthermore, the technical solution involved in this application, which involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.) and the use of artificial intelligence technology for automated decision-making, and makes decisions that have a significant impact on personal rights based on the results of automated decision-making, provides users with corresponding operation entry points for users to choose to agree to or reject the results of automated decision-making; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0026] It should be noted that the data processing methods, apparatus, devices, storage media, and program products provided in this application can be used in the fintech field, or in any field other than fintech. The application fields of the data processing methods, apparatus, devices, storage media, and program products in the embodiments of this application are not limited.

[0027] This application is applicable to continuous integration / continuous deployment (CI / CD) scenarios in development and operations integrated environments, especially in industries such as banking and finance where system stability requirements are extremely high. Figure 1This is a schematic diagram illustrating a common scenario for continuous integration / continuous deployment provided in an embodiment of this disclosure, such as... Figure 1 As shown, in continuous integration / continuous deployment application scenarios, the process begins with developers submitting code to repositories such as Git. Next, code testing is performed, including automated code style checks, static code analysis, and unit tests to quickly identify code defects in the early stages of integration. Then, automated builds are executed, including automatically pulling code, compiling, and packaging. Following this, test environment deployment and verification are performed, deploying the build artifacts to the test environment for integration and API testing to verify functionality and compatibility. Only after these tests pass can the next stage be initiated. Finally, if verification succeeds, the product is deployed to the production environment for production release and monitoring; otherwise, adjustments are made.

[0028] In a DevOps environment, software development teams need to frequently iterate versions and continuously deploy to quickly respond to business needs and fix issues. Traditional verification processes typically rely on manual operations: developers must manually write verification cases, import them into the system, and execute tests one by one (including integration testing, canary testing, and post-release monitoring testing). This model faces significant challenges in scenarios with short software delivery cycles and high deployment frequency. For example, when upgrading a banking system, developers need to write verification cases for each deployed microservice or configuration change, covering all scenarios that might affect business logic (such as database script changes, configuration file adjustments, batch task scheduling, etc.). However, manually writing cases can easily overlook critical scenarios, leading to undiscovered potential risks; simultaneously, case writing and execution are time-consuming (each case takes 2-3 hours) and cannot be processed in parallel, severely impacting deployment efficiency. Furthermore, traditional verification models lack a real-time verification mechanism for deployed versions, resulting in delayed problem detection and potentially causing production environment failures.

[0029] The data processing method provided in this application aims to solve the above-mentioned technical problems of the prior art.

[0030] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0031] Figure 2 This is a flowchart illustrating a data processing method provided in an embodiment of the present disclosure, as shown below. Figure 2 As shown, exemplarily, it includes:

[0032] Step S101: Obtain the target deployment content submitted by the user, and capture the deployment operation events corresponding to the deployment content in real time through an event-driven architecture.

[0033] Step S102: Parse the deployment operation event into a structured operation tree, which contains the operation type, operation parameters and dependencies corresponding to the deployment operation event.

[0034] Step S103: Generate validation cases for the target deployment content based on the structured operation tree.

[0035] For example, refer to Figure 1 The illustrated application scenario diagram shows that after a user submits target deployment content, such as submitting program code to a code repository or deploying build artifacts to a test environment, the system uses an event-driven architecture to capture deployment operation events corresponding to the deployment content in real time. Event-driven architecture is a system design pattern that triggers subsequent operations by listening to and processing events, used to respond to deployment operation events in real time. For example, in a CI / CD tool, the system listens for the "PaaS resource deployment" event and triggers subsequent parsing processes. Deployment operation events are identifiable operations that occur in the continuous deployment pipeline, such as resource deployment and configuration updates. For example, when a developer submits a deployment request containing database script updates, the "database script execution" event is triggered. Exemplarily, deployment operation events include at least one of the following: PaaS resource deployment, environment variable change, configuration file update, database script execution, batch task scheduling, and infrastructure adjustment.

[0036] Next, the deployment operation events are parsed to generate a data body with a specific data structure, namely a structured operation tree. This structured operation tree includes the operation type, operation parameters, and dependencies corresponding to the deployment operation events. Specifically, the deployment operation events in the CI / CD tool are monitored in real time through an event-driven architecture, and the original deployment description (such as a YAML configuration file) is parsed into a structured operation tree. The structured operation tree includes the operation type (such as PaaS resource deployment, configuration file update), parameters (such as resource type = MySQL, file path = config.yaml), and dependencies (such as environment variable changes in microservice A depend on configuration file updates). The verification case generation module extracts the operation type, parameters, and dependencies from each node in the structured operation tree to generate corresponding verification cases. For example, for the "PaaS resource deployment" node, the case "verify that the MySQL service image version is consistent with the production environment" is generated; for the "configuration file update" node, the case "check whether the parameters in config.yaml are effective" is generated. The entire process, through the combination of an event-driven architecture and a structured operation tree, achieves fully automated generation of verification cases from deployment operations.

[0037] The data processing method provided in this embodiment captures deployment operation events in real time through an event-driven architecture, parses the deployment content into a structured operation tree, and generates verification cases based on the operation tree, solving the problem of incomplete coverage in traditional manually written verification cases. The event-driven architecture ensures that all critical operations are captured in real time by listening to deployment events in CI / CD tools (such as PaaS resource deployment and database script execution), avoiding omissions due to human error. The structured operation tree, by hierarchically representing operation types, parameters, and dependencies, provides accurate input for verification case generation, ensuring that each operation scenario is covered. The verification case generation module dynamically generates corresponding verification cases based on the metadata of the operation tree (such as operation type, parameters, and dependencies), for example, generating a case for "checking whether parameters are effective" for "configuration file update". This technique decouples deployment operations from verification logic, dynamically adapts to complex deployment scenarios (such as microservice chained updates), significantly improves the comprehensiveness of verification cases, ensures that all deployment operations are verified, and thus reduces potential risks.

[0038] Furthermore, in one possible implementation, such as Figure 3 As shown, the specific implementation of step S102 includes:

[0039] Step S1021: Obtain the event type corresponding to the deployment operation event.

[0040] Step S1022: Determine the operation type, operation parameters, and dependencies based on the event type.

[0041] Step S1023: Construct a structured operation tree containing hierarchical relationships based on the operation type, operation parameters, and dependencies.

[0042] For example, the event type refers to the classification identifier of the deployment operation event, such as "PaaS resource deployment" or "configuration file update". The event type is associated with the operation type; the event type corresponds to a specific "purpose," while the operation type corresponds to a specific "means." More specifically, for example, when the event type is "PaaS resource deployment," the corresponding operation type is "create a MySQL service instance." The operation parameters are the specific configuration parameters corresponding to the operation type. Dependency refers to the order or association between operations, such as "environment variable changes in microservice A depend on configuration file updates." For example, the dependency "environment variable changes in microservice A depend on configuration file updates" means that environment variable changes can only be performed after the configuration file is updated.

[0043] When parsing deployment operation events, the system first extracts the operation type (e.g., "Create MySQL service instance"), parameters (e.g., "Resource type = MySQL"), and dependencies (e.g., "Environment variable change for microservice A depends on configuration file update") based on the event type (e.g., "PaaS resource deployment"). Then, the system constructs the extracted metadata into a hierarchical structured operation tree, where each node contains the operation type, parameters, and dependencies, ensuring the integrity of the operation logic. For example, for the "configuration file update" event, the system extracts the operation type "file update," the parameter "file path = config.yaml," and the dependency "Microservice B's database script execution depends on this configuration," and organizes these into operation tree nodes.

[0044] In this embodiment, a precise structured operation tree is constructed by further extracting event types, parameters, and dependencies. This step decomposes deployment operation events into operable metadata (such as operation type, parameters, and dependencies), ensuring that the structured operation tree fully reflects the deployment logic, thereby providing more accurate input for subsequent verification case generation. For example, in a microservice chained update scenario, dependency extraction ensures that verification cases cover all related operations, avoiding verification omissions due to incorrect operation order.

[0045] Furthermore, in this embodiment, the deployment operation event includes at least two refined sub-operation events;

[0046] Following step S101, this embodiment further includes:

[0047] Step S101A: Based on context information, identify the target sub-operation event with high-risk operation.

[0048] Accordingly, the specific implementation of step S102 includes:

[0049] Step S102A: Parse the target sub-operation event into a structured operation tree.

[0050] For example, context information refers to associated data of deployment operations, such as operation dependencies and historical change records. Context information can be pre-generated; the specific generation method and content of context information are not described here. For instance, in a microservice chained update scenario, the system refines the deployment operation event "configuration update" into two sub-operation events: "configuration update of microservice A" and "configuration update of microservice B." Simultaneously, the system identifies high-risk operations based on context information (such as operation dependencies and historical change records) and refines the event type. For example, if historical data indicates that "configuration file update" frequently causes production environment failures, the system refines this event type to "configuration file update of microservice B," thus identifying it as the target sub-operation event. Then, based on this target sub-operation event, a structured operation tree is parsed to ensure that critical operations are verified individually. The specific implementation method for generating the structured operation tree can be found in the relevant descriptions in previous embodiments.

[0051] Through the steps of this embodiment, the verification coverage accuracy in complex scenarios is further improved by dynamically adjusting the event capture granularity and context awareness mechanism. By refining the event types of high-risk operations, it is ensured that each operation is verified individually, avoiding coverage omissions caused by event aggregation.

[0052] Figure 4 This is a flowchart illustrating another data processing method provided in an embodiment of the present disclosure. Figure 2 Based on the illustrated embodiment, a verification step for executing verification cases has been added, such as... Figure 4 As shown, exemplarily, it includes:

[0053] Step S201: Obtain the target deployment content submitted by the user, and capture the deployment operation events corresponding to the deployment content in real time through an event-driven architecture.

[0054] Step S202: Parse the deployment operation event into a structured operation tree, which contains the operation type, operation parameters and dependencies corresponding to the deployment operation event.

[0055] Step S203: Generate validation cases for the target deployment content based on the structured operation tree.

[0056] Step S204: Obtain the task template type corresponding to the verification case.

[0057] Step S205: Determine the corresponding version verification strategy based on the task template type.

[0058] Step S206: Generate a verification version number based on the version verification strategy. The verification version number is used to represent the version of the target deployed content.

[0059] For example, template type refers to the classification identifier of the deployment template, such as "grayscale template" or "non-grayscale template". Grayscale templates are used for phased releases of new versions, while non-grayscale templates are used for full releases. The version verification strategy selected based on the template type is, for example, "grayscale templates use the latest build version number" or "non-grayscale templates combine a time window calculation model". More specifically, the version verification strategy for grayscale templates is "directly use the latest build version number from the CI / CD pipeline".

[0060] After generating validation cases, the system selects the corresponding version validation strategy based on the template type (e.g., "grayscale template" or "non-grayscale template"). For grayscale templates, the system directly uses the latest build version number of the CI / CD pipeline as the validation benchmark; for non-grayscale templates, the system combines a time window calculation model and a version number topology sorting mechanism to filter valid version numbers. For example, in a non-grayscale template scenario, the system first obtains the grayscale conversion date and the production launch date, establishes a time window (grayscale conversion date ≤ production launch date), and then scans the version sequence in reverse chronological order of release time to select the last release version number that meets the conditions.

[0061] In this embodiment, a differentiated version verification strategy is further adopted to adapt to complex deployment scenarios (such as canary releases and cross-day production deployments). This step ensures strict synchronization between the verification environment and the production environment by dynamically matching version numbers, avoiding verification failures due to version number misjudgments. For example, in cross-day production deployment scenarios, the combination of a time window calculation model and a topology sorting mechanism can accurately filter valid version numbers, improving the reliability of verification results.

[0062] Among them, the corresponding version verification strategy is determined according to the task template type, including at least one of the following: enabling a 24-hour time difference compensation algorithm in cross-day production scenarios; and filtering valid version numbers through a version number topology sorting mechanism.

[0063] For example, the 24-hour time difference compensation algorithm refers to automatically correcting the time difference between the gray-to-offline (GTO) date and the production date in cross-day production scenarios. For instance, if the GTO date is October 1, 2023, and the production date is October 2, 2023, the system corrects the GTO date to 23:59 on October 1, 2023. The version number topology sorting mechanism refers to arranging the version sequence in reverse chronological order of release time to ensure the latest valid version is selected. For example, in the version sequence v1.0.0 (September 30, 2023), v1.1.0 (October 1, 2023), and v1.2.0 (October 2, 2023), v1.2.0 is selected as the verification version. In cross-day production scenarios, the system uses the 24-hour time difference compensation algorithm to correct the GTO date to 23:59 of the day before the production date, ensuring the consistency of the version matching logic. Meanwhile, the system filters the version sequence using a version number topology sorting mechanism, arranging them in reverse chronological order by release date, and selecting the last version that meets the condition of "gray-to-offline date ≤ production launch date". For example, in a cross-day production launch scenario, after correcting the gray-to-offline date, the system selects version v1.2.0 as the verification version using the topology sorting mechanism. The time difference compensation algorithm and topology sorting mechanism address the version misjudgment problem in cross-day production launch scenarios and ensure the accuracy of the verification version number.

[0064] Optionally, after step S206, the method further includes:

[0065] Step S207: Create an asynchronous verification task based on the version verification strategy and the verification version number.

[0066] Step S208: Trigger the verification process for the verification case through an asynchronous verification task.

[0067] For example, after obtaining the version verification strategy and verification version number based on the previous steps, an asynchronous verification task is created according to the version verification strategy and verification version number. The verification process is then triggered through asynchronous check task scheduling. Here, the asynchronous verification task is a verification task that starts asynchronously. Asynchronous verification task scheduling means that the verification process is automatically triggered after the deployment pipeline is completed, avoiding blocking the main process execution. For example, after the deployment pipeline is completed, the system starts the verification task asynchronously without waiting for the main process to finish.

[0068] Optionally, the method further includes the following after step S208:

[0069] Step S209: Trigger the circuit breaker mechanism when the asynchronous verification task times out.

[0070] For example, when a verification task times out, the waiting is terminated and the task is marked as an exception, thus triggering the circuit breaker mechanism. For instance, if a verification task is not completed within 10 minutes, the system terminates the task and marks it as a timeout exception to prevent the verification process from becoming stuck.

[0071] In this embodiment, asynchronous scheduling and a circuit breaker mechanism are used to achieve real-time performance and robustness of the verification process. This step ensures that the verification process does not block the main deployment process through asynchronous task scheduling, while the circuit breaker mechanism prevents verification delays caused by system failures. For example, in high-concurrency deployment scenarios, asynchronous scheduling can ensure the priority execution of critical verification tasks, and the circuit breaker mechanism can handle abnormal tasks in a timely manner, avoiding resource waste.

[0072] In one possible implementation, prior to step S207, the following is also included:

[0073] Step S210: Based on the verification version number and the corresponding version verification strategy, construct the association information; based on the association information, verify the matching between the verification version number and the version verification strategy.

[0074] For example, the association information is a mapping relationship information that represents the correlation between the verification case and the execution result of the version verification strategy. By verifying the version number and the corresponding version verification strategy, the correlation between the verification version number and the execution result of the version verification strategy is constructed. Specifically, before triggering the verification process, the system associates the verification case with the execution result of the version verification strategy (such as verifying the version number v1.2.0) and generates a list of verification tasks. For example, the verification case "Check image version" is associated with the version number v1.2.0, generating the task "Verify whether the image version is v1.2.0", that is, verifying the matching of the verification version number and the version verification strategy.

[0075] The above-described steps achieve precise matching between verification cases and version verification strategies. This step, by associating verification cases with version numbers, ensures the relevance of the verification process and avoids invalid verifications caused by mismatches between version numbers and verification cases.

[0076] Optionally, after step S208, the method further includes:

[0077] Step S211: After generating the verification result corresponding to the verification case, obtain the responsible party corresponding to the verification case. The responsible party is the user who submitted or reviewed the target deployment content; send the verification result to the responsible party.

[0078] For example, after generating the verification task list, the system distributes the verification results to different roles, i.e., responsible parties, through a tiered push strategy. The responsible party is associated with the target deployment content, i.e., the user who submitted or reviewed the target deployment content. For instance, the development department receives public content containing the application group name and production version via email, while the application support manager receives detailed content containing result details and the support department via platform notification. This tiered push strategy achieves differentiated distribution of verification results. This step, by distributing verification results to different roles, ensures that key information (such as result details) is promptly communicated to relevant personnel, improving problem response efficiency.

[0079] In this embodiment, the specific implementation methods of steps S201-S203 are the same as those of... Figure 2 The specific implementation methods of steps S101-S103 in the illustrated embodiment are similar, and will not be repeated here.

[0080] Corresponding to the image processing method in the above embodiments, Figure 5 This is a structural block diagram of an image processing apparatus provided in an embodiment of this application. The method described in the above embodiments can be executed by this image processing apparatus, which can be implemented by software and / or hardware, and can be integrated into an electronic device with certain data processing capabilities. The electronic device may include, but is not limited to, mobile terminals with big data processing capabilities, as well as fixed terminals with big data processing capabilities such as desktop computers and supercomputers.

[0081] For ease of explanation, only the parts relevant to the embodiments of this application are shown. (Refer to...) Figure 5 The image processing device 3 includes:

[0082] The acquisition module 31 is used to acquire the target deployment content submitted by the user and capture the deployment operation events corresponding to the deployment content in real time through an event-driven architecture.

[0083] The parsing module 32 is used to parse deployment operation events into a structured operation tree, which contains the operation type, operation parameters and dependencies corresponding to the deployment operation events.

[0084] Processing module 33 is used to generate verification cases for the target deployment content based on the structured operation tree.

[0085] According to one or more embodiments of this application, the parsing module 32 is specifically used for: obtaining the event type corresponding to the deployment operation event; determining the operation type, operation parameters, and dependencies based on the event type; and constructing a structured operation tree containing hierarchical relationships based on the operation type, operation parameters, and dependencies.

[0086] According to one or more embodiments of this application, after generating a verification case for the target deployment content based on the structured operation tree, the processing module 33 is further configured to: obtain the task template type corresponding to the verification case, determine the corresponding version verification strategy based on the task template type, and generate a verification version number based on the version verification strategy, wherein the verification version number is used to characterize the version of the target deployment content.

[0087] According to one or more embodiments of this application, when the processing module 33 determines the corresponding version verification strategy based on the task template type, it is specifically used for at least one of the following: enabling a 24-hour time difference compensation algorithm in a cross-day production scenario; and filtering valid version numbers through a version number topology sorting mechanism.

[0088] According to one or more embodiments of this application, after generating a verification version number based on a version verification strategy, the processing module 33 is further configured to: create an asynchronous verification task based on the version verification strategy and the verification version number; trigger a verification process for the verification case through the asynchronous verification task; and trigger a circuit breaker mechanism when the asynchronous verification task times out.

[0089] According to one or more embodiments of this application, before creating an asynchronous verification task based on the version verification strategy and the verification version number, the processing module 33 is further configured to: construct association information based on the verification version number and the corresponding version verification strategy; and verify the matching of the verification version number and the version verification strategy based on the association information.

[0090] According to one or more embodiments of this application, the deployment operation event includes at least one of the following: PaaS resource deployment, environment variable change, configuration file update, database script execution, batch task scheduling, and infrastructure adjustment; the deployment operation event includes at least two refined sub-operation events; the parsing module 32 is further configured to: determine the target sub-operation event with high-risk operation based on context information; when parsing the deployment operation event into a structured operation tree, the parsing module 32 is specifically configured to: parse the target sub-operation event into a structured operation tree.

[0091] According to one or more embodiments of this application, the processing module is further configured to: after generating the verification result corresponding to the verification case, obtain the responsible object corresponding to the verification case, wherein the responsible object is the user who submitted or reviewed the target deployment content; and send the verification result to the responsible object.

[0092] The acquisition module 31, recognition module 32, processing module 33, and generation module are connected sequentially. The image processing device 3 provided in this embodiment can execute the technical solution of the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0093] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 6 As shown, the electronic device 4 includes:

[0094] Processor 41, and memory 42 communicatively connected to processor 41;

[0095] Memory 42 stores instructions executed by the computer;

[0096] The processor 41 executes computer execution instructions stored in the memory 42 to achieve, for example, Figures 2-4 The image processing method in the illustrated embodiment.

[0097] Optionally, the processor 41 and the memory 42 are connected via a bus 43.

[0098] For relevant instructions, please refer to the corresponding text. Figures 2-4 The relevant descriptions and effects of the steps in the corresponding embodiments are understood, and will not be elaborated on here.

[0099] This application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement this application. Figures 2-4 The image processing method provided in any of the corresponding embodiments.

[0100] This application provides a computer program product, including a computer program, which, when executed by a processor, implements this application. Figures 2-4 The image processing method provided in any of the corresponding embodiments.

[0101] To implement the above embodiments, this application also provides an electronic device.

[0102] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0103] It should be further noted that although the steps in the flowchart 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 flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0104] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0105] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0106] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0107] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0108] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0109] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0110] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A data processing method, characterized in that, include: The system obtains the target deployment content submitted by the user and captures the deployment operation events corresponding to the deployment content in real time through an event-driven architecture. The deployment operation event is parsed into a structured operation tree, which contains the operation type, operation parameters and dependencies corresponding to the deployment operation event; Based on the structured operation tree, verification cases are generated for the target deployment content.

2. The method according to claim 1, characterized in that, The step of parsing the deployment operation event into a structured operation tree includes: Obtain the event type corresponding to the deployment operation event; Based on the event type, determine the operation type, the operation parameters, and the dependencies; Based on the operation type, the operation parameters, and the dependencies, a structured operation tree containing hierarchical relationships is constructed.

3. The method according to claim 1, characterized in that, After generating verification cases for the target deployment content based on the structured operation tree, the method further includes: Obtain the task template type corresponding to the verification case; Based on the task template type, determine the corresponding version verification strategy; A verification version number is generated based on the version verification strategy, and the verification version number is used to represent the version of the target deployment content.

4. The method according to claim 3, characterized in that, The step of determining the corresponding version verification strategy based on the task template type includes at least one of the following: In cross-day production scenarios, a 24-hour time difference compensation algorithm is enabled. Valid version numbers are filtered using a version number topology sorting mechanism.

5. The method according to claim 3, characterized in that, After generating the verification version number based on the version verification strategy, the method further includes: Based on the version verification strategy and the verification version number, an asynchronous verification task is created; The asynchronous verification task triggers the verification process for the verification case. The method further includes: When the asynchronous verification task times out, the circuit breaker mechanism is triggered.

6. The method according to claim 5, characterized in that, Before creating the asynchronous verification task based on the version verification strategy and the verification version number, the method further includes: Based on the verification version number and the corresponding version verification strategy, construct the associated information; Based on the associated information, verify the matching between the verification version number and the version verification strategy.

7. The method according to claim 1, characterized in that, The deployment operation events include at least one of the following: PaaS resource deployment, environment variable change, configuration file update, database script execution, batch task scheduling, and infrastructure adjustment; The deployment operation event includes at least two detailed sub-operation events; The method further includes: Based on contextual information, identify target sub-operation events with high-risk operations; The step of parsing the deployment operation event into a structured operation tree includes: The target sub-operation event is parsed into a structured operation tree.

8. The method according to claim 1, characterized in that, The method further includes: After generating the verification result corresponding to the verification case, the responsible party corresponding to the verification case is obtained. The responsible party is the user who submitted or reviewed the target deployment content. The verification result is sent to the responsible party.

9. A data processing apparatus, comprising: The acquisition module is used to acquire the target deployment content submitted by the user and capture the deployment operation events corresponding to the deployment content in real time through an event-driven architecture. The parsing module is used to parse the deployment operation event into a structured operation tree, wherein the structured operation tree contains the operation type, operation parameters and dependencies corresponding to the deployment operation event; The processing module is used to generate verification cases for the target deployment content based on the structured operation tree.

10. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 8.

12. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 8.

Images