Version processing method, system and apparatus and electronic device

Abstract

The present application discloses a version processing method, system and apparatus, and an electronic device. The method comprises: receiving a version release request initiated by a target object via a target client, wherein the version release request comprises at least identifier information of a branch to be released, and a target version of a target workflow template is stored in the branch; on the basis of the identifier information of the branch, acquiring the branch, generating a target mirror image corresponding to the branch, and calling a target program of a first platform to deploy the target mirror image to a target operating environment; and receiving a deployment result returned by the first platform, wherein the deployment result is used to indicate whether or not the target version of the target workflow template has been successfully released. The present application solves the technical problem in the related art of low reliability during the release of workflow-template versions.

Description

[0001] Version Processing Method, System, Apparatus, and Electronic Device This application claims priority to Chinese patent application number 202410052028.3, filed with the China Patent Office on January 12, 2024, entitled "Version Processing Method, System, Apparatus, and Electronic Device," the entire contents of which are incorporated herein by reference. Technical Field This application relates to the field of computer technology, and more specifically, to a version processing method, system, apparatus, and electronic device. Background: Currently, when using a workflow engine to define a workflow template, methods in other templates can be referenced. However, in large-scale systems, a complex workflow template definition often has a deep reference hierarchy and complex reference relationships. To improve overall execution efficiency, the task of parsing the referenced template is typically distributed to various worker nodes for parallel execution. In this scenario, the release of workflow template versions presents at least the following issues:

[0002] (1) Incompatibility issues: When an existing workflow instance is running, if a user modifies a template and publishes it, when the workflow instance runs to reference the modified template, if the modification is incompatible with the original reference relationship, the existing running workflow instance will fail, which will affect the existing normal running workflow and cause online failures. A new workflow instance needs to be created to correct the process.

[0003] (2) Low release reliability: When releasing templates, there is a lack of process control such as code approval and testing, and the code quality is uncontrollable, which brings more online failures.

[0004] (3) Concurrency Issues: Currently, when multiple users publish workflow templates simultaneously, isolation and concurrency control are not performed. For example, after user A submits a template for publication, the baseline version modified by user B is still the baseline version before user A publishes it. As a result, user B directly overwrites user A's changes after publishing it, but neither user A nor user B is aware of this, which causes online failures. Currently, no effective solution has been proposed to the above-mentioned problems. SUMMARY OF THE INVENTION The embodiments of the present application provide a version processing method, system, device, and electronic device to at least solve the technical problem of low reliability when publishing workflow template versions in related technologies. According to one aspect of an embodiment of the present application, a version processing method is provided, comprising: receiving a version release request initiated by a target object through a target client, wherein the version release request includes at least identification information of a to-be-released branch, wherein the to-be-released branch stores a target version of a target workflow template; obtaining the to-be-released branch based on the identification information of the to-be-released branch, generating a target image corresponding to the to-be-released branch, and invoking a target program of a first platform to deploy the target image to a target runtime environment, wherein the target image is used to implement template version release for the target client, and the target runtime environment is used to run the target image, so that the target client initiates a release request to a target component, wherein the release request is used to request the target component to release the target version of the target workflow template; receiving a deployment result returned by the first platform, wherein the deployment result indicates whether the target version of the target workflow template was successfully released. Furthermore, generating the target image corresponding to the to-be-released branch includes: testing the to-be-released branch to obtain a test result; and generating the target image if the test result indicates that the to-be-released branch passes the test. Furthermore, generating a target image includes: obtaining project identification information of a target project, and detecting the number of branches of a to-be-released branch corresponding to the target project based on the project identification information, wherein the target project is used to provide a target workflow template for the target object; if there are multiple branches, merging the multiple to-be-released branches to obtain a merged to-be-released branch; generating an image corresponding to the merged to-be-released branch, and using the image corresponding to the merged to-be-released branch as the target image.Furthermore, before receiving a version release request initiated by the target object through the target client, the method further includes: receiving a version change request initiated by the target object through the target client, wherein the version change request includes at least project identification information; determining baseline branch information of the baseline branch of the target project based on the project identification information, and obtaining a baseline branch from the target client based on the baseline branch information, wherein the baseline branch stores a target workflow template; generating a first branch based on the target module and the baseline branch, wherein the first branch is used to implement a template change; and responding to a target operation of the target object on the target workflow template in the first branch, changing the target workflow template in the first branch based on the target operation to obtain a branch to be released. Furthermore, after receiving the deployment result returned by the first platform, the method further includes: when error information of the target component is detected, generating prompt information based on the error information, and sending the prompt information to the target object, wherein the error information is used to indicate that an abnormality exists in the target workflow template; receiving a version rollback request initiated by the target object, wherein the version rollback request includes at least the version number of the target image to be rolled back; determining the target image to be rolled back based on the version number of the target image to be rolled back, and obtaining a target version snapshot from the target image to be rolled back, wherein the target version snapshot is used to record the version content of the first version of the target workflow template, and the first version indicates the version of the target workflow template to be rolled back; performing a rollback operation based on the target image to be rolled back and the target version snapshot to release the first version. According to one aspect of an embodiment of the present application, a version processing method is provided, comprising: receiving a publish request via a target component, wherein the publish request includes at least a target version of a target workflow template; performing a validity check on the version content of the target version according to a first service to obtain a check result; if the check result indicates that the version content of the target version passes the validity check, publishing the target version according to a second service and storing the target version in a target database. Furthermore, storing the target version in the target database comprises: obtaining a template relationship table, and determining a target dependency relationship corresponding to the target workflow template in the template relationship table, wherein the target dependency relationship represents a reference relationship corresponding to the target workflow template; updating the target dependency relationship according to a target rule and a target version to obtain an updated template relationship table; and obtaining a template content table, and storing the template identifier of the target workflow template and the version content of the target version in the template content table.According to one aspect of an embodiment of the present application, a version processing system is provided, comprising: a target client, configured to manage a target workflow template and submit version change requests to a target platform. The target client includes at least a target module, configured to manage versions of the target workflow template, and the version change request includes at least project identification information of a target project. A target platform, configured to generate a to-be-released branch storing a target version of the target workflow template based on the project identification information, generate a target image for the to-be-released branch, and invoke a target program on a first platform to deploy and release the target image. The system further comprises: a target component, configured to provide a target service for the target client. The target service includes at least a first service and a second service. The first service is configured to perform a validity check on the target version content, and the second service is configured to release the target version. Furthermore, the first platform is configured to deploy the target image to a target runtime environment. The target runtime environment is configured to run the target image, so that the target client can initiate a release request to the target component. According to another aspect of an embodiment of the present application, a version processing method is further provided, comprising: obtaining a version release request uploaded by a client, wherein the version release request includes at least identification information of a to-be-released branch, and the to-be-released branch stores a target version of a target workflow template; obtaining a to-be-released branch in a cloud server based on the identification information of the to-be-released branch, generating a target image corresponding to the to-be-released branch, and calling a target program of a first platform to deploy the target image to a target operating environment, wherein the target image is used to implement template version release of the client, and the target operating environment is used to run the target image, so that the client initiates a release request to a target component, and the release request is used to request the target component to release the target version of the target workflow template; receiving a deployment result returned by the first platform, wherein the deployment result is used to indicate whether the target version of the target workflow template is successfully released; and feeding back the deployment result to the client.According to another aspect of an embodiment of the present application, a version processing apparatus is provided, comprising: a first receiving unit configured to receive a version release request initiated by a target object via a target client, wherein the version release request includes at least identification information of a to-be-released branch, which stores a target version of a target workflow template; a first generating unit configured to obtain a to-be-released branch based on the identification information of the to-be-released branch, generate a target image corresponding to the to-be-released branch, and invoke a target program on a first platform to deploy the target image to a target runtime environment, wherein the target image is used to implement template version release on the target client, and the target runtime environment is used to run the target image, so that the target client initiates a release request to a target component, wherein the release request is used to request the target component to release the target version of the target workflow template; a second receiving unit configured to receive a deployment result returned by the first platform, wherein the deployment result indicates whether the target version of the target workflow template was successfully released. Furthermore, the first generating unit includes: a first testing subunit configured to test the to-be-released branch and obtain a test result; and a first generating subunit configured to generate the target image if the test result indicates that the to-be-released branch passes the test. Furthermore, the first generation subunit includes: a first acquisition module, configured to obtain project identification information of a target project, and detect the number of branches of a to-be-released branch corresponding to the target project based on the project identification information, wherein the target project is used to provide a target workflow template for a target object; a first processing module, configured to merge multiple to-be-released branches if there are multiple branches, to obtain a merged to-be-released branch; and a first determination module, configured to generate an image corresponding to the merged to-be-released branch, and use the image corresponding to the merged to-be-released branch as the target image. Furthermore, the version processing device also includes: a third receiving unit, configured to receive a version change request initiated by the target object through the target client before receiving the version release request initiated by the target object through the target client, wherein the version change request includes at least project identification information; a first determining unit, configured to determine baseline branch information of the baseline branch of the target project based on the project identification information, and obtain the baseline branch from the target client based on the baseline branch information, wherein the baseline branch stores the target workflow template; a second generating unit, configured to generate a first branch based on the target module and the baseline branch, wherein the first branch is used to implement template change; and a first processing unit, configured to respond to the target operation of the target object on the target workflow template in the first branch, and change the target workflow template in the first branch according to the target operation to obtain a branch to be released.Furthermore, the version processing device also includes: a third generating unit, configured to, after receiving the deployment result returned by the first platform, generate prompt information based on the error information when detecting error information of the target component, so as to send the prompt information to the target object, wherein the error information is used to indicate that there is an abnormality in the target workflow template; a fourth receiving unit, configured to receive a version rollback request initiated by the target object, wherein the version rollback request includes at least the version number of the target image to be rolled back; a second determining unit, configured to determine the target image to be rolled back based on the version number of the target image to be rolled back, and obtain a target version snapshot from the target image to be rolled back, wherein the target version snapshot is used to record the version content of the first version of the target workflow template, and the first version indicates the version of the target workflow template to be rolled back; and a second processing unit, configured to perform a rollback operation based on the target image to be rolled back and the target version snapshot to release the first version. According to another aspect of an embodiment of the present application, a version processing apparatus is provided, comprising: a fifth receiving unit configured to receive a publish request through a target component, wherein the publish request includes at least a target version of a target workflow template; a third processing unit configured to perform a validity check on the version content of the target version according to a first service and obtain a check result; a fourth processing unit configured to publish the target version according to a second service if the check result indicates that the version content of the target version passes the validity check, and store the target version in a target database. Furthermore, the fourth processing unit comprises: a first obtaining subunit configured to obtain a template relationship table and determine a target dependency relationship corresponding to the target workflow template in the template relationship table, wherein the target dependency relationship represents a reference relationship corresponding to the target workflow template; an updating subunit configured to update the target dependency relationship according to a target rule and a target version to obtain an updated template relationship table; and a second obtaining subunit configured to obtain a template content table and store the template identifier of the target workflow template and the version content of the target version in the template content table. According to another aspect of an embodiment of the present application, a computer-readable storage medium is provided. The storage medium stores a program. When the program is executed, the device containing the storage medium is controlled to execute any one of the above-described version processing methods. According to another aspect of an embodiment of the present application, an electronic device is provided, including: a memory storing an executable program; and a processor configured to execute the program. When the program is executed, the device executes any one of the above-described version processing methods.In an embodiment of the present application, a version release request is received from a target object via a target client, wherein the version release request includes at least identification information of a to-be-released branch, wherein the to-be-released branch stores a target version of the target workflow template; the to-be-released branch is obtained based on the identification information of the to-be-released branch, a target image corresponding to the to-be-released branch is generated, and a target program of a first platform is called to deploy the target image to a target runtime environment. The target image is used to implement template version release for the target client, and the target runtime environment is used to run the target image, so that the target client initiates a release request to a target component, wherein the release request is used to request the target component to release the target version of the target workflow template; and a deployment result is received from the first platform, wherein the deployment result indicates whether the target version of the target workflow template has been successfully released. By generating a target image corresponding to the to-be-released branch, template version release can be implemented based on the target image. Compared with the related art in which users directly modify and release templates, this standardizes the template version release process, facilitates management and control of template version release, and makes template version release more convenient and efficient. In addition, when an exception occurs in the release, the template can be rolled back with the help of the target image. This improves the isolation of single snapshots for releases, making rollbacks safer and reducing online failure rates. This improves the reliability of workflow template version releases and addresses the technical issue of low reliability in workflow template version releases in related technologies. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings described herein are provided to provide a further understanding of this application and constitute a part of this application. The illustrative embodiments of this application and their descriptions are intended to explain this application and are not intended to unduly limit it. In the accompanying drawings: Figure 1 is a schematic diagram of a computer terminal provided according to Example 1 of the present application; Figure 2 is a flowchart of the version processing method provided according to Example 1 of the present application; Figure 3 is a flowchart of the version processing method provided according to Example 2 of the present application; Figure 4 is a schematic diagram of the version dependency relationship provided according to Example 2 of the present application; Figure 5 is a schematic diagram of the version processing system provided according to Example 3 of the present application; Figure 6 is a schematic diagram of the version processing flow provided according to Example 3 of the present application; Figure 7 is a flowchart of the version processing method provided according to Example 4 of the present application; Figure 8 is a schematic diagram of the version processing device provided according to Example 5 of the present application; Figure 9 is a schematic diagram of the version processing device provided according to Example 6 of the present application; Figure 10 is a schematic diagram of the computing terminal provided according to Example 7 of the present application.DETAILED DESCRIPTION To help those skilled in the art better understand the present invention, the following will provide a clear and complete description of the technical solutions in the embodiments of the present invention, with reference to the accompanying drawings. It should be noted that the described embodiments represent only a portion of the present invention, and are not exhaustive. All other embodiments devised by persons of ordinary skill in the art based on the embodiments of the present invention without inventive effort should fall within the scope of protection of the present invention. It should be noted that the terms "first," "second," and so on, in the specification and claims of the present invention, and in the accompanying drawings, are used to distinguish similar objects and are not necessarily used to describe a specific order or precedence. It should be understood that such terms are interchangeable where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than that illustrated or described herein. Furthermore, the terms "including," "having," and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or elements is not necessarily limited to the steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, product, or apparatus. 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, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use, and processing of relevant data must comply with the relevant laws, regulations, and standards of the relevant region, and corresponding operation portals are provided for users to choose to authorize or refuse. First, some nouns or terms that appear in the description of the embodiments of this application are subject to the following explanations: Continuous Integration: The full English name is Continuous Integration, abbreviated as CL. Continuous integration is the process by which development team members frequently integrate their code into a shared code repository. Through automated build and integration processes, the team can quickly discover and resolve code conflicts, errors, and problems to ensure code stability and consistency. Continuous Delivery: The full English name is Continuous Delivery, abbreviated as CD. Continuous delivery is a software delivery practice whose goal is to ensure that software can be delivered at any time. In continuous delivery, the development team uses automated processes to generate deployable software packages from integrated and tested software builds and delivers them to the quality assurance team or deployment team for verification and deployment.Continuous Deployment: Continuous Deployment (CD) takes continuous delivery a step further by automatically deploying tested software to production. The goal of continuous deployment is to fully automate the process from code submission to production, reducing manual intervention and shortening delivery time. Continuous Integration and Continuous Delivery / Deployment: Continuous Integration Continuous Delivery / Deployment (CICD) are software development practices and automated processes designed to achieve rapid, high-quality software delivery through frequent integration, building, testing, and delivery. Workflow Engine: A software system used to define, execute, and manage complex workflows and task flows. A workflow engine abstracts task flows into executable models and provides a range of functions and services to implement the various activities, tasks, and decisions within the process. Process Definition and Modeling: A workflow engine allows users to describe task flows through definition and modeling tools. Process steps, activities, decisions, and relationships are typically defined using a graphical interface or a specific markup language, such as Business Process Modeling Notation (BPMN). Process Execution and Scheduling: Once a process is defined and modeled, the workflow engine is responsible for executing and scheduling the tasks and activities within the process. It automatically triggers and tracks the execution status of each step based on pre-defined rules and conditions, ensuring that the process proceeds according to the defined sequence and conditions. Task and Work Allocation: The workflow engine is responsible for assigning tasks and work to the appropriate participants or executors. It can assign tasks to specific individuals, roles, teams, or systems based on pre-defined rules and conditions. Decision Management and Routing: The workflow engine can perform decision management and routing based on pre-defined rules and conditions. Based on the current context and data, it can automatically determine the direction, execution path, and branching of the process according to specific conditions. Monitoring and Reporting: The workflow engine provides monitoring and reporting capabilities, tracking and recording process execution, task status, and executor performance. It can generate reports and statistics to help users understand process efficiency, bottlenecks, and areas for improvement. Workflow template: A reusable workflow definition used to create and instantiate specific workflow instances in the workflow engine. It is a predefined blueprint that includes definitions of elements such as steps, tasks, decisions, and routes in the workflow.Embodiment 1: According to an embodiment of the present application, a version processing method is also provided. It should be noted that the steps shown in the flowcharts of the accompanying drawings can be executed in a computer system, such as a set of computer-executable instructions. Furthermore, although the flowcharts illustrate a logical order, in some cases, the steps shown or described may be executed in a different order. The method embodiment provided in Embodiment 1 of the present application can be executed in a mobile terminal, a computer terminal, or a similar computing device. Figure 1 shows a hardware block diagram of a computer terminal (or mobile device) for implementing the version processing method. As shown in Figure 1, the computer terminal (or mobile device) 10 may include a processor assembly 102 (the processor assembly 102 may include, but is not limited to, a processing device such as a microprocessor (MCU) or a programmable logic device (FPGA), and the processor assembly 102 may include a processor assembly, as shown in Figure 1 by 102a, 102b, ..., 102n), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, the device may also include: a display, an input / output interface (I / O interface), a Universal Serial Bus (USB) port (which may be included as one of the ports of a BUS), a network interface, a power supply, and / or a camera. Those skilled in the art will appreciate that the structure shown in FIG1 is merely illustrative and does not limit the structure of the electronic device. For example, the computer terminal 10 may include more or fewer components than shown in FIG1 , or have a configuration different from that shown in FIG1 . It should be noted that the one or more processors 102 and / or other data processing circuits described above may generally be referred to herein as "data processing circuitry." This data processing circuitry may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuitry may be a single, independent processing module, or may be fully or partially integrated into any of the other components of the computer terminal 10 (or mobile device). The memory 104 may be used to store software programs and modules of application software, such as a program instruction / data storage device corresponding to the version processing method in the embodiments of the present application. The processor 102 executes the software programs and modules stored in the memory 104 to perform various functional applications and data processing, thereby implementing the above-mentioned version processing method.Memory 104 may include high-speed random access memory (RAM) and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, memory 104 may further include memory remotely located relative to processor 102, which may be connected to computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. Transmission device 106 is used to receive or transmit data via a network. Specific examples of such networks may include a wireless network provided by the computer terminal 10's communications provider. In one instance, transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to communicate with the Internet. In one instance, transmission device 106 may be a radio frequency (RF) module for wireless communication with the Internet. The display may be, for example, a touch-screen liquid crystal display, which enables a user to interact with the user interface of computer terminal 10 (or mobile device). Currently, workflow templates defined using a workflow engine can reference methods from other templates. However, in large-scale systems, complex workflow template definitions often contain deep reference layers and complex relationships. To improve overall execution efficiency, the task of parsing referenced templates is often distributed and executed in parallel across worker nodes. In this scenario, workflow template releases present at least the following issues:

[0005] (1) Incompatibility issues: When an existing workflow instance is running, if a user modifies a template and publishes it, when the workflow instance runs to reference the modified template, if the modification is incompatible with the original reference relationship, the existing running workflow instance will fail, which will affect the existing normal running workflow and cause online failures. A new workflow instance needs to be created to correct the process.

[0006] (2) Low release reliability: When releasing templates, there is a lack of process control such as code approval and testing, and the code quality is uncontrollable, which brings more online failures.

[0007] (3) Concurrency Issues: Currently, when multiple users publish workflow templates simultaneously, isolation and concurrency control are not performed. For example, after user A submits a template for publication, the baseline version modified by user B is still the baseline version before user A publishes it, resulting in user B directly overwriting user A's changes after publishing, but neither A nor B is aware of it, thus causing online failures. Against the above technical background, this application provides a version processing method as shown in FIG2. FIG2 is a flowchart of the version processing method provided according to the first embodiment of this application. The method comprises: step S201, receiving a version publishing request initiated by a target object through a target client, wherein the version publishing request includes at least identification information of a branch to be published, and the branch to be published stores a target version of the target workflow template. The version publishing request is used to request the publication of a newly generated branch (i.e., the branch to be published). The target workflow template represents the template contained in the target project. The target project is mainly responsible for storing template information and providing workflow templates to users, so that users can modify templates in the project. The target version represents the new version of the template. To reduce online failure rates, this solution implements template release based on the CICD platform. For example, after a user (i.e., the target object) makes a template change using a target client (e.g., the ACS Workflow-Template-Manager client), a branch to be released is obtained. The user then uses the branch to initiate a change on the CICD platform, requesting the release of the change. The CICD platform then receives a version release request from the user. The version release request includes at least identification information (e.g., branch name) of the branch to be released, which stores the new version of the workflow template. In step S202, the branch to be released is obtained based on the identification information of the branch to be released. A target image corresponding to the branch to be released is generated, and a target program on the first platform is invoked to deploy the target image to the target runtime environment. The target image is used to implement template version release for the target client, and the target runtime environment is used to run the target image, enabling the target client to initiate a release request to the target component. The release request is used to request the target component to release the target version of the target workflow template.The first platform may be a deployment platform, the target program may be a deployment program, and the target runtime environment may be an image runtime environment. Running the image in the runtime environment may trigger the startup of the template publishing program, for example, causing the target client to initiate a publishing request to the target component. The target component may be a workflow engine, such as ACS Workflow, the workflow engine used by the cloud-native data warehouse AnalyticDB for MySQL (ADB for MySQL). ACS is a platform component of ADB, and ACS Workflow is a component in ACS. It can serve as the server of the aforementioned ACS - Workflow-Template-Manager client and provide services for it. When a change is released, the CICD platform automatically builds an image for the new version. Based on the identification information of the branch to be released, it retrieves the branch to be released and generates a target image corresponding to the branch. The deployment platform's deployment program is then invoked to deploy the target image to the target runtime environment, enabling the image to run in that runtime environment. This triggers the template release program to start, causing the target client to initiate a release request to the target component, releasing the template version to the target client. The release request includes at least the new version of the workflow template. For example, after a user makes a template change using the ACS-Workflow-Template-Manager client, they can submit the branch to be released to a remote Git repository using the client's version control system (Git). The CICD platform then retrieves the branch to be released from the remote Git repository based on the identification information and generates a target image corresponding to the branch to be released. Step S203: Receive the deployment result returned by the first platform. The deployment result indicates whether the target version of the target workflow template has been successfully released.After the target image is deployed to the target runtime environment, before the new version of the template is released, the target client calls the target component to verify the template. For example, the ACS-Workflow-Template-Manager client calls ACS Workflow to check the validity of the changed template. If the check fails, the release of the change is rejected and the change is returned. It will be successfully released only after the user modifies the template correctly. If the check passes, the changed template and its corresponding version are stored in the database. The change is successfully released, that is, the new version of the workflow template is successfully released. ACS Workflow then reports the template release success to the deployment platform, and the deployment platform reports the image deployment success to the CICD platform. Therefore, the CICD platform receives the deployment result returned by the deployment platform. For example, if the deployment result is "deployment successful", it means that the template was successfully released. In this solution, by generating a target image corresponding to the branch to be released, template versions can be released based on the target image. Compared to related techniques where users directly modify and release templates, this standardizes the template version release process, facilitates management and control of template version releases, and makes template version releases more convenient and efficient. Furthermore, if a release exception occurs, the target image can be used to roll back the template, better implementing single-snapshot isolation and making rollbacks safer. How to generate a new version image is crucial. Therefore, in the version processing method provided in Example 1 of this application, generating a target image corresponding to the branch to be released includes: testing the branch to be released and obtaining test results; if the test results indicate that the branch to be released passes the test, generating the target image. During the generation of the target image corresponding to the branch to be released, the branch to be released can be tested and obtained test results; if the test results indicate that the branch to be released passes the test, generating the target image. For example, a user can submit a change using a pending branch on the CICD platform and apply for its release. This change will undergo code review and unit and integration testing (e.g., testing the runtime nature of the pending branch) before it can be officially released. It's important to note that compared to related technologies where workflows use their own platforms to submit and manage templates, template release based on the CICD platform is more secure and makes the workflow system more lightweight. Having the CICD platform manage image building, testing, and other operations makes template release more convenient and efficient, effectively reducing online failure rates and improving the reliability of workflow template releases.To generate a new version of an image, the version processing method provided in the first embodiment of the present application generates a target image, including: obtaining project identification information of a target project, and detecting the number of branches of a to-be-released branch corresponding to the target project based on the project identification information. The target project is used to provide a target workflow template for the target object; if there are multiple branches, merging the multiple to-be-released branches to obtain a merged to-be-released branch; generating an image corresponding to the merged to-be-released branch, and using the image corresponding to the merged to-be-released branch as the target image. In this solution, multi-version management of workflow templates is implemented based on the CICD platform. When building an image for a new version, the CICD platform can obtain project identification information (such as the project name), detect the number of branches of a to-be-released branch corresponding to the target project based on the project identification information, and if there are multiple branches, merge the multiple to-be-released branches to obtain a merged to-be-released branch, generate an image corresponding to the merged to-be-released branch, and use the image corresponding to the merged to-be-released branch as the target image. For example, when multiple users use the CICD platform to release branches, the CICD platform automatically merges the multiple branches to be released. If a merge conflict occurs, the aforementioned Git tool can be used to resolve the conflict. The merged branches to be released are then used for release, generating an image corresponding to the merged branches. This image contains a snapshot of the new branch version and a snapshot of the template contained in that branch. After running the image, the ACS-Workflow-Template-Manager client invokes ACS Workflow to write the new version to the ACS Workflow database, completing the multi-version release. It should be noted that template release based on the CICD platform is more secure and makes the workflow system more lightweight. Having the CICD platform manage image building, testing, and other operations makes template release more convenient and efficient, effectively reducing online failure rates and improving the reliability of workflow template version releases.In order to obtain the branch to be released, in the version processing method provided in the first embodiment of the present application, before receiving the version release request initiated by the target object through the target client, a version change request initiated by the target object through the target client is received, wherein the version change request includes at least project identification information; baseline branch information of the baseline branch of the target project is determined based on the project identification information, and the baseline branch is obtained from the target client based on the baseline branch information, wherein the baseline branch stores the target workflow template; a first branch is generated based on the target module and the baseline branch, wherein the first branch is used to implement a template change; in response to the target object's target operation on the target workflow template in the first branch, the target workflow template in the first branch is changed based on the target operation, thereby obtaining the branch to be released. Optionally, before receiving a version release request initiated by a user through the target client, the CICD platform receives a version change request initiated by the user. For example, a user submits a version change request through the ACS-Workflow-Template-Manager client, requesting a change to the workflow template of the target project. The CICD platform can determine the baseline branch information of the target project's baseline branch based on project identification information such as the project name, and retrieve the baseline branch from the ACS-Workflow-Template-Manager client based on the baseline branch information. The CICD platform then generates a new branch (i.e., the first branch) based on the target module (such as the aforementioned Git tool) and the baseline branch. For example, the client's Git tool is invoked, and the user can use Git to create a new branch from the baseline branch and perform template changes on the new branch. Therefore, the CICD platform responds to the user's target operation (such as a modification operation) on the target workflow template in the new branch and, based on the target operation, changes the target workflow template in the new branch to obtain a branch to be released. Subsequently, the CICD platform can respond to the user's commit operation on the branch to be released by submitting the branch to be released to the target repository (such as the aforementioned remote Git repository). It should be noted that by combining the CICD platform with Git version management, template versions are made transparent to users, simplifying the process of publishing templates and how to use templates. This avoids online failures caused by users not understanding template versions, making workflow template publishing more controllable and secure.To effectively implement rollback, the version processing method provided in the first embodiment of the present application includes: after receiving the deployment result returned by the first platform, if error information of the target component is detected, a prompt message is generated based on the error information and sent to the target object, wherein the error information is used to indicate that an abnormality exists in the target workflow template; a version rollback request initiated by the target object is received, wherein the version rollback request includes at least the version number of the target image to be rolled back; a target image to be rolled back is determined based on the version number of the target image to be rolled back, and a target version snapshot is obtained from the target image to be rolled back, wherein the target version snapshot is used to record the version content of the first version of the target workflow template, where the first version represents the version of the target workflow template to be rolled back; and a rollback operation is performed based on the target image to be rolled back and the target version snapshot to release the first version. After a new version of a workflow template is released, if an error occurs, an emergency rollback is necessary to mitigate losses. For example, if a template contains errors, the ACS Workflow program may issue an exception alert. The CICD platform can detect the error and notify the user. For example, the CICD platform detects the error message from the ACS Workflow, generates a prompt based on the error message, and sends the prompt to the user. The user can then select the historical image version to roll back through the CICD platform and redeploy that historical image using a new deployment process. Because each image version contains a snapshot of a specific template version, a rollback operation simply requires re-releasing the template in that image version. This snapshot of the historical template version is then published and stored as a new change in the ACS Workflow database. Therefore, the CICD platform receives a version rollback request submitted by a user. The request includes at least the version number of the target image to be rolled back (i.e., the version number of the historical image to be rolled back). Based on the version number of the target image to be rolled back (i.e., the version number of the historical image to be rolled back), the platform determines the target image to be rolled back (i.e., the historical image to be rolled back). A target version snapshot containing the content of the version to be rolled back is then retrieved from the target image. The platform then performs a rollback operation based on the target image and the target version snapshot, releasing the first version (i.e., the historical version) and storing it in the ACS Workflow database. It should be noted that since this solution relies on the CICD platform, rollback can be performed solely on the CICD platform, eliminating the need for complex rollback logic in the project code. Furthermore, since the code implementation hides the user's awareness of template versions, rollback can reuse the release process logic and roll back multiple versions, resulting in high reliability.In addition, template rollback using mirroring better implements single snapshot isolation, making rollback safer and more reliable. When errors occur during release, rollback can be done quickly and safely, improving rollback efficiency. In an embodiment of the present application, a version release request is received from a target object via a target client, wherein the version release request includes at least identification information of a to-be-released branch, wherein the to-be-released branch stores a target version of the target workflow template; the to-be-released branch is obtained based on the identification information of the to-be-released branch, a target image corresponding to the to-be-released branch is generated, and a target program of a first platform is called to deploy the target image to a target runtime environment. The target image is used to implement template version release for the target client, and the target runtime environment is used to run the target image, so that the target client initiates a release request to a target component, wherein the release request is used to request the target component to release the target version of the target workflow template; and a deployment result is received from the first platform, wherein the deployment result indicates whether the target version of the target workflow template has been successfully released. By generating a target image corresponding to the to-be-released branch, template version release can be implemented based on the target image. Compared with the related art in which users directly modify and release templates, this standardizes the template version release process, facilitates management and control of template version release, and makes template version release more convenient and efficient. In addition, when an exception occurs in the release, the template can be rolled back with the help of the target image. This better implements single-snapshot isolation for releases, making rollbacks safer and reducing online failure rates. This improves the reliability of workflow template version releases, further resolving the technical issue of low reliability in workflow template version releases in related technologies. It should be noted that the aforementioned method embodiments are presented as a series of actions for simplicity. However, those skilled in the art should be aware that this application is not limited to the order of the actions described, as certain steps may be performed in a different order or simultaneously. Furthermore, those skilled in the art should also be aware that the embodiments described in this specification are preferred embodiments, and the actions and modules involved are not necessarily required for this application. Through the above description of the embodiments, those skilled in the art will clearly understand that the methods according to the aforementioned embodiments can be implemented using software and a necessary general-purpose hardware platform. Hardware implementation is also possible, but in many cases the former is the preferred implementation.Based on this understanding, the technical solution of this application, or the portion that contributes to the prior art, can essentially be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, a magnetic disk, or an optical disk) and includes instructions for enabling a terminal device (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in various embodiments of this application. Example 2: According to an embodiment of this application, a version processing method as shown in Figure 3 is provided. Figure 3 is a flowchart of the version processing method provided according to Example 2 of this application. The method comprises: Step S301: Receive a publish request via a target component, wherein the publish request includes at least a target version of a target workflow template. Step S302: Perform a validity check on the version content of the target version using a first service to obtain a check result. Step S303: If the check result indicates that the version content of the target version passes the validity check, publish the target version using a second service and store the target version in a target database. The target component can be a workflow engine, such as ACS Workflow, the workflow engine used by the cloud-native data warehouse AnalyticDB for MySQL (ADB for MySQL). ACS is a platform component of ADB. ACS Workflow is a component within ACS that serves as the server for the ACS-Workflow-Template-Manager client, providing services such as template verification, template version logging, and template relationship logging. Optionally, running the image in the runtime environment triggers the startup of a template publishing program, causing the ACS-Workflow-Template-Manager client to initiate a publishing request to ACS Workflow and simultaneously verify the template. Therefore, ACS Workflow receives the publishing request and performs a validity check on the version content of the target version (i.e., the new version) based on a first service (e.g., a template verification service). If the check result indicates that the version content of the target version passes the validity check, the target version is published based on a second service (e.g., a template relationship record service) and stored in a target database (e.g., an ACS Workflow database). If the check result indicates that the version content of the target version fails the validity check, the publication of the change is rejected and the change is rolled back. The change will be successfully published only after the user correctly modifies the template.To manage workflow template versions, the version processing method provided in Example 2 of this application stores the target version in a target database. The method includes: obtaining a template relationship table and determining the target dependency relationship corresponding to the target workflow template in the template relationship table. The target dependency relationship represents the reference relationship corresponding to the target workflow template; updating the target dependency relationship based on the target rule and target version to obtain an updated template relationship table; obtaining a template content table and storing the template identifier of the target workflow template and the version content of the target version in the template content table. In the ACS Workflow database, each template has a corresponding version number. When a template is published, the version number is incremented by 1 and stored in the database. Furthermore, due to the dependencies between templates, template relationships need to be processed to ensure compatibility after publication. Therefore, when storing the target version in the target database, a template relationship table is obtained, and the target dependency corresponding to the target workflow template is determined in the template relationship table. The target dependency is then updated based on the target rule and target version, resulting in an updated template relationship table. Furthermore, a template content table is obtained, and the template identifier of the target workflow template and the version content of the target version are stored in the template content table. The template relationship table is used to store dependencies between templates, while the template content table is used to store template content. For example, the template identifier (such as template name, template number, etc.) and version content of a workflow template are stored in the template content table. The template identifier can be used to find the corresponding dependency in the template relationship table, and the corresponding template content can be found in the template content table. For example, the record format of the template relationship table is: {Template 1, Version 1, Template 2, Version 2}, where Template 2 is the template on which Template 1 depends, Version 1 is the current version of Template 1, and Version 2 is the current version of Template 2. According to an embodiment of the present application, a version dependency relationship is provided as shown in FIG4 . FIG4 is a schematic diagram of a version dependency relationship provided according to a second embodiment of the present application. As shown on the left side of FIG4 , template temp1 depends on template temp2, which in turn depends on templates temp3 and temp4. When a database table (e.g., a template relationship table) records template relationships, it also records corresponding version numbers. The version dependency relationship shown on the left side of FIG4 generates three records in the database: (temp1, 1, temp2, 1}, (temp2, 1, temp3, 1}, and (temp2, 1, temp4, 2}).When a change is published simultaneously for templates temp2 and temp3, both templates temp2 and temp3 will be upgraded. For example, template temp2 is upgraded to version 2, and template temp3 is upgraded to version 2. At this time, the corresponding template relationship records will also be changed. That is, after this release, the database will add two relationship records and update one relationship record. The records after the release are: {tempi, 1, temp2, 2}, {temp2, 1, temp3, 1}, {temp2, 1, temp4, 2}, (temp2, 2, temp3, 2}, (temp2, 2, temp4, 2}. The template relationship change rule (i.e., the target rule) is: When a dependent template is updated, a new template relationship record will be inserted, for example, the records for templates temp2 and temp3, and the records for templates temp2 and temp4 in the example above; When a dependent template is updated, The version number in the existing record will be directly modified, for example, the records for templates temp1 and temp2 in the example above. It should be noted that the template versions in the ACS Workflow database are transparent to users, meaning that users are unaware of the template revisions. For users, they only need to pull a new branch from the baseline branch, submit and publish the template modifications. If you want to run the workflow, after submission, the newer version of the template in the library will be used by default. This allows the workflow instance running online to gradually converge to the newer version, effectively avoiding template management confusion caused by multiple versions running simultaneously. It should be noted that for simplicity, the aforementioned method embodiments are presented as a series of combined actions. However, those skilled in the art should be aware that this application is not limited by the order of the actions described, as certain steps can be performed in a different order or simultaneously. Furthermore, those skilled in the art should also be aware that the embodiments described in this specification are preferred embodiments, and the actions and modules involved are not necessarily required for this application. Through the above description of the implementation methods, Those skilled in the art will clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, or by hardware, but in many cases the former is a better implementation method.Based on this understanding, the technical solution of this application, or the portion that contributes to the prior art, can essentially be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, a magnetic disk, or an optical disk) and includes instructions for enabling a terminal device (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in various embodiments of this application. Example 3 According to an embodiment of this application, a version processing system as shown in FIG5 is provided. FIG5 is a schematic diagram of a version processing system provided according to Example 3 of this application. The system includes: a target client 501, which is used to manage a target workflow template and submit version change requests to a target platform 502. The target client 501 includes at least a target module, which is used to manage versions of the target workflow template. The version change request includes at least project identification information of the target project; and a target platform 502, which is used to generate a to-be-released branch storing a target version of the target workflow template based on the project identification information, generate a target image for the to-be-released branch, and invoke a target program on a first platform 503 to deploy and release the target image. In an optional embodiment, the version processing system further includes a target component 504, which is configured to provide target services for a target client 501. The target services include at least a first service and a second service, wherein the first service is configured to perform a validity check on the target version content, and the second service is configured to publish the target version. In an optional embodiment, a first platform 503 is configured to deploy the target image to a target runtime environment, where the target runtime environment is configured to run the target image, enabling the target client 501 to initiate a release request to the target component 504. As shown in FIG5 , the CICD platform (i.e., target platform 502) serves as the top-level architecture and includes functions such as image building, template change approval, code review, and security auditing (e.g., testing). It also provides a user-friendly front-end interactive interface and a complete and secure release process. This standardizes the version release process, ensures code quality through process checkpoints, and reduces the complexity of template release. Furthermore, image rollbacks can be made more secure and reliable, enabling a quick and secure rollback in the event of a release error.

[0008] The ACS Workflow-Template-Manager (ACS-Workflow-Template-Manager) is a client (i.e., target client 501) used to manage workflow templates and submit changes for release. It can manage template versions using Git, eliminating the need for additional complex version management functions such as conflict resolution and other complex version control processes.

[0009] ACS is a platform component of ADB, and ACS Workflow (i.e., target component 504) is a component within ACS. Backend operations for templates, such as template verification, template version recording, and template relationship recording, are all performed within the ACS Workflow component, acting as a server for the ACS Workflow-Template-Manager and providing services thereto. The deployment platform (i.e., first platform 503) is responsible for publishing and deploying cloud-native applications to the corresponding runtime environment. In an optional embodiment, a version processing flow is provided, as shown in FIG6 . FIG6 is a schematic diagram of the version processing flow provided according to Example 3 of the present application. As shown in FIG6 , users can use the ACS Workflow-Template-Manager client to modify templates and, using Git, submit a release branch to a remote Git repository.Users can use this branch to submit changes on the CICD platform and apply for release. These changes will undergo code review, unit testing, and integration testing before they are officially released. Therefore, the CICD platform receives version change requests submitted by users through the client and pulls the baseline branch from the client based on the project identification information included in the request. It then generates a new branch based on the Git tool and the baseline branch. Users can modify the new branch (for example, modify the workflow template) to obtain a branch to be released. The user commits the branch to be released and submits it to the remote Git repository. Afterward, the user submits the change for release. The CICD platform receives the user's release request. When releasing the change, the CICD platform automatically builds an image for the version and calls the deployment platform's deployment program, ACS - Workflow-Template-Manager, to deploy the image to the program runtime environment. The image runs, causing the client's branch release program to run (triggering the template release program). It then initiates a release request to ACS-Workflow and calls ACS-Workflow to verify and release the template. ACS-Workflow checks the validity of the modified template. If the validity check fails, ACS-Workflow returns a verification failure result to the client. The client then reports a release failure to the CICD platform, which then reports a release deployment failure to the user. If the validity check passes, the new template version is stored in the database. The database reports a write success to ACS-Workflow, which then reports a release success to the client. The client then reports a template release success to the deployment platform. Upon detecting success, the deployment platform reports a successful deployment success to the CICD platform, which then reports a release success to the user. It's important to note that compared to related techniques where users directly modify and release templates, implementing template releases based on the CICD platform is more secure and makes the workflow system more lightweight. Having the CICD platform manage image building, testing, and other operations makes template releases more convenient and efficient, effectively reducing online failure rates and improving the reliability of workflow template version releases. Furthermore, using mirroring for template rollbacks better implements single-snapshot isolation, making rollbacks more secure and reliable. When release errors occur, rollbacks can be performed quickly and safely, improving rollback efficiency. It's important to note that this solution leverages Git to implement version management features such as isolation between versions and snapshot generation, effectively reducing online failure rates.Furthermore, by integrating the CICD platform with Git version management, template versions are transparent to users, simplifying the template publishing process and usage. This prevents users from being confused about template versions and causing online failures. This makes workflow template publishing more controllable and secure. Furthermore, even if a template is released during the running of an existing workflow, it will not affect the normal operation of the existing workflow. It should be noted that the preferred implementation schemes involved in the above-mentioned embodiments of this application are the same as the solution, application scenarios, and implementation process provided in Example 1, but are not limited to the solution provided in Example 1. Example 4 According to an embodiment of the present application, a version processing method is also provided, as shown in Figure 7, the method includes: step S701, obtaining a version release request uploaded by the client, wherein the version release request includes at least identification information of the branch to be released, and the target version of the target workflow template is stored in the branch to be released; step S702, obtaining the branch to be released in the cloud server based on the identification information of the branch to be released, generating a target image corresponding to the branch to be released, and calling the target program of the first platform to deploy the target image to the target operating environment, wherein the target image is used to implement the template version release of the client, and the target operating environment is used to run the target image, so that the client initiates a release request to the target component, and the release request is used to request the target component to release the target version of the target workflow template; receiving the deployment result returned by the first platform, wherein the deployment result is used to indicate whether the target version of the target workflow template is successfully released; step S703, feeding back the deployment result to the client. The above solution standardizes the template version release process, facilitating the management and control of template version releases and making template version releases more convenient and efficient. Furthermore, when a release exception occurs, the template can be rolled back using the target image, better implementing single snapshot isolation for releases and making rollbacks safer. This reduces online failure rates and improves the reliability of workflow template version releases, thereby resolving the technical issue of low reliability in workflow template version releases in related technologies. The specific method for version processing in the cloud server is the same as that in Example 1 and will not be further described here. It should be noted that, for simplicity, the aforementioned method embodiments are presented as a series of actions. However, those skilled in the art should be aware that this application is not limited by the order of the actions described, as certain steps may be performed in a different order or simultaneously. Furthermore, those skilled in the art should also be aware that the embodiments described in this specification are preferred embodiments, and the actions and modules involved are not necessarily required for this application.Through the above description of the embodiments, those skilled in the art will clearly understand that the methods according to the above embodiments can be implemented using software and the necessary general-purpose hardware platform. Of course, hardware can also be used, but in many cases the former is the preferred implementation method. Based on this understanding, the technical solution of this application, or the portion that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, a magnetic disk, or an optical disk) and includes instructions for enabling a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application. Example 5 According to an embodiment of this application, a version processing device for implementing the above-mentioned version processing method is also provided. As shown in Figure 8, the device includes a first receiving unit 801, a first generating unit 802, and a second receiving unit 803. A first receiving unit 801 is configured to receive a version release request initiated by a target object through a target client, wherein the version release request includes at least identification information of a to-be-released branch, and the to-be-released branch stores a target version of a target workflow template. A first generating unit 802 is configured to obtain a to-be-released branch based on the identification information of the to-be-released branch, generate a target image corresponding to the to-be-released branch, and call a target program of the first platform to deploy the target image to a target runtime environment, wherein the target image is used to implement template version release on the target client, and the target runtime environment is used to run the target image, so that the target client initiates a release request to a target component, wherein the release request is used to request the target component to release the target version of the target workflow template. A second receiving unit 803 is configured to receive a deployment result returned by the first platform, wherein the deployment result is used to indicate whether the target version of the target workflow template has been successfully released.In the version processing device provided in the fifth embodiment of the present application, a first receiving unit 801 receives a version release request initiated by a target object through a target client, wherein the version release request includes at least identification information of a to-be-released branch, and the to-be-released branch stores a target version of the target workflow template; a first generating unit 802 obtains a to-be-released branch based on the identification information of the to-be-released branch, generates a target image corresponding to the to-be-released branch, and calls a target program of the first platform to deploy the target image to a target operating environment, wherein the target image is used to implement template version release for the target client, and the target operating environment is used to run the target image, so that the target client initiates a release request to a target component, wherein the release request is used to request the target component to release the target version of the target workflow template; and a second receiving unit 803 receives a deployment result returned by the first platform, wherein the deployment result is used to indicate whether the target version of the target workflow template has been successfully released. This solution standardizes the template version release process, facilitating the management and control of template version releases, making template version releases more convenient and efficient. Furthermore, when a release exception occurs, the template can be rolled back using the target image, better implementing single snapshot isolation for releases and making rollbacks safer. This reduces online failure rates, thereby improving the reliability of workflow template version releases and resolving the technical issue of low reliability in workflow template version releases in related technologies. Optionally, in the version processing device provided in Example 5 of the present application, the first generation unit 802 includes: a first testing subunit configured to test the branch to be released and obtain a test result; and a first generation subunit configured to generate the target image if the test result indicates that the branch to be released passes the test. Optionally, in the version processing device provided in Example 5 of the present application, the first generation sub-unit includes: a first acquisition module, configured to obtain project identification information of a target project, and detect the number of branches of a to-be-released branch corresponding to the target project based on the project identification information, wherein the target project is used to provide a target workflow template for a target object; a first processing module, configured to merge multiple to-be-released branches if there are multiple branches, to obtain a merged to-be-released branch; and a first determination module, configured to generate an image corresponding to the merged to-be-released branch, and use the image corresponding to the merged to-be-released branch as the target image.Optionally, in the version processing device provided in Example 5 of the present application, the version processing device further includes: a third receiving unit, configured to receive a version change request initiated by the target object through the target client before receiving the version release request initiated by the target object through the target client, wherein the version change request includes at least project identification information; a first determination unit, configured to determine the baseline branch information of the baseline branch of the target project based on the project identification information, and obtain the baseline branch from the target client based on the baseline branch information, wherein the baseline branch stores the target workflow template; a second generation unit, configured to generate a first branch based on the target module and the baseline branch, wherein the first branch is used to implement template change; a first processing unit, configured to respond to the target operation of the target object on the target workflow template in the first branch, and change the target workflow template in the first branch according to the target operation to obtain a branch to be released. Optionally, in the version processing device provided in Example 5 of the present application, the version processing device further includes: a third generating unit, configured to, after receiving the deployment result returned by the first platform, generate prompt information based on the error information when error information of the target component is detected, so as to send the prompt information to the target object, wherein the error information is used to indicate that an abnormality exists in the target workflow template; a fourth receiving unit, configured to receive a version rollback request initiated by the target object, wherein the version rollback request includes at least the version number of the target image to be rolled back; a second determining unit, configured to determine the target image to be rolled back based on the version number of the target image to be rolled back, and obtain a target version snapshot from the target image to be rolled back, wherein the target version snapshot is used to record the version content of the first version of the target workflow template, and the first version indicates the version of the target workflow template to be rolled back; and a second processing unit, configured to perform a rollback operation based on the target image to be rolled back and the target version snapshot to publish the first version. It should be noted that the aforementioned first receiving unit 801, first generating unit 802, and second receiving unit 803 correspond to steps S201 to S203 in Example 1. The aforementioned units and corresponding steps implement the same examples and application scenarios, but are not limited to the contents disclosed in Example 1. It should be noted that the aforementioned modules, as part of the apparatus, can be run in the computer terminal 10 provided in Example 1. It should be noted that the preferred implementation schemes involved in the aforementioned embodiments of this application are the same as the schemes, application scenarios, and implementation processes provided in Example 1, but are not limited to the schemes provided in Example 1.Example 6 According to an embodiment of the present application, a version processing device for implementing the above-mentioned version processing method is also provided. As shown in Figure 9, the device includes: a fifth receiving unit 901, a third processing unit 902, and a fourth processing unit 903. The fifth receiving unit 901 is configured to receive a publishing request through a target component, wherein the publishing request includes at least a target version of a target workflow template; the third processing unit 902 is configured to perform a validity check on the version content of the target version according to a first service to obtain a check result; and the fourth processing unit 903 is configured to publish the target version according to a second service if the check result indicates that the version content of the target version passes the validity check, and store the target version in a target database. In the version processing device provided in Example 6 of the present application, a fifth receiving unit 901 receives a publishing request through a target component, wherein the publishing request includes at least a target version of a target workflow template. A third processing unit 902 performs a validity check on the version content of the target version according to a first service to obtain a check result. If the check result indicates that the version content of the target version passes the validity check, a fourth processing unit 903 publishes the target version according to a second service and stores the target version in a target database. Optionally, in the version processing device provided in Example 6 of the present application, the fourth processing unit 903 includes: a first obtaining subunit configured to obtain a template relationship table and determine a target dependency relationship corresponding to the target workflow template in the template relationship table, wherein the target dependency relationship represents a reference relationship corresponding to the target workflow template; an updating subunit configured to update the target dependency relationship according to a target rule and a target version to obtain an updated template relationship table; and a second obtaining subunit configured to obtain a template content table and store the template identifier of the target workflow template and the version content of the target version in the template content table. It should be noted that the fifth receiving unit 901, third processing unit 902, and fourth processing unit 903 described above correspond to steps S301 to S303 in Example 2. The examples and application scenarios implemented by the aforementioned units and corresponding steps are the same, but are not limited to the content disclosed in Example 2. It should be noted that the preferred implementation schemes involved in the aforementioned embodiments of this application are the same as the schemes, application scenarios, and implementation processes provided in Example 2, but are not limited to the schemes provided in Example 2. Example 7: The embodiments of this application may provide a computer terminal, which may be any computer terminal device in a computer terminal group. Optionally, in this embodiment, the aforementioned computer terminal may be replaced with a terminal device such as a mobile terminal.Optionally, in this embodiment, the computer terminal may be located on at least one of multiple network devices in a computer network. In this embodiment, the computer terminal may execute program code for the following steps in the version processing method: receiving a version release request initiated by a target object via a target client, wherein the version release request includes at least identification information of a to-be-released branch, where the to-be-released branch stores a target version of the target workflow template; obtaining the to-be-released branch based on the identification information of the to-be-released branch, generating a target image corresponding to the to-be-released branch, and invoking a target program on the first platform to deploy the target image to a target runtime environment, wherein the target image is used to implement template version release on the target client, and the target runtime environment is used to run the target image, so that the target client initiates a release request to a target component, wherein the release request is used to request the target component to release the target version of the target workflow template; and receiving a deployment result returned by the first platform, wherein the deployment result indicates whether the target version of the target workflow template was successfully released. The computer terminal may also execute program code for the following steps in the version processing method: generating a target image corresponding to the branch to be released, including: testing the branch to be released and obtaining a test result; if the test result indicates that the branch to be released passes the test, generating the target image. The computer terminal may also execute program code for the following steps in the version processing method: generating a target image, including: obtaining project identification information of a target project, and detecting the number of branches of the branch to be released corresponding to the target project based on the project identification information, wherein the target project is used to provide a target workflow template for a target object; if there are multiple branches, merging the multiple branches to be released to obtain a merged branch to be released; generating an image corresponding to the merged branch to be released, and using the image corresponding to the merged branch to be released as the target image. The computer terminal may also execute the program code of the following steps in the version processing method: before receiving a version release request initiated by the target object through the target client, receiving a version change request initiated by the target object through the target client, wherein the version change request includes at least project identification information; determining the baseline branch information of the baseline branch of the target project based on the project identification information, and obtaining the baseline branch from the target client based on the baseline branch information, wherein the baseline branch stores the target workflow template; generating a first branch based on the target module and the baseline branch, wherein the first branch is used to implement template change; responding to the target operation of the target object on the target workflow template in the first branch, changing the target workflow template in the first branch based on the target operation to obtain a branch to be released.The computer terminal may also execute program code for the following steps in the version processing method: after receiving the deployment result returned by the first platform, if error information of the target component is detected, generating a prompt message based on the error information and sending the prompt message to the target object, wherein the error information indicates an exception in the target workflow template; receiving a version rollback request initiated by the target object, wherein the version rollback request includes at least the version number of the target image to be rolled back; determining the target image to be rolled back based on the version number of the target image to be rolled back, and obtaining a target version snapshot from the target image to be rolled back, wherein the target version snapshot records the version content of the first version of the target workflow template, wherein the first version indicates the version of the target workflow template to be rolled back; performing a rollback operation based on the target image to be rolled back and the target version snapshot to release the first version. Optionally, FIG10 is a block diagram of the structure of a computer terminal according to an embodiment of the present application. As shown in FIG10 , the computer terminal 10 may include: one or more (only one is shown in FIG10 ) processors 102 and a memory 104. The computer terminal 10 may further include a storage controller for controlling and managing the memory 104. The computer terminal 10 may also include a peripheral interface for connecting to a radio frequency module, an audio module, and a display screen. The memory may be used to store software programs and modules, such as the program instructions / modules corresponding to the version processing method and apparatus described in the embodiments of the present application. The processor executes the software programs and modules stored in the memory to perform various functional applications and data processing, thereby implementing the aforementioned version processing method. The memory may include high-speed random access memory (RAM) and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory located remotely from the processor, which may be connected to the terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.The processor can access information and applications stored in the memory through a transmission device to perform the following steps: receiving a version release request initiated by a target object via a target client, wherein the version release request includes at least identification information of a to-be-released branch, and the to-be-released branch stores a target version of the target workflow template; obtaining the to-be-released branch based on the identification information of the to-be-released branch, generating a target image corresponding to the to-be-released branch, and invoking a target program on the first platform to deploy the target image to a target runtime environment, wherein the target image is used to implement template version release on the target client, and the target runtime environment is used to run the target image, so that the target client initiates a release request to a target component, wherein the release request is used to request the target component to release the target version of the target workflow template; receiving a deployment result returned by the first platform, wherein the deployment result indicates whether the target version of the target workflow template was successfully released. Optionally, the processor can further execute program code for the following steps: generating a target image corresponding to the to-be-released branch, including: testing the to-be-released branch to obtain a test result; and generating the target image if the test result indicates that the to-be-released branch passes the test. Optionally, the processor may further execute program code for the following steps: generating a target image, including: obtaining project identification information of a target project, and detecting the number of branches of a to-be-released branch corresponding to the target project based on the project identification information, wherein the target project is used to provide a target workflow template for a target object; if there are multiple branches, merging the multiple to-be-released branches to obtain a merged to-be-released branch; generating an image corresponding to the merged to-be-released branch, and using the image corresponding to the merged to-be-released branch as the target image. Optionally, the processor may further execute program code for the following steps: before receiving a version release request initiated by the target object through the target client, receiving a version change request initiated by the target object through the target client, wherein the version change request includes at least project identification information; determining baseline branch information of the baseline branch of the target project based on the project identification information, and obtaining a baseline branch from the target client based on the baseline branch information, wherein the baseline branch stores a target workflow template; generating a first branch based on the target module and the baseline branch, wherein the first branch is used to implement a template change; responding to a target operation of the target object on the target workflow template in the first branch, changing the target workflow template in the first branch based on the target operation to obtain a branch to be released.Optionally, the processor may further execute program code for the following steps: after receiving the deployment result returned by the first platform, if error information of the target component is detected, generating a prompt message based on the error information and sending the prompt message to the target object, wherein the error information indicates an abnormality in the target workflow template; receiving a version rollback request initiated by the target object, wherein the version rollback request includes at least the version number of the target image to be rolled back; determining the target image to be rolled back based on the version number of the target image to be rolled back, and obtaining a target version snapshot from the target image to be rolled back, wherein the target version snapshot records the version content of the first version of the target workflow template, wherein the first version indicates the version of the target workflow template to be rolled back; performing a rollback operation based on the target image to be rolled back and the target version snapshot to release the first version. Persons skilled in the art will appreciate that the structure shown in FIG. 10 is merely illustrative, and the computer terminal may also be a smartphone (e.g., an Android phone, an iOS phone, etc.), a tablet computer, a PDA, or a mobile internet device (MID), a PAD, or other terminal device. Figure 10 does not limit the structure of the electronic device described above. For example, the computer terminal 10 may include more or fewer components (such as a network interface, a display device, etc.) than those shown in Figure 10, or may have a configuration different from that shown in Figure 10. Those skilled in the art will appreciate that all or part of the steps in the various methods of the above embodiments can be completed by a program instructing the hardware associated with the terminal device. The program can be stored in a computer-readable storage medium, which may include a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk. Example 8 The embodiments of the present application also provide a computer-readable storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the version processing method provided in Example 1. Optionally, in this embodiment, the storage medium can be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals. The serial numbers of the embodiments of the present application are for descriptive purposes only and do not represent the merits or demerits of the embodiments. In the above-described embodiments of this application, the descriptions of each embodiment are given with emphasis. For portions not described in detail in a particular embodiment, reference can be made to the relevant descriptions of other embodiments. It should be understood that the disclosed technical content of the several embodiments provided in this application can be implemented in other ways.The device embodiments described above are merely illustrative. For example, the division of units is merely a logical functional division. In actual implementation, other divisions may be employed. For example, multiple units or components may be combined or integrated into another system, or some features may be omitted or not implemented. Furthermore, the couplings or direct couplings or communication connections shown or discussed may be through interfaces, or indirect couplings or communication connections between units or modules, and may be electrical or other forms. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, i.e., they may be located in one location or distributed across multiple network units. Some or all of these units may be selected to achieve the objectives of the present embodiments as needed. Furthermore, the functional units in the various embodiments of the present application may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. These integrated units may be implemented in either hardware or software functional units. If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, or the portion 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, stored in a storage medium, includes instructions for causing a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memories (ROMs), random access memories (RAMs), removable hard drives, magnetic disks, or optical disks. The above description is merely a preferred embodiment of this application. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this application, and such improvements and modifications should also be considered within the scope of protection of this application.Industrial Applicability The version processing method provided in the embodiment of the present application receives a version release request initiated by a target object through a target client, wherein the version release request includes at least identification information of a to-be-released branch, and the to-be-released branch stores a target version of a target workflow template; obtains the to-be-released branch based on the identification information of the to-be-released branch, generates a target image corresponding to the to-be-released branch, and calls a target program of a first platform to deploy the target image to a target runtime environment, wherein the target image is used to implement template version release for the target client, and the target runtime environment is used to run the target image so that the target client initiates a release request to a target component, wherein the release request is used to request the target component to release the target version of the target workflow template; receives a deployment result returned by the first platform, wherein the deployment result is used to indicate whether the target version of the target workflow template is successfully released. By generating a target image corresponding to the to-be-released branch, template version release can be implemented based on the target image. Compared with the related art in which a user directly modifies and releases a template, this method standardizes the template version release process, facilitates the management and control of template version release, and makes template version release more convenient and quick. In addition, when an exception occurs in the release, Template rollback can also be performed using the target image, better implementing single snapshot isolation for release, making rollback safer and reducing online failure rates. This improves the reliability of workflow template version releases and addresses the low reliability issue of workflow template version releases in related technologies.

Claims

Claims 1. A version processing method, comprising: Receive a version release request initiated by a target object through a target client. The version release request includes at least the identification information of the branch to be released, and the target version of the target workflow template is stored in the branch to be released. Obtain the branch to be released according to the identification information of the branch to be released, generate a target image corresponding to the branch to be released, and call a target program of the first platform to deploy the target image to a target running environment. The target image is used to implement the template version release of the target client, and the target running environment is used to run the target image, so that the target client sends a release request to a target component. The release request is used to request the target component to release the target version of the target workflow template. Receive the deployment result returned by the first platform, where the deployment result is used to indicate whether the release of the target version of the target workflow template is successful.

2. The method according to claim 1, wherein, Generating a target image corresponding to the branch to be released includes: testing the branch to be released to obtain a test result; if the test result indicates that the branch to be released passes the test, generating the target image.

3. The method according to claim 2, wherein Generating the target image includes: obtaining the project identification information of the target project, and detecting the number of branches of the branch to be released corresponding to the target project according to the project identification information. The target project is used to provide the target workflow template for the target object. If the number of branches is multiple, merging the multiple branches to be released to obtain a merged branch to be released; generating an image corresponding to the merged branch to be released, and using the image corresponding to the merged branch to be released as the target image.

4. The method according to claim 3, wherein, Before receiving the version release request initiated by the target object through the target client, the method further includes: receiving a version change request initiated by the target object through the target client. The version change request includes at least the project identification information; determining the baseline branch information of the baseline branch of the target project according to the project identification information, and obtaining the baseline branch from the target client according to the baseline branch information. The target workflow template is stored in the baseline branch; generating a first branch according to the target module and the baseline branch, where the first branch is used to implement template changes. 25 In response to the target operation of the target object on the target workflow template in the first branch, changing the target workflow template in the first branch according to the target operation to obtain the branch to be released.

5. The method according to claim 1, wherein After receiving the deployment result returned by the first platform, the method further includes: in the case of detecting error information of the target component, generating prompt information according to the error information to send the prompt information to the target object, where the error information is used to characterize that there is an abnormality in the target workflow template; receiving a version rollback request initiated by the target object, where the version rollback request at least includes the version number of the target image to be rolled back; determining the target image to be rolled back according to the version number of the target image to be rolled back, and obtaining a target version snapshot from the target image to be rolled back, where the target version snapshot is used to record the version content of the first version of the target workflow template, and the first version represents the version to be rolled back of the target workflow template; performing a rollback operation according to the target image to be rolled back and the target version snapshot to release the first version.

6. A version processing method, comprising: Receiving, by a target component, the release request according to any one of claims 1 to 5, where the release request at least includes the target version of the target workflow template; performing a legality check on the version content of the target version according to a first service to obtain a check result; if the check result indicates that the version content of the target version passes the legality check, then releasing the target version according to a second service and storing the target version in a target database.

7. The method according to claim 6, wherein, Storing the target version in the target database includes: obtaining a template relationship table and determining a target dependency relationship corresponding to the target workflow template in the template relationship table, where the target dependency relationship is used to characterize the reference relationship corresponding to the target workflow template; updating the target dependency relationship according to a target rule and the target version to obtain an updated template relationship table; obtaining a template content table and storing the template identifier of the target workflow template and the version content of the target version in the template content table.

8. A version processing system, comprising: A target client, which is used to manage a target workflow template and submit a version change request to a target platform, where the target client at least includes a target module, and the target module is used to manage the version of the target workflow template, and the version change request at least includes the project identification information of a target project; The target platform, which is used to generate a to-be-released branch storing the target version of the target workflow template according to the project identification information, generate a target image for the to-be-released branch, and call a target program of the first platform to implement the release and deployment of the target image.

9. The system according to claim 8, wherein, The system further includes: a target component, which is used to provide a target service for the target client, and the target service at least includes a first service and a second service. The first service is used to perform a legality check on the version content of the target version, and the second service is used to release the target version.

10. The system according to claim 9, wherein The first platform is used to deploy the target image to a target running environment, where the target running environment is used to run the target image, so that the target client can initiate a release request to the target component.

11. A version processing method, comprising: Obtain a version release request uploaded by a client. The version release request at least includes identification information of a to-be-released branch, and the to-be-released branch stores a target version of a target workflow template. Obtain the to-be-released branch in the cloud server according to the identification information of the to-be-released branch, generate a target image corresponding to the to-be-released branch, and call a target program of the first platform to deploy the target image to the target running environment. The target image is used to implement the template version release of the client, and the target running environment is used to run the target image, so that the client can initiate a release request to the target component. The release request is used to request the target component to release the target version of the target workflow template. Receive a deployment result returned by the first platform, where the deployment result is used to indicate whether the release of the target version of the target workflow template is successful. Feed back the deployment result to the client.

12. A version processing device, comprising: A first receiving unit, configured to receive a version release request initiated by a target object through a target client. The version release request at least includes identification information of a to-be-released branch, and the to-be-released branch stores a target version of a target workflow template. A first generating unit, configured to obtain the to-be-released branch according to the identification information of the to-be-released branch, generate a target image corresponding to the to-be-released branch, and call a target program of the first platform to deploy the target image to the target running environment. The target image is used to implement the template version release of the target client, and the target running environment is used to run the target image, so that the target client can initiate a release request to the target component. The release request is used to request the target component to release the target version of the target workflow template. A second receiving unit, configured to receive the deployment result returned by the first platform, where the deployment result is used to indicate whether the release of the target version of the target workflow template is successful.

13. A computer-readable storage medium, the computer-readable storage medium comprising a stored program, wherein, In When the program runs, it controls the device where the storage medium is located to execute the version processing method according to any one of claims 1 to 7.

14. An electronic device, comprising: A memory, storing an executable program; A processor, configured to run the program. When the program runs, it executes the version processing method according to any one of claims 1 to 7. 28

Images