Task processing method and device, electronic equipment, storage medium and program product

Abstract

The present disclosure provides a task processing method and device, an electronic device, a storage medium and a program product. The method comprises: obtaining a target task script; splitting the target task script according to a node restart instruction in the target task script to obtain a plurality of execution segments of the target task script; sequentially executing the plurality of execution segments, recording an execution state and controlling a first service node to perform node restart processing after one execution segment is executed on the first service node, and continuing to execute a next execution segment according to the recorded execution state after the first service node is restarted, so as to perform integration and deployment processing on a target application. According to the embodiments of the present disclosure, the integration and deployment efficiency of the target application can be improved.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a task processing method and apparatus, electronic device, storage medium, and program product. Background Technology

[0002] With the widespread application of Continuous Integration / Continuous Deployment (CI / CD) technology in the software development field, CI / CD tasks have become the core carrier for automating the entire process of application building, testing, and deployment. During the execution of CI / CD tasks, it is often necessary to execute a system restart command, such as in scenarios involving driver installation, dependency library updates, or system parameter configuration, to ensure that the relevant operations take effect.

[0003] In related technologies, during the execution of a CI / CD task that includes a system restart command, when the system restart command is executed, the device often immediately performs a system restart and disconnects from the CI / CD system, causing the task execution to be interrupted, which in turn leads to the failure of the pipeline task execution, affecting the integration and deployment efficiency of the application. The pipeline task can be used to chain multiple CI / CD tasks in the order of execution to form an automated execution process.

[0004] Therefore, improving the efficiency of application integration and deployment has become an urgent technical problem to be solved. Summary of the Invention

[0005] This disclosure provides a task processing method and apparatus, electronic device, storage medium, and program product.

[0006] In a first aspect, this disclosure provides a task processing method, which includes: obtaining a target task script; wherein the target task script includes instructions for integrating and deploying a target application; splitting the target task script according to node restart instructions in the target task script to obtain multiple execution segments of the target task script; sequentially executing the multiple execution segments; after one execution segment is completed on a first service node, recording the execution status and controlling the first service node to restart the execution node; after the first service node restarts, continuing to execute the next execution segment according to the recorded execution status to perform integration and deployment processing on the target application; wherein the first service node is used to integrate and deploy the target application.

[0007] Secondly, this disclosure provides a task processing apparatus, comprising: an acquisition module for acquiring a target task script; wherein the target task script includes instructions for integrating and deploying tasks for a target application; a splitting module for splitting the target task script according to node restart instructions in the target task script to obtain multiple execution segments of the target task script; and an execution module for sequentially executing the multiple execution segments, recording the execution status and controlling the first service node to restart the execution node after one of the multiple execution segments has been executed on a first service node, and continuing to execute the next execution segment of the multiple execution segments according to the recorded execution status after the first service node has restarted, so as to perform integration and deployment processing on the target application; wherein the first service node is used to integrate and deploy the target application.

[0008] Thirdly, this disclosure provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores one or more computer programs executable by the at least one processor, the one or more computer programs being executed by the at least one processor to enable the at least one processor to perform the above-described task processing method.

[0009] Fourthly, this disclosure provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the above-described task processing method.

[0010] Fifthly, this disclosure provides a computer program product comprising computer-readable code, which, when executed in a processor of an electronic device, performs the aforementioned task processing method.

[0011] The task processing method provided in this embodiment obtains a target task script for integrating and deploying a target application. Then, it splits the target task script into multiple execution segments according to a node restart instruction and executes each execution segment in sequence. After an execution segment is completed on a first service node, the execution status is recorded and the first service node is controlled to perform node restart processing. After the first service node is restarted, the next execution segment is executed according to the recorded execution status, thereby performing integration and deployment processing on the target application.

[0012] Based on the embodiments of this disclosure, without manual intervention, the control node running the CI / CD system can automatically split the target task script according to the node restart command. By sequentially executing multiple execution segments, after one execution segment completes execution on the first service node used for integrating and deploying the target application, the execution segment is recorded, and the first service node is controlled to restart. After the first service node restarts, the next execution segment continues execution based on the recorded execution status. This allows the control node to continue executing subsequent execution segments from the current segment after a node restart, avoiding task interruption and failure. This improves the continuity and automation of the target application integration and deployment tasks, reduces manual intervention, and enhances the efficiency of application integration and deployment. Furthermore, by sequentially executing these multiple execution segments, it is unnecessary to pre-configure restart logic in the CI / CD system pipeline configuration, thereby decoupling the business execution logic from the CI / CD control configuration and reducing the complexity of task configuration and maintenance.

[0013] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0014] The accompanying drawings are provided to further illustrate the present disclosure and form part of the specification. They are used together with the embodiments of the present disclosure to explain the disclosure and do not constitute a limitation thereof. The above and other features and advantages will become more apparent to those skilled in the art from the description of detailed exemplary embodiments with reference to the accompanying drawings, which are described below.

[0015] Figure 1 A flowchart of a task processing method provided in an embodiment of this disclosure.

[0016] Figure 2 A flowchart of the splitting process provided for embodiments of this disclosure.

[0017] Figure 3 A flowchart illustrating the integration and deployment process provided for embodiments of this disclosure.

[0018] Figure 4 This is a flowchart for obtaining the current segment index provided in an embodiment of this disclosure.

[0019] Figure 5 This is a schematic diagram of the verification process provided in an embodiment of this disclosure.

[0020] Figure 6 A timing diagram illustrating the integration and deployment processes provided in embodiments of this disclosure.

[0021] Figure 7 This is a block diagram of a task processing apparatus provided in an embodiment of the present disclosure.

[0022] Figure 8 This is a block diagram of an electronic device provided in an embodiment of the present disclosure. Detailed Implementation

[0023] To enable those skilled in the art to better understand the technical solutions of this disclosure, exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments of this disclosure to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0024] Where there is no conflict, the various embodiments of this disclosure and the features thereof in the embodiments may be combined with each other.

[0025] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0026] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Words such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0027] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this disclosure, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined herein.

[0028] Currently, continuous integration and continuous deployment of applications can generally be achieved based on CI / CD systems, which can be implemented using automation tools such as Jenkins, GitLab CI, or GitHub Actions.

[0029] During continuous integration and continuous deployment of applications, pipeline tasks can typically be configured in a CI / CD system. These pipeline tasks can include one or more CI / CD tasks for the application. For example, Task 1 might be configured to install Driver 1, execute a system restart command, and test if Driver 1 was successfully installed; Task 2 might be configured to install Driver 2; Task 3 might be configured to install the dependencies required for the application to run; Task 4 might be configured to retrieve the latest code for the application and perform integration compilation to generate the application's installation file; and Task 5 might be configured to install the application's installation file to deploy the application. Of course, this is just an example; in actual implementation, the CI / CD tasks configured in the application's pipeline tasks within the CI / CD system, as well as the order of these tasks, can be set as needed.

[0030] As described in the background section, when a CI / CD task in a pipeline configuration includes a system reboot instruction, such as a reboot instruction, the execution node used for integrating and deploying applications, such as a server, will immediately restart after the system reboot instruction is executed during the execution of the CI / CD task. This restart of the execution node will cause its connection with the CI / CD system to be broken. After the connection is broken, the CI / CD system detects the interruption of the CI / CD task execution and marks the pipeline task as failed. Once the pipeline task is marked as failed, even if the execution node restarts successfully, it cannot continue executing other instructions following the system reboot instruction, thus causing the integration and deployment of the application to fail.

[0031] To address the aforementioned issues, the applicant discovered that it is advisable for developers to manually split task scripts containing system restart instructions into multiple independent tasks, eliminating the use of system restart instructions within the task scripts, and further managing state transfer between tasks manually to prevent task interruptions.

[0032] However, manually managing the state transfer between tasks generally requires developers to manually add state saving codes, manually specify save locations, and specify recovery logic in the task scripts. This process is complex to configure and difficult to maintain, and may still affect the integration and deployment efficiency of the application.

[0033] To this end, the applicant further discovered that it is also possible to consider having pipeline development users—that is, users who configure pipeline tasks in the CI / CD system—cooperate with business development users who develop applications. Business development users would break down the CI / CD tasks that include system restart instructions into multiple independent tasks, and inform the pipeline development users of the business steps that need to be executed for restarting. The pipeline development users would then explicitly handle the system restart logic in the pipeline tasks, thereby avoiding pipeline task failures and improving the integration and deployment efficiency of applications to a certain extent.

[0034] However, this approach requires deep coupling between Pipeline configuration and business logic. That is, Pipeline developers need to have a deep understanding of the business details in the business logic of integrating and deploying the application, and specifically adapt the restart process in the configuration file of the Pipeline task, which leads to unclear boundaries of responsibility. Furthermore, when the business logic changes, Pipeline developers also need to modify both the Pipeline configuration and the business scripts, which still results in complex configuration and difficult maintenance, thus affecting the efficiency of application integration and deployment.

[0035] In view of this, the present disclosure provides a task processing method. After obtaining a target task script for integrating and deploying a target application, the target task script is split into multiple execution segments according to a node restart instruction. Each execution segment is executed sequentially. After an execution segment is completed on a first service node, the execution status is recorded and the first service node is controlled to restart. After the first service node restarts, the next execution segment is executed according to the recorded execution status, thereby performing integration and deployment processing on the target application.

[0036] Based on the embodiments of this disclosure, without manual intervention, the control node running the CI / CD system can automatically split the target task script according to the node restart command. By sequentially executing multiple execution segments, after one execution segment completes execution on the first service node used for integrating and deploying the target application, the execution segment is recorded, and the first service node is controlled to restart. After the first service node restarts, the next execution segment continues execution based on the recorded execution status. This allows the control node to continue executing subsequent execution segments from the current segment after a node restart, avoiding task interruption and failure. This improves the continuity and automation of the target application integration and deployment tasks, reduces manual intervention, and enhances the efficiency of application integration and deployment. Furthermore, by sequentially executing these multiple execution segments, it is unnecessary to pre-configure restart logic in the CI / CD system pipeline configuration, thereby decoupling the business execution logic from the CI / CD control configuration and reducing the complexity of task configuration and maintenance.

[0037] The task processing method according to embodiments of this disclosure can be executed by a control node, which has a CI / CD system installed and deployed, such as a CI / CD system based on the Jenkins automation tool. This control node can be used to perform integration and deployment processing of applications on a service node (e.g., a server). The control node can be a server or a terminal device, which can be an in-vehicle device, user equipment (UE), mobile device, user terminal, terminal, computing device, etc. The method can be implemented by a processor calling computer-readable program instructions stored in memory. Alternatively, the method can be executed by a server.

[0038] Figure 1 A flowchart illustrating a task processing method provided in an embodiment of this disclosure. (Refer to...) Figure 1 The method may include the following steps S11-S13, which are described in detail below.

[0039] Step S11: Obtain the target task script.

[0040] The target task script includes instructions for integrating and deploying the target application. This integration and deployment task can correspond to a complete pipeline task, or it can correspond to a CI / CD task within a complete pipeline task.

[0041] It is understood that the target task script may include at least one node restart instruction. Of course, even if the target task script does not include node restart instructions, the target application can still be integrated and deployed based on the methods provided in the embodiments of this disclosure, and this disclosure does not impose any special limitations on this.

[0042] In this embodiment of the disclosure, the target application can be any application that needs to perform continuous integration and deployment processing, and this disclosure does not impose any special limitations on it.

[0043] A target task script is an automated execution script used for continuous integration and continuous deployment tasks of a target application. It contains one or more instructions and can be used to implement the application's dependency installation, driver configuration, building, testing, deployment and other processing flows.

[0044] Specifically, the target task script can be, for example, a script containing the following content.

[0045] test-app1-driver:

[0046] stage: "test" / / Corresponds to the test phase.

[0047] - “install_driver.sh” / / Install the driver.

[0048] - "reboot" / / Reboot the system.

[0049] - "run_test.sh" / / Run the test.

[0050] - "reboot" / / Reboot the system.

[0051] - "cleanup.sh" / / Clean up.

[0052] It should be noted that the above is only an example. In actual implementation, the content of the target task script corresponding to the target application can be set as needed, and the number of target task scripts can also be set as needed. This disclosure does not impose any special limitations on this.

[0053] Step S12: Based on the node restart instructions in the target task script, split the target task script to obtain multiple execution fragments of the target task script.

[0054] Each execution segment includes at least one instruction from the target task script.

[0055] That is, each execution chunk can correspond to a part of the target task script, and the content of different execution chunks is different.

[0056] A node restart command can be a command used to trigger a system restart on a service node (such as a server) where the target application is deployed; that is, it can be the system restart command described above. This node restart command can be the "reboot" command in operating systems such as UNIX and Linux, or the "shutdown" command in operating systems like Windows, depending on the system type.

[0057] For example, for the target task script mentioned above, the control node can identify the node restart command "reboot" and split it into the following execution fragments: {execution fragment 0: ["install_driver.sh"], execution fragment 1: ["run_test.sh"], execution fragment 2: ["cleanup.sh"]}.

[0058] Specifically, after obtaining the target task script based on step S11, the control node can automatically analyze the node restart instructions in the script without manual intervention. Based on the position of each node restart instruction in the script, the target task script is sequentially divided into multiple execution segments.

[0059] It should be noted that, in actual implementation, the multiple execution fragments obtained from the splitting can be stored and managed in any form such as a set, array, or list, and this disclosure does not impose any special restrictions on this.

[0060] Step S13: Execute multiple execution segments sequentially. After an execution segment is completed on the first service node, record the execution status and control the first service node to restart. After the first service node restarts, continue to execute the next execution segment according to the recorded execution status to perform integration and deployment processing on the target application.

[0061] In this embodiment of the disclosure, the execution status can be used to identify the execution progress of multiple execution segments to indicate the target execution segment to be executed. This execution status can be stored in the status file of the first service node, or it can be set as needed, for example, stored in a database; this disclosure does not impose any special limitations on this.

[0062] In this embodiment of the disclosure, the control node can update the execution status after each execution segment is completed, so that after the execution node restarts processing, it can read the execution status to continue executing the next execution segment among multiple execution segments, thereby avoiding task failure caused by the CI / CD pipeline being disconnected due to node restart.

[0063] The first service node is used for integrating and deploying the target application. That is, the first service node is the service node used for integrating and deploying the target application, and the control node can control the execution of various execution segments on the first service node to perform integration and deployment processing of the target application.

[0064] After obtaining multiple execution segments corresponding to the target task script, the control node can automatically execute these segments sequentially. After each segment is completed, the execution status is updated and recorded. Then, the first service node is controlled to restart the execution node. After the node restarts, the recorded execution status is read again, and the next execution segment is executed based on the execution status. In this way, by having the control node automatically split the target task script and persistently save the execution status representing the execution progress, it is beneficial to reduce the situation where pipeline tasks are marked as failed due to task interruption, thereby improving the integration and deployment efficiency of the target application.

[0065] As can be seen, the method provided by this disclosure can automatically split the target task script according to the node restart command by the control node running the CI / CD system without manual intervention. Multiple execution segments are executed sequentially. After one execution segment completes execution on the first service node used for integrating and deploying the target application, the execution segment is recorded and the first service node is controlled to restart. After the first service node restarts, the next execution segment continues execution based on the recorded execution status. This allows the control node to continue executing subsequent execution segments from the current segment after a node restart, avoiding task interruption and failure. This improves the continuity and automation of the target application integration and deployment tasks, reduces manual intervention, and enhances the efficiency of application integration and deployment. Furthermore, by executing these multiple execution segments sequentially, it is not necessary to pre-configure restart logic in the CI / CD system pipeline configuration, thereby decoupling the business execution logic from the CI / CD control configuration and reducing the complexity of task configuration and maintenance.

[0066] The task processing method according to the embodiments of this disclosure will now be described in detail.

[0067] In some embodiments, step S12, which involves splitting the target task script according to the node restart instructions in the target task script to obtain multiple execution segments, may include: splitting the target task script using the position of each node restart instruction in the target task script as a splitting point to obtain multiple execution segments, wherein each execution segment does not include node restart instructions.

[0068] That is, in step S12, the control node can analyze the content of the target task script and use the location of the node restart instruction, such as the reboot instruction, in the script as a split point. Based on this split point, the target task script can be split into multiple execution fragments. For example, the multiple execution fragments in the example above can be obtained as follows: {Execution fragment 0: ["install_driver.sh"], Execution fragment 1: ["run_test.sh"], Execution fragment 2: ["cleanup.sh"]}.

[0069] After obtaining the multiple execution fragments: {execution fragment 0: ["install_driver.sh"], execution fragment 1: ["run_test.sh"], execution fragment 2: ["cleanup.sh"]}, when initially executing these multiple execution fragments sequentially, the execution status initially identifies the first execution fragment among the multiple execution fragments as the target execution fragment to be executed. Therefore, the control node can first use execution fragment 0: ["install_driver.sh"] as the target execution fragment and execute the instruction "install_driver.sh" on the first service node. After execution, the execution status is updated and recorded. Then, the control node automatically controls the first service node to perform node restart processing without manual intervention or prior configuration. After the node restarts, the control node reads the recorded execution status and determines that the target execution segment to be executed is execution segment 1: ["run_test.sh"]. Therefore, the instruction "run_test.sh" can continue to be executed on the first service node. After execution, the execution status is updated and recorded again. Then, the control node automatically controls the first service node to perform node restart processing until the instruction "cleanup.sh" in the last execution segment 2 is executed, so as to automatically and continuously integrate and deploy the target application.

[0070] As can be seen, based on the method provided in this disclosure, by automatically splitting the script and recording the execution status, the node restart and subsequent business instructions can be completed without interrupting the overall task flow. There is no need for manual intervention to split the task or manually resume execution after restarting, which is beneficial to improving the continuity of target application integration and deployment and reducing configuration and maintenance complexity.

[0071] Please refer to Figure 2 This is a flowchart of the splitting process provided in the embodiments of this disclosure. For example... Figure 2 As shown, in some embodiments, the step of splitting the target task script by using the position of each node restart instruction in the target task script as the splitting point to obtain multiple execution fragments may include the following steps S21-25.

[0072] Step S21: Use the position of each node restart instruction in the target task script as a split point to obtain multiple split points.

[0073] Here, we will still use the target task script as an example to illustrate the above. The target task script contains two node restart commands "reboot". After the control node analyzes the script content and identifies the two node restart commands, it can take the position of each node restart command as a split point, and finally obtain two split points, denoted as split point A, which corresponds to the position of the first node restart command, and split point B, which corresponds to the position of the second node restart command. That is, multiple split points are {split point A, split point B}.

[0074] Step S22: Based on the instructions from the starting position of the target task script to the starting split point of multiple split points, obtain the first execution segment.

[0075] The starting split point refers to the first split point arranged in the order of instructions in the target task script. In the example, the starting split point is split point A. The instructions from the beginning of the target task script to split point A are only "install_driver.sh". Therefore, this instruction can be used as the first execution segment, that is, the first execution segment is ["install_driver.sh"], corresponding to execution segment 0 in the example above.

[0076] Step S23: Based on the instructions between each pair of adjacent split points of the multiple split points, at least one second execution segment is obtained.

[0077] The two adjacent split points refer to any two adjacent split points among multiple split points. Of course, when there are only two split points, these two split points refer to the start split point and the end split point, that is, the instruction segment between the start split point and the end split point is regarded as a second execution segment; while when there are more than two split points, the instruction segment between any two adjacent split points can be regarded as a second execution segment.

[0078] For example, if there are two splitting points, such as splitting point A and splitting point B mentioned above, then two adjacent splitting points are the starting splitting point and the ending splitting point, and the instruction between them is "run_test.sh". Therefore, this instruction is used as a second execution segment, that is, the second execution segment is ["run_test.sh"], corresponding to execution segment 1 in the example above. It should be noted that if the target task script contains three or more node restart instructions, multiple adjacent intermediate splitting points will be obtained, resulting in at least one second execution segment. This disclosure does not impose any special limitations on this.

[0079] Step S24: Based on the instructions between the end split point of multiple split points and the end position of the target task script, the third execution segment is obtained.

[0080] The end split point refers to the last split point in the order of instructions in the target task script. In the example, the end split point is split point B mentioned above. The instructions between split point B and the end of the target task script are "cleanup.sh". Therefore, this instruction is used as the third execution segment, i.e., the third execution segment is ["cleanup.sh"], corresponding to execution segment 2 in the example above.

[0081] Step S25: Based on the first execution segment, at least one second execution segment, and the third execution segment, multiple execution segments are obtained.

[0082] That is, through the above processing, we can obtain the first execution fragment as ["install_driver.sh"], the second execution fragment as ["run_test.sh"], and the third execution fragment as ["cleanup.sh"]. By integrating these three execution fragments, we can obtain multiple execution fragments corresponding to the target task script, namely {execution fragment 0: ["install_driver.sh"], execution fragment 1: ["run_test.sh"], execution fragment 2: ["cleanup.sh"]}.

[0083] It should be noted that in actual implementation, the `chunk` array can be initialized to store the split execution fragments, and the `currentChunk` array can be initialized to cache execution fragments when traversing the target task script. That is, traversal can begin from the start of the target task script. If the traversed instruction (also called a script item) is not a node restart instruction, execution continues until a split point is reached, i.e., a node restart instruction is encountered. At this point, the contents of the `currentChunk` array are saved to the `chunk` array, and the `currentChunk` array is cleared before skipping the split point. This process is repeated until the entire script is traversed. In other words, different forms of coding implementation can be performed based on the principles of S21-S25 of this disclosure.

[0084] It should also be noted that the above examples are only illustrative of the methods provided by the embodiments of this disclosure. In actual implementation, the number of instructions and the number of node restart instructions in the target task script can be set according to requirements. Regardless of the number of split points, the target task script can be split based on the methods provided by the embodiments of this disclosure to obtain multiple execution segments, so as to ensure that each execution segment does not contain node restart instructions. This avoids the task interruption caused by the unplanned restart of the first service node during task execution, which would lead to the failure of the integration and deployment of the target application, thereby further improving the integration and deployment efficiency of the target application.

[0085] It is understood that, in some embodiments, the method may further include: taking the position of each node restart instruction in the target task script as a split point to obtain one split point; then the instructions before and after the split point can be taken as an execution segment to obtain multiple execution segments.

[0086] In other words, if the target task script contains only one node restart instruction, then the instructions before the node restart instruction can be used as one execution segment, and the instructions after the node restart instruction can be used as another execution segment, resulting in multiple execution segments. The detailed process will not be elaborated here.

[0087] Of course, if the target task script does not include node restart instructions, then there is no need to split the target task script.

[0088] Please refer to Figure 3 This is a flowchart of the integration and deployment process provided in the embodiments of this disclosure. For example... Figure 3 As shown, in some embodiments, step S13 involves sequentially executing multiple execution segments. After an execution segment is completed on the first service node, the execution status is recorded and the first service node is controlled to restart. After the first service node restarts, the next execution segment is executed according to the recorded execution status to perform integration and deployment processing on the target application. This may include the following steps S31-S34.

[0089] Step S31: Obtain the execution status, where the execution status is used to indicate the target execution segment to be executed.

[0090] Specifically, this execution status can be primarily achieved by updating and recording the data "current segment index currentChunk". This current segment index is an integer, starting from 0. A value of 0 indicates that the target execution segment to be executed is the first of multiple execution segments, while a value of 1 indicates the second execution segment, and so on. It should be noted that in actual implementation, this execution status may also include other data fields; this disclosure does not impose any special limitations on this.

[0091] After obtaining multiple execution segments based on step S12, the control node can execute these multiple execution segments sequentially. During the initial execution, since the initial value of the current segment index is 0, the control node can determine that the target execution segment to be executed is the first execution segment when it obtains that the current segment index is 0, for example, execution segment 0 in the above example: ["install_driver.sh"].

[0092] It should be noted that in this embodiment, the execution status of multiple execution segments is represented by recording the current segment index. In actual implementation, the execution status can also be recorded directly through the "executeStatus" data field, and this disclosure does not impose any special limitations on this. Furthermore, the initial value of the current segment index can be set to 0 by default (corresponding to the first execution segment), or it can be flexibly set according to actual execution needs. For example, the value 1 can represent the first execution segment, the value 2 can represent the second execution segment, and so on. This disclosure does not impose any special limitations on this. Additionally, the current segment index can be obtained from a configuration file or a database, such as a Redis database, and this disclosure does not impose any special limitations on this.

[0093] Step S32: Based on the execution status, control the first service node to execute the target execution segment.

[0094] After obtaining the target execution segment to be executed based on the current segment index, the control node can send an execution instruction to the first service node to control the first service node to execute the target execution segment.

[0095] For example, if the current fragment index is 0 initially, the control node can determine that the target execution fragment is execution fragment 0, and thus control the first service node to execute the instruction "install_driver.sh" to complete the driver installation related processing.

[0096] Step S33: If the first service node has completed the execution of the target execution segment and the target execution segment is not the last execution segment among multiple execution segments, update the execution status and control the first service node to restart the execution node.

[0097] In other words, after the first service node finishes executing the current target execution segment, it returns a completion signal to the control node. Upon receiving this signal, the control node determines whether the currently executing target execution segment is the last among multiple execution segments. For example, if currentChunk is 0, and after the control node controls the first service node to execute the aforementioned execution segment 0, the control node determines that it is not the last execution segment. In this case, it can update the current segment index from 0 to 1 to record the execution status and send a restart command to the first service node, controlling its execution node to restart the process so that the driver installation and configuration corresponding to execution segment 0 takes effect.

[0098] Of course, when currentChunk is 1, after executing the above execution segment 1, this segment is not the last execution segment. The control node can update the current segment index from 1 to 2 and control the first service node to perform the restart process again. If the target execution segment is the last execution segment, such as the above execution segment 2, then there is no need to update the execution status or control the first service node to perform the restart process. The execution process can be terminated directly.

[0099] Step S34: Perform online detection processing on the first service node. After detecting that the first service node has restarted and come online, continue to execute the next execution segment according to the updated execution status.

[0100] After controlling the first service node to perform a restart, the control node can continuously monitor the first service node's online status. This monitoring can include network connectivity checks and service status checks to ensure the first service node has fully restarted and returned to normal operation. Once the first service node is detected as back online, the control node can determine the execution status based on the updated current segment index and continue executing the next execution segment until all execution segments are completed, thus achieving the integration and deployment of the target application.

[0101] It should be noted that the above examples are only used to illustrate the methods provided by the embodiments of this disclosure. In actual implementation, the update logic of the execution status and the online detection method of the first service node can be set as needed, and this disclosure does not impose any special limitations on them.

[0102] As can be seen, based on the method provided in this disclosure, the control node can precisely control the sequential execution of each execution segment, achieving precise connection of execution progress after node restart. It can restore execution after restart without manual intervention, thereby reducing the problem of task execution interruption, improving the continuity, automation and execution efficiency of target application integration and deployment, and also decoupling business execution logic from CI / CD system configuration, reducing the complexity of task configuration and maintenance.

[0103] Please refer to Figure 4 This is a flowchart of obtaining the current segment index provided in an embodiment of this disclosure. For example... Figure 4 As shown, in some embodiments, obtaining the current segment index in step S31 may include the following steps S41-S42.

[0104] Step S41: In the case of initial execution of multiple execution segments, create status files corresponding to multiple execution segments on the first service node, and obtain the execution status from the status files.

[0105] The status file is used to record the execution status of multiple execution segments.

[0106] As shown above, in related technologies, when a task is manually split into multiple independent tasks, in order to avoid task interruption, it is often necessary to implement code in each task to save and read the task execution status. After the node restarts, the task status needs to be read manually to continue executing the next task, which has the problems of cumbersome configuration and difficult maintenance.

[0107] Therefore, in this embodiment of the disclosure, after obtaining multiple execution segments based on step S12, each execution segment is executed sequentially. For example, before step S31 above, if the control node determines that the current time is the initial start of the execution of the multiple execution segments, a status file can be automatically created on the first service node so as to obtain the intermediate state of task execution during the execution of the execution segments and ensure the continuity of task execution.

[0108] Furthermore, to ensure multi-platform compatibility, in this embodiment, the state file can be a JSON file, with a filename such as ci-reboot-state.json. Additionally, storing this state file on the first service node executing the target application is considered for the sake of task processing uniformity. In actual implementation, the state file can, of course, be stored in other locations as needed, and this disclosure does not impose any special limitations on this.

[0109] It is understood that, in addition to including the current fragment index mentioned above, the status file can also store multiple execution fragments obtained above as needed. For example, execution fragment 0, execution fragment 1, and execution fragment 2 can be stored in a two-dimensional array scriptChunks. Furthermore, it should be noted that the status file can also store some uniform configurations in the pipeline tasks corresponding to the target application. For example, task configuration information can be stored based on the "job" field, global configuration information can be stored based on the "config" field, and script phases (whose content can be "before_script / script / after_script") can be stored based on the "phase" field. This disclosure does not impose any special limitations on this.

[0110] That is, in this embodiment of the disclosure, the status file may include, for example, the following content.

[0111] {

[0112] “currentChunk”: 0, / / Current fragment index.

[0113] “scriptChunks”: [ / / Array of execution fragments.]

[0114] ["install_driver.sh", "..."], / / Execution fragment 0.

[0115] ["run_test.sh", "test_driver"], / / Execution fragment 1.

[0116] ["cleanup.sh", "rm -rf / tmp / test"], / / Execution fragment 2.

[0117] ],

[0118] "job": { / / Task configuration information.

[0119] "name": "...", / / Task name.

[0120] "stage": "...", / / Task stage.

[0121] "timeout": "...", / / Timeout duration.

[0122] },

[0123] "config": { / / Global configuration information.

[0124] …

[0125] },

[0126] “phase”: script, / / script phase.

[0127] "rebootCount": 0, / / Reboot count.

[0128] …, / / other.

[0129] }

[0130] Step S42: If the current execution is not the initial execution of multiple execution segments, directly obtain the execution status from the status file.

[0131] It is understandable that, in the case that multiple execution segments are not being executed at the current moment, that is, during task execution, since the aforementioned status file has already been created at the initial moment, and the index of the current segment in the status file has been updated before the execution node restarts processing, the current segment index can be directly read from the status file to determine the current execution status of the multiple execution segments.

[0132] As can be seen, based on the method provided in this disclosure, the control node can accurately determine the execution status by creating and maintaining a status file, thereby achieving the initialization of the execution progress during initial execution and the accurate recovery of the execution progress after restart, without the need for manual intervention to record the execution progress. This can further improve the automation level of target application integration and deployment, reduce the occurrence of task execution interruptions and progress loss, and improve task execution efficiency; at the same time, it can also reduce the complexity of task configuration and maintenance.

[0133] Please refer to Figure 5 This is a schematic diagram of the verification process provided in the embodiments of this disclosure. Figure 5 As shown, in some embodiments, the method may further include the following steps S51-S53.

[0134] Step S51: If the target execution segment has been completed on the first service node and the target execution segment is the last execution segment, obtain the restart count.

[0135] The restart count is used to record the number of times the first service node actually performs node restart processing during integration and deployment.

[0136] The reboot count, rebootCount, can be used to determine the actual number of reboots of the first service node during task execution. The reboot count can be updated in step S33 above, while updating the current segment index.

[0137] Step S52: Determine the planned number of restarts for the first service node during integration and deployment processing based on the number of multiple execution fragments.

[0138] The planned restart count is the theoretical number of times the first service node should perform node restart processing during the integration and deployment of the target application.

[0139] Understandably, the number of planned restarts can be determined based on the number of execution fragments obtained by splitting the target task script. That is, subtracting 1 from the number of execution fragments gives the planned restart count. For example, if the number of execution fragments is 3, the planned restart count is 2.

[0140] Step S53: If the restart count and the planned restart count are consistent, determine that the integration and deployment process has been completed.

[0141] That is, in order to avoid errors in task execution after the control node has executed the last execution segment, in this embodiment of the disclosure, the actual number of restarts of the node, i.e., the restart count, can be obtained and compared with the planned number of restarts. If the two values ​​are consistent, it means that the first service node has completed all restart processing as expected and all execution segments have been executed. At this time, it can be determined that the integration and deployment processing of the target application has been completed. If the two values ​​are inconsistent, it means that there is a restart omission or anomaly. The control node can further investigate the anomaly, for example, perform rollback processing, i.e., re-execute the multiple execution segments to ensure the integrity of the integration and deployment processing of the target application.

[0142] Understandably, once the integration and deployment process for the target application is confirmed to be complete, the control node can mark the pipeline task corresponding to that target application as successful; the details of the process will not be elaborated here.

[0143] For easier understanding, please refer to Figure 6 This is a timing diagram illustrating the integration and deployment processing provided in the embodiments of this disclosure. The following uses the example of {execution fragment 0: [“install_driver.sh”], execution fragment 1: [“run_test.sh”], execution fragment 2: [“cleanup.sh”]} obtained by splitting the target task script as an example to illustrate the execution timing of the task processing method of this disclosure.

[0144] like Figure 6As shown, in the case of "first execution", that is, the current moment is the initial execution of the multiple execution fragments, the control node can first perform the "create status file" process on the first service node used for integrating and deploying the target application. That is, create a status file to record the execution status of the multiple execution fragments. The status file can include the current execution fragment index currentChunk mentioned above, and its initial value is 0. It can also initialize the scriptChunks array to store the multiple execution fragments mentioned above.

[0145] After creating the status file, the control node reads currentChunk as 0, then retrieves the first execution segment from scriptChunks, i.e., execution segment 0 (chunk0), and starts execution. After chunk0 is executed, i.e., after the "install_driver.sh" command is executed, the control node can perform the "update status" process, that is, update currentChunk in the status file to 1 and update rebootCount to 1.

[0146] After that, such as Figure 6 As shown, the control node can send a node restart command to the first service node to control the first service node to perform system restart processing.

[0147] Please continue reading. Figure 6 In the case of "re-online", that is, after the first restart, when the first service node is detected to be online again, the control node first performs the "detection of the existence of the status file" process.

[0148] If a status file already exists, the "read execution status" process can proceed. This involves reading the latest `currentChunk` from the status file. Since `currentChunk` was updated to 1 before the first service node executed the node restart command, then... Figure 6 As shown, the control node can perform the "skip execution segment 0, execute execution segment 1" process, that is, skip execution segment 0 (chunk0) and control the first service node to execute the second execution segment, that is, execution segment 1 (chunk1). After the "run_test.sh" instruction in the second execution segment is completed, the control node continues to perform the "update status" process, thereby updating currentChunk in the status file to 2 and the reboot count to 2.

[0149] Then, the control node sends a node restart command to the first service node to control the first service node to perform system restart processing.

[0150] Please continue reading. Figure 6 Upon "re-online," i.e., after the second restart, if the first service node is detected to be back online, the control node will still first perform the "check if the status file exists" process. If the status file exists, it will then perform the "read execution status" process, retrieving the latest currentChunk from the status file. Since currentChunk was updated to 2 before the first service node executed the second node restart command, then... Figure 6 As shown, the control node can execute the process of "skipping execution segments 0 and 1, and executing execution segment 2". That is, the control node can skip execution segments 0 (chunk0) and 1 (chunk1) and control the first service node to execute the third execution segment, i.e., execution segment 2 (chunk2). After executing the "cleanup.sh" command in this third execution segment, since chunk2 is the last execution segment, the control node can obtain the planned restart count and execute the process of "confirming whether the planned restart count matches the restart count". If they match, the integration and deployment of the target application is confirmed to be complete. In this case, to avoid interference from the existing state file when executing these multiple execution segments again, it can be done as follows: Figure 6 As shown, after performing the "delete status file" process, the task execution focus can be returned from the first service node to the control node, and the control node can mark the pipeline task as "task completed".

[0151] It should be noted that, in Figure 6 The dashed lines in the diagram represent the separation of the processing before and after each node restart process, and do not limit the methods provided in the embodiments of this disclosure.

[0152] As can be seen, based on the method provided in this disclosure, the control node can accurately verify the completion status of the integration and deployment processing for the target application, avoiding deployment failures caused by missed restarts or incomplete execution, thereby improving the reliability and integrity of the integration and deployment of the target application.

[0153] In some embodiments, step S34, when performing online detection processing on the first service node, may include: after controlling the first service node to perform node restart processing, controlling the second service node to perform online detection processing on the first service node according to a preset period using a preset detection instruction.

[0154] The second service node, also known as the jump server node, can be a node that has established a communication connection with the control node, and the second service node can be in the same service cluster network as the first service node.

[0155] The preset period can be a fixed time interval, such as 10 seconds, 30 seconds, etc.

[0156] These preset detection commands can include network connectivity detection commands, port detection commands, or system status detection commands. For example, if the CI / CD system being used is based on Jenkins, the first service node can be checked for online status using the Jenkins API interface node.getComputer().isOffline().

[0157] In other words, in actual implementation, after the first service node performs the node restart process, it will usually disconnect from the first service node. In related technologies, in this case, the execution focus of the pipeline task will usually return to the CI / CD system. However, since the pipeline task has not yet been completed, that is, it is in an interrupted state, the CI / CD system will mark the pipeline task as having failed.

[0158] Therefore, in this embodiment of the disclosure, after the control node performs the node restart process, the control node switches the execution focus of the pipeline task to the second service node to preserve the continuity of pipeline task execution and avoid the task being marked as failed due to task return, thereby improving the continuity of application integration and deployment tasks.

[0159] In some embodiments, the method may further include: if the first service node is not detected to be online within a preset time period using a preset detection command, obtaining the address information of the first service node, performing a hardware restart process on the first service node through a preset remote power supply control interface based on the address information, and continuing to perform online detection processing on the first service node; wherein the preset time period is longer than a preset period.

[0160] The preset duration can be set as needed, for example, it can be 10 minutes.

[0161] This address information could be, for example, the IP address of the first service node.

[0162] Specifically, during the online detection of the first service node by the second service node according to a preset cycle, if the first service node is not detected to be online within a preset time period, it indicates that the first service node may have experienced software freezes, abnormal hangs, or other faults, and cannot be restored online by software restart alone. In this case, the control node obtains the address information of the first service node and, based on this address information, calls a preset remote power supply control interface to perform a hardware restart process, such as a power-off restart, on the first service node, thereby forcibly restoring its operation at the hardware level. For example, this can be achieved using the command `curl -X POST http: / / xxx.com / ${first service node's IP} / pdu_restart`.

[0163] After the hardware restart process is completed, the control node continues to control the second service node to perform online detection processing on the first service node according to a preset cycle and using preset detection instructions, until the first service node is detected to be back online, so as to ensure that subsequent execution segments can be executed normally.

[0164] As can be seen, the method provided by the embodiments of this disclosure can quickly restore the node status by hardware restart when the first service node fails to go online normally, which is conducive to improving the fault tolerance and stability of the deployment process and ensuring that the target application integration and deployment tasks can be executed smoothly.

[0165] In some embodiments, the process of controlling the first service node to perform node restart processing described above may include: obtaining the system type of the operating system used by the first service node; and controlling the first service node to perform node restart processing using a node restart instruction corresponding to the operating system, based on the system type.

[0166] System type indicates the operating system used by the first service node, such as a UNIX-like operating system, a Windows operating system, etc.

[0167] Understandably, when controlling the first service node to execute the node restart command, the corresponding command can be used based on its system type to control the restart process. For example, in the case of a "UNIX" system, the restart command for that system, namely the "reboot" command, can be used to control the first service node to execute the restart process. In the case of a "Windows" system, the restart command for that system, namely the "shutdown -r -t 5" command, can be used to control the first service node to execute the restart process. Here, the shutdown command is the main shutdown control command built into the Windows system, the -r parameter is used to specify the restart operation, and the -t 5 parameter indicates that the delay time is set to 5 seconds. The system will automatically complete the device restart after waiting for 5 seconds. The specific values ​​can be set as needed; this is only for illustrative purposes.

[0168] As can be seen, by automatically selecting the corresponding node restart instruction based on the operating system type, the compatibility of the method provided in this embodiment can be improved, enabling it to adapt to different platforms and ensuring that node restart and subsequent processes can be executed normally under different operating environments, thereby further improving the stability of target application integration and deployment.

[0169] It is understood that the various method embodiments mentioned above in this disclosure can be combined with each other to form combined embodiments without violating the principle and logic. Due to space limitations, this disclosure will not elaborate further. Those skilled in the art will understand that in the above methods of specific implementation, the specific execution order of each step should be determined by its function and possible internal logic.

[0170] In addition, this disclosure also provides a task processing apparatus, an electronic device, and a computer-readable storage medium, all of which can be used to implement any of the task processing methods provided in this disclosure. The corresponding technical solutions and descriptions are described in the corresponding section of the method and will not be repeated here.

[0171] Figure 7 This is a block diagram of a task processing apparatus provided in an embodiment of the present disclosure.

[0172] Reference Figure 7 This disclosure provides a task processing device, which includes: an acquisition module 701, a splitting module 702, and an execution module 703.

[0173] The acquisition module 701 is used to acquire the target task script; wherein, the target task script includes instructions for integrating and deploying tasks for the target application.

[0174] The splitting module 702 is used to split the target task script according to the node restart instructions in the target task script to obtain multiple execution fragments of the target task script.

[0175] The execution module 703 is used to execute multiple execution segments sequentially. After an execution segment is completed on the first service node, the execution status is recorded and the first service node is controlled to restart. After the first service node is restarted, the next execution segment is executed according to the recorded execution status to perform integration and deployment processing on the target application. The first service node is used to integrate and deploy the target application.

[0176] In some embodiments, when the splitting module 702 splits the target task script according to the node restart instructions in the target task script to obtain multiple execution fragments of the target task script, it can be used to: split the target task script with the position of each node restart instruction in the target task script as the splitting point to obtain multiple execution fragments, wherein each execution fragment does not include node restart instructions.

[0177] In some embodiments, when the execution module 703 executes multiple execution segments sequentially, records the execution status and controls the first service node to restart after one execution segment is completed on the first service node, and continues to execute the next execution segment according to the recorded execution status after the first service node restarts, in order to perform integration and deployment processing on the target application, it can be used to: obtain the execution status, wherein the execution status is used to indicate the target execution segment to be executed; control the first service node to execute the target execution segment according to the execution status; update the execution status and control the first service node to restart if the first service node has completed the execution of the target execution segment and the target execution segment is not the last execution segment among multiple execution segments; perform online detection processing on the first service node, and continue to execute the next execution segment according to the updated execution status after detecting that the first service node has restarted and gone online.

[0178] In some embodiments, when the execution module 703 obtains the execution status, it may be used to: create a status file corresponding to multiple execution segments on the first service node when the current execution is the initial execution of multiple execution segments, and obtain the execution status from the status file; when the current execution is not the initial execution of multiple execution segments, directly obtain the execution status from the status file.

[0179] In some embodiments, the apparatus may further include a verification module, which may be used to: obtain a restart count when the first service node has completed the execution of the target execution segment and the target execution segment is the last execution segment, wherein the restart count is used to record the number of times the first service node actually performs node restart processing during the integration and deployment process; determine the planned number of restarts of the first service node during the integration and deployment process based on the number of multiple execution segments; and determine that the integration and deployment process has been completed when the restart count and the planned number of restarts are consistent.

[0180] In some embodiments, when the execution module 703 performs online detection processing on the first service node, it can be used to: after controlling the first service node to perform node restart processing, control the second service node to perform online detection processing on the first service node according to a preset period using preset detection instructions.

[0181] In some embodiments, the device may further include a detection module, which can be used to: if the first service node is not detected to be online within a preset time period using a preset detection command, obtain the address information of the first service node, perform hardware restart processing on the first service node through a preset remote power supply control interface based on the address information, and continue to perform online detection processing on the first service node; wherein the preset time period is longer than the preset period.

[0182] In some embodiments, when controlling the first service node to perform node restart processing, the execution module 703 may be used to: obtain the system type of the operating system used by the first service node; and, based on the system type, use a node restart instruction corresponding to the operating system to control the first service node to perform node restart processing.

[0183] Figure 8 This is a block diagram of an electronic device provided in an embodiment of the present disclosure.

[0184] Reference Figure 8 This disclosure provides an electronic device, which includes: at least one processor 801; at least one memory 802; and one or more I / O interfaces 803 connected between the processor 801 and the memory 802; wherein the memory 802 stores one or more computer programs that can be executed by the at least one processor 801, and the one or more computer programs are executed by the at least one processor 801 to enable the at least one processor 801 to perform the above-described task processing method.

[0185] This disclosure also provides a computer-readable storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the task processing method described above. The computer-readable storage medium may be volatile or non-volatile.

[0186] This disclosure also provides a computer program product including computer-readable code, which, when run in a processor of an electronic device, enables the processor in the electronic device to perform the task processing method described above.

[0187] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0188] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0189] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0190] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.

[0191] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0192] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0193] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0194] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

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

[0196] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in connection with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in connection with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of this disclosure as set forth by the appended claims.

Claims

1. A task processing method, characterized in that, The method includes: Obtain the target task script; wherein the target task script includes instructions for integrating and deploying tasks for the target application; Based on the node restart instructions in the target task script, the target task script is split into multiple execution segments; wherein, the multiple execution segments are obtained by splitting the target task script by using the position of each node restart instruction in the target task script as the splitting point; The multiple execution segments are executed sequentially. After an execution segment is completed on the first service node, the execution status is recorded and the first service node is controlled to restart. After the first service node restarts, the next execution segment is executed according to the recorded execution status to perform integration and deployment processing on the target application. The first service node is used to integrate and deploy the target application.

2. The method according to claim 1, characterized in that, The step of splitting the target task script according to the node restart instructions in the target task script to obtain multiple execution fragments of the target task script includes: The target task script is split into multiple execution segments by using the position of each node restart instruction in the target task script as the split point, wherein each execution segment does not include the node restart instruction.

3. The method according to claim 1, characterized in that, The process involves sequentially executing the multiple execution segments. After one execution segment completes execution on the first service node, the execution status is recorded, and the first service node is restarted. After the first service node restarts, the next execution segment is executed based on the recorded execution status to perform integration and deployment processing on the target application, including: Obtain the execution status, wherein the execution status is used to indicate the target execution segment to be executed currently; Based on the execution status, control the first service node to execute the target execution segment; If the first service node completes the execution of the target execution segment, and the target execution segment is not the last execution segment among the plurality of execution segments, the execution status is updated, and the first service node is controlled to restart the processing. The first service node is subjected to an online detection process. After the first service node is detected to have restarted and come online, the next execution segment is executed according to the updated execution status.

4. The method according to claim 3, characterized in that, The step of obtaining the execution status includes: In the case where the execution of the plurality of execution segments is currently in the initial stage, a status file corresponding to the plurality of execution segments is created on the first service node, and the execution status is obtained from the status file; If the execution of the plurality of execution segments is not currently being performed initially, the execution status is obtained directly from the status file.

5. The method according to claim 3, characterized in that, The method further includes: When the first service node completes the execution of the target execution segment, and the target execution segment is the last execution segment, a restart count is obtained, wherein the restart count is used to record the number of times the first service node actually performs node restart processing during the integration and deployment process; Based on the number of the plurality of execution fragments, determine the planned number of restarts for the first service node during the integration and deployment process; If the restart count matches the planned restart count, the integration and deployment process is considered complete.

6. The method according to claim 3, characterized in that, The online detection process performed on the first service node includes: After controlling the first service node to perform node restart processing, the second service node is controlled to perform online detection processing on the first service node according to a preset period using preset detection instructions.

7. The method according to claim 6, characterized in that, The method further includes: If the first service node is not detected to be online within a preset time period using the preset detection command, the address information of the first service node is obtained, and a hardware restart process is performed on the first service node through a preset remote power supply control interface based on the address information, and the online detection process of the first service node continues to be performed; wherein, the preset time period is longer than the preset period.

8. The method according to claim 1, characterized in that, The step of controlling the first service node to perform node restart processing includes: Obtain the system type of the operating system used by the first service node; Based on the system type, the first service node is controlled to perform node restart processing using a node restart instruction corresponding to the operating system.

9. A task processing device, characterized in that, include: An acquisition module is used to acquire a target task script; wherein, the target task script includes instructions for integrating and deploying tasks for a target application; The splitting module is used to split the target task script according to the node restart instructions in the target task script to obtain multiple execution segments of the target task script; wherein, the multiple execution segments are obtained by splitting the target task script with the position of each node restart instruction in the target task script as the splitting point; An execution module is used to execute the plurality of execution segments sequentially. After one of the execution segments is completed on the first service node, the execution status is recorded and the first service node is controlled to restart the execution node. After the first service node is restarted, the next execution segment of the plurality of execution segments is executed according to the recorded execution status to perform integration and deployment processing on the target application. The first service node is used to integrate and deploy the target application.

10. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores one or more computer programs that can be executed by the at least one processor, the one or more computer programs being executed by the at least one processor to enable the at least one processor to perform the task processing method as described in any one of claims 1-8.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the task processing method as described in any one of claims 1-8.

12. A computer program product, characterized in that, It includes computer-readable code, which, when executed in a processor of an electronic device, causes the processor in the electronic device to perform the task processing method as described in any one of claims 1-8.

Images