CN117076150A - Task queue management method and device, electronic equipment and computer readable medium - Google Patents

Abstract

The application provides a task queue management method, equipment and a computer readable medium, wherein the application obtains a task to be issued and a task queue associated with the task to be issued, and the task queue indicates a group of issued priorities of the task to be issued; determining a release priority of the first task based on historical execution information associated with the first task in response to the task to be released being the first task, wherein the historical execution information at least indicates a construction duration of the first task; and adding the first task to the task queue based on the publication priority. Therefore, the task release priority can be dynamically determined at least based on the historical construction time of the task to be released, so that task release can be more reasonably performed, and the task execution efficiency is improved.

Description

Task queue management method and device, electronic equipment and computer readable medium

Technical Field

The present application relates to the field of computer technologies, and in particular, to a method and apparatus for managing task queues, an electronic device, and a computer readable medium.

Background

With the advent of the internet age, software development has become an integral part of modern society.

In order to improve the development efficiency and quality of software, the working mode of realizing the development of the software based on team cooperation is increasingly popularized and used. Typically, a business pipeline can be created in a software development effort to implement code-written, code-based program build tasks of software in its entirety. Thus, how to improve the software development efficiency and quality in this mode is of great concern.

Disclosure of Invention

Aspects of the present application provide a method, apparatus, electronic device, and computer readable storage medium for managing a task queue, which are used to dynamically determine a task publishing priority based at least on a historical construction time of a task to be published, so as to more reasonably publish the task and improve task execution efficiency.

In one aspect of the present application, a method for managing a task queue is provided, including: acquiring a task to be issued and a task queue associated with the task to be issued, wherein the task queue indicates a group of issued priorities of the task to be issued; determining a release priority of the first task based on historical execution information associated with the first task in response to the task to be released being the first task, wherein the historical execution information at least indicates a construction duration of the first task; and adding the first task to the task queue based on the publication priority.

In another aspect of the present application, there is provided a task queue management apparatus including: the system comprises an acquisition module, a transmission module and a transmission module, wherein the acquisition module is configured to acquire a task to be issued and a task queue associated with the task to be issued, and the task queue indicates the issued priority of a group of tasks to be issued; the first determining module is configured to determine the release priority of the first task based on historical execution information associated with the first task in response to the task to be released being the first task, wherein the historical execution information at least indicates the construction duration of the first task; and an adding module configured to add the first task to the task queue based on the publication priority.

In another aspect of the present application, there is provided an electronic apparatus including: at least one processor; and a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of task queue management as described above.

In another aspect of the application, a computer readable storage medium having stored thereon computer program instructions executable by a processor to implement a method of task queue management as described above is provided.

In the scheme provided by the embodiment of the application, the construction of the task to be issued can be performed by utilizing the task queue indicating the issued priority of a group of tasks to be issued. And after acquiring the task to be issued and the task queue associated with the task to be issued, if the task to be issued is a first task with history execution information associated therewith, determining the issue priority of the first task based on the history execution information associated with the first task. Further, the first task is added to the task queue based on the publication priority. Therefore, the task release priority can be dynamically determined at least based on the historical construction time of the task to be released, so that task release can be more reasonably performed, and the task execution efficiency is improved.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following description will briefly explain the drawings used in the embodiments or the description of the prior art, and it is obvious that the drawings in the following description are some embodiments of the present application, and other drawings can be obtained according to these drawings without inventive effort to a person skilled in the art.

Other features, objects and advantages of the present application will become more apparent upon reading of the detailed description of non-limiting embodiments, made with reference to the accompanying drawings in which:

FIG. 1 is a schematic diagram of a task queue management method according to an embodiment of the present application;

FIG. 2 is a schematic diagram illustrating a flow of a task queue management method according to another embodiment of the present application;

FIG. 3 is a schematic diagram of a task queue management device according to an embodiment of the present application;

FIG. 4 is a schematic diagram of the structure of an apparatus suitable for implementing aspects of embodiments of the present application;

the same or similar reference numbers in the drawings refer to the same or similar parts.

Detailed Description

For the purpose of making the objects, technical solutions and advantages of the embodiments of the present application more apparent, the technical solutions of the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application, and it is apparent that the described embodiments are some embodiments of the present application, but not all embodiments of the present application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

In one exemplary configuration of the application, the terminal, the devices of the services network each include one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer-readable media include both permanent and non-permanent, removable and non-removable media, and information storage may be implemented by any method or technology. The information may be computer program instructions, data structures, modules of the program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape storage or other magnetic storage devices, or any other non-transmission medium which can be used to store information that can be accessed by a computing device.

As discussed above, a business pipeline may be created in a software development effort, typically to implement code-written, code-based program build tasks of software in its entirety. In a service pipeline, tasks to be issued are generally managed by using a task queue, for example, a issuing body of a code may sequentially process each task based on an issuing order or an issuing priority indicated by the task queue, so as to implement issuing of a program. In general, such processes may also be referred to as executing tasks, issuing programs, building programs, and so forth, in addition to the issuing of programs.

In general, the associated logic of the release priority of each task to be released in the task queue enters the task queue according to the time sequence to be sequenced and waits. However, such association logic is difficult to adapt to flexible requirements in software development, for example, it is difficult to adapt to adjustment based on the execution situation, the execution value, etc. of the task to be issued, resulting in low use value of the task queue.

The embodiment of the application provides a task queue management method, which comprises the steps of obtaining a task to be issued and a task queue associated with the task to be issued, wherein the task queue indicates the issued priority of a group of tasks to be issued; determining a release priority of the first task based on historical execution information associated with the first task in response to the task to be released being the first task, wherein the historical execution information at least indicates a construction duration of the first task; the first task is added to the task queue based on the publication priority. Therefore, the task release priority can be dynamically determined at least based on the historical construction time of the task to be released, so that task release can be more reasonably performed, and the task execution efficiency is improved.

In an actual scenario, the execution body of the method may be a user device, or a device formed by integrating the user device and a network device through a network, or may also be an application running on the device, where the user device includes, but is not limited to, various terminal devices such as a computer, a mobile phone, a tablet computer, a smart watch, a bracelet, and the network device includes, but is not limited to, a network host, a single network server, a plurality of network server sets, or a computer set based on cloud computing, and the network device may be implemented, for example, to implement a part of processing functions when setting an alarm clock. Here, the Cloud is composed of a large number of hosts or web servers based on Cloud Computing (Cloud Computing), which is a kind of distributed Computing, one virtual computer composed of a group of loosely coupled computer sets.

Fig. 1 shows a flow 100 of a task queue management method according to an embodiment of the present application, where the flow 100 at least includes the following processing steps:

step S101, a task to be issued and a task queue associated with the task to be issued are obtained.

In an embodiment of the present application, tasks to be distributed that are expected to be executed, and a task queue for indicating a priority of the tasks to be distributed to be executed, or, in other words, an order in which the tasks to be distributed are executed, may be acquired. For example, a task to be distributed may be a task composed of codes submitted by respective code developers, and after such task to be distributed is accepted and executed, an execution subject of a server, for example, may generate a corresponding program based on such task to be distributed. In some embodiments, the execution entity or the build entity that builds the program based on the task to be distributed (e.g., a server, a pre-agreed terminal device for building the program, etc.), may collect or retrieve such task to be distributed locally in advance or from a non-local storage device.

In some embodiments, obtaining the task to be issued includes: and responding to the received task release request, and acquiring the task to be released based on the task release request. Specifically, the task build body may continuously obtain codes provided by the code developer and store the codes locally. Further, after the code development task sends the task release request, the task construction body may respond to the task release request to determine code to be used to construct the program. Further, the task construction agent is allowed to execute subsequent tasks based on the codes. Thus, code is developed and provided in a remote device such as a cloud end in a cooperative manner by a code developer.

Similarly, code developers can also request building programs by uploading complete code along with task release requests. Thus, the code developer can select an appropriate mode for submitting the task to be published based on actual requirements to execute program construction.

In some embodiments, such a task queue is used in a continuous integrated CI/continuous delivery CD system in some embodiments. In particular, sustained integration (Continuous Integration) refers to developers frequently submitting code to a version control system and performing automated build, test, and deployment operations. Thus, the code errors can be found and solved in time, and the stability and reliability of the software are ensured. Continuous delivery (Continuous Delivery) is based on continuous integration to enable automated deployment and testing. By continuously automating the process, the process of software delivery can be optimized, the delivery time can be shortened, human errors can be reduced, and the quality and reliability of the software can be improved. Therefore, the CI/CI system can be utilized to continuously and automatically complete the code development flow, and the development efficiency is improved.

In some embodiments, if the task queue is a task queue executing under a CI/CD system, the task to be issued indicates at least one of: code addresses, code types, code frame types, and deployment patterns of program items provided in the CI/CD system. In particular, as explained above, a task to be issued may be an indication that instructs a build subject to build a corresponding program or program item. Accordingly, the task to be issued may be a program to be finally generated, a specific code address, a code type, a code frame type and a deployment mode associated with the program item. Accordingly, the build subject can determine what the developer desires to implement, the resulting program, based on the content, to complete the build. Therefore, pipeline development under the CI/CD system is realized, and the development efficiency of software is improved.

It should be appreciated that for continuous, collaborative code development, tasks that may be performed (or, in other words, tasks that are being developed, are allowed to be developed) may also typically be recorded, stored in advance. For example, a plurality of tasks may be built in the dimension of a program based on a program that is allowed to be built, or an update to a program is allowed, or the like. For example, a task for program a, a task for program B, and so on. Therefore, in the process of submitting the task to be issued, the task can be named in the modes of a naming program A, a naming program B and the like, so that the task to be issued can be submitted more conveniently and efficiently. For example, the task to be issued may be submitted by means of a named program a later, so as to achieve the purposes of updating, continuous development, etc. of the program a.

In step S102, in response to the task to be issued being the first task, the issue priority of the first task is determined based on the history execution information associated with the first task.

In an embodiment of the present application, when a task to be issued is received, the nature of the task to be issued may be determined based on whether the task to be issued was executed, for example, whether code was submitted for the task to be constructed (for example, the task to be issued submitted this time may be an update to a program, or a modification to a program that has been issued, etc.). For example, it may be determined whether the task to be issued is the first task based on whether there is historical execution information associated therewith. If a task to be issued was executed, for example, the issuing task is directed to an existing program a (for example, code provided in the issuing task is updated code for a function in the program a), such a task to be issued may be exemplarily described as a first task for ease of understanding. For such a first task, its corresponding publication priority may be generated based on its associated historical execution information.

In addition, in some embodiments, whether the task to be issued is the first task may be determined based on whether the content pointed to by the task to be issued is executed, and the corresponding historical execution information may be acquired if the task is determined to be the first task.

In an embodiment of the present application, the history execution information indicates at least a construction period of the first task, that is, a period of time required when the program construction for the first task is completed by the history execution. For example, the execution duration may be calculated by recording a start time when the first task is executed to build, and recording an end time after the execution is completed. In some embodiments, if the first task is performed multiple times, the build duration associated with the first task may be obtained by averaging the average duration based on the execution time of each record. Further, after the construction time length is acquired, the release priority corresponding to the first task can be determined based on the construction time length. In some embodiments, to quantify publication priorities, a corresponding priority parameter may be generated based on a particular value of the build time period, e.g., priority credits may be determined based on seconds of the build time period, e.g., 1s corresponds to 1 unit of credits, and a numerical relationship of the priority credits may be utilized to determine the order of publication priorities. In some embodiments, the publication priority is inversely proportional to the build time period, i.e., a first task that is longer in build time period is associated with being executed later, e.g., a task that is 100 units of credit is executed preferentially over a first task that is 200 units of credit. Thus, the short task to be issued is preferentially processed so that the task requiring more time is executed later.

In some embodiments, the historical execution information further indicates at least one of: the method comprises the steps of historical execution success rate, historical execution failure rate, historical interrupted execution rate, historical interrupted times, historical executed times, the ratio of the executed times of the first task in a unit period to the total number of all executed tasks and historical submitted times. In particular, a reference benefit associated with the first task may also be generated based on its historical execution, so as to dynamically adjust its execution priority, i.e., issue priority, based on the level of the reference benefit. For example, a reference benefit may be associated based on historical execution success rates for a dimension of whether construction can be completed sequentially, which can result in the tasks of an ideal, desired program. For example, tasks with higher historical execution success rates (or tasks that can be built sequentially, resulting in an ideal, desired program) may refer to tasks that may have higher yields than tasks with lower execution success rates, and thus tasks with higher historical execution success rates may be executed more preferentially. Similarly, with respect to historical success rates, reference revenue may also be generated based on corresponding historical execution failure rates, which is not repeated at this time. Similarly, for tasks where the build process was interrupted (e.g., by a developer or by a system, etc.), or where the history is interrupted at a higher rate (or, in other words, the frequency of history interrupted execution), the reference benefit may be lower than for tasks that were not interrupted or tasks where the history is interrupted at a lower rate. Similarly, the reference benefit of the first task may also be generated based on the number of times the first task was executed, e.g., the reference benefit of the first task that was executed multiple times may be higher, etc. In addition, in order to generate the reference revenue more dynamically, a preset unit period (for example, a natural day) may be associated, whereby the reference revenue may be generated using, for example, the number of executions within the unit period, etc., to improve the quality of the generation of the reference revenue. In some embodiments, the corresponding reference benefit may also be generated based on the ratio of the number of times the first task is executed to the total number of all executed tasks in the unit period and the historical number of times submitted. Thus, information of each dimension can be associated based on a reference profit manner to generate a higher-value and more accurate release priority.

Illustratively, the historical execution success rate (buildsucccessrate) =the number of times of construction release of the first task/(total number of times of construction release-number of times of construction of human or system interrupt-number of times of construction failure). Similarly, the historical execution failure rate (build failure) =the number of build failures of the first task/the total number of build tasks. Similarly, the history interrupted execution rate (build run rate) =the number of times it is interrupted/the total number of times a task is built in the first task. Therefore, the task to be issued with higher execution benefit can be executed preferentially, so that the task issuing can be performed more reasonably, and the task execution efficiency can be improved.

In some embodiments, if the history execution information indicates a plurality of items, for example, the history execution information indicates a plurality of items indicating a construction period of the first task, a history execution success rate of the first task, a history execution failure rate, a history interrupted execution rate, a history interrupted number of times, a history executed number of times, a ratio of the number of times the first task is executed to the total number of all executed tasks in a unit period, and more than two of the history submitted number of times, in order to determine the release priority of the first task more accurately and in accordance with the demand, a weight coefficient may be configured in advance for the specific content indicated by the history execution information. Accordingly, determining the publication priority of the first task based on the historical execution information associated with the first task includes: and processing the historical execution information associated with the first task by utilizing the pre-configured weight coefficient, and determining the release priority of the first task. For example, the weight coefficient corresponding to the historical execution success rate is 10, the weight coefficient corresponding to the historical interrupted execution rate is 40, the weight coefficient corresponding to the historical execution success rate is 20, the weight coefficient corresponding to the construction duration is 1/60, the ratio of the number of times the first task is executed to the total number of all executed tasks in a unit period and the weight coefficient corresponding to the number of times the history is submitted is 10, etc. Thus, the reference value of the content indicated by the history execution information is dynamically adjusted by the weight coefficient to more accurately determine the distribution priority of the first task. It should be appreciated that where the historical execution information indicates multiple items of content, the operational relationship of the items of content may not be limited to addition operations, and may be "-" (subtraction) for certain dimensions that may be negatively affected (e.g., historical execution failure rates) with corresponding operators, thereby balancing the priority relationship in a manner that utilizes subtraction.

In such a case, the order in which the first tasks are executed in the task queue may be positively correlated with the issue priority (for example, the higher the unit score corresponding to the line level is issued, the higher the priority may be executed). Illustratively, the unit score of the release priority = history execution success rate 10-history interrupted execution rate 40-history execution failure rate 20+ the ratio of the number of times the first task is executed to the total number of all executed tasks in the unit period and the weight coefficient corresponding to the number of times the history is submitted 10-construction duration/60.

In addition, in some embodiments, in response to receiving an update event for the historical execution information, the historical execution information is updated based on content indicated by the update event, the update event being used to indicate at least one of the historical execution information. In particular, for historical execution information associated with the first task, it may also be updated based on the corresponding update event. For example, for a first task that is interrupted while it is currently being executed, its corresponding history may be updated (e.g., added once) for the number of times it was interrupted. Thus, the quality of use of the history execution information is ensured in such a manner that timeliness of the history execution information is ensured.

Step S103, adding the first task to the task queue based on the issue priority.

In an embodiment of the present application, after determining the release priority of the first task, the adding position of the first task in the task queue may be determined based on the release priority thereof. For example, two other first tasks closest to their unit credits are determined based on the publication priorities of the first tasks. For example, the first task in the current task queue has a publication priority of 100 points, 150 points, 200 points, 230 points. If the release priority of the first task which is expected to be inserted currently is 170 points, the two first tasks of 150 points and 200 points can be taken out, and the current first task is selected to be inserted between the two first tasks of 150 points and 200 points. For example, the issue priority of completing the first task in the inserted task queue is 100 points, 150 points, 170 points, 200 points, 230 points. Thus, the insertion of the first task is completed, and the execution of the tasks and the construction of the program are continued in the order of the tasks in the task queue. It should be understood that after the first task is executed, the historical execution information may be updated based on the case where the first task is executed this time (for example, the historical execution information may be updated based on the execution duration of this time).

In addition, in some embodiments, the task to be issued may be a task that has not been executed, or the task to be issued may not yet be associated with "historical execution information". Such a task to be issued may be described as a second task for ease of understanding. For the case where the second task exists, reference may be made to fig. 2 at the same time, and fig. 2 shows a process flow 200 of a task queue management method according to another embodiment of the present application. In fig. 2, step S201 may also be included for determining whether the task to be issued is the first task or the second task. If the task to be issued is the first task, step S102 and step S203 may be performed to add the first task to the task queue in the manner described above, and the description thereof will not be repeated here.

If the task to be issued is a second task, step S202 may be executed to determine the issue priority of the second task based on the issue time of the second task. Specifically, the conversion relationship between the issue time and the above-described "integral" may be set in a similar manner to determine the second task corresponding issue priority. Further, after step S202 is performed to determine the issue priority of the second task, step S203 may be performed to add the second task to the task queue to be executed.

In some embodiments, after step S203 is performed, step S204 may be performed during the process of the second task being performed, to record the status of the second task being performed "first". For example, the execution duration when "first" is executed, and so forth. Accordingly, after the second task is performed "first", step S205 may be continued to be performed to convert the execution status into the history execution information of the second task. It should be appreciated that after the second task has been executed "for the first time", because it has associated historical execution information, the second task may already be considered as being converted into a "first task" at this time, and thus, when executed again for such a task later, it may be processed as the first task to be inserted into the task queue to implement an automated management flow of the task queue.

In some embodiments, for the process of inserting the second task into the task queue, the second task may also be directly inserted into the task queue based on the release time. For example, the target task in the task queue is determined based on the closest time relation between the release completion time and the release time of the second task, for example, the task queue includes the release completion time of 00:30, 00:50, if the release time of the second task is 00:32, the task with the release completion time of 00:30 can be determined as the target task. Further, the second task may be inserted after the target task so that the second task is performed as soon as possible after the currently performed task is completed. Therefore, on the premise of not interrupting the existing execution process, the second task is executed as early as possible, execution delay caused by the fact that the second task is not executed is avoided, and the second task can be executed smoothly is ensured. And, such a manner may also complete the "first" execution of the second task as early as possible to translate it into a "first task", collecting historical execution information associated therewith.

In some embodiments, if there is already a task to be published in the task queue, for example, the first task or the second task has been previously submitted to the task queue. If the task queue is detected to have the task to be distributed, the task to be distributed which is already included in the task queue can be selected and removed, the corresponding distribution priority is determined based on the task to be distributed which is acquired this time, and task addition aiming at the task queue is completed. Thus, abnormal errors caused by code and data changes due to, for example, post-update can be avoided, and the execution quality of the task can be ensured.

In the solution provided by the embodiment of the present application, the task queue indicating the published priority of a group of tasks to be published may be used to execute the construction of the tasks to be published. And after acquiring the task to be issued and the task queue associated with the task to be issued, if the task to be issued is a first task with history execution information associated therewith, determining the issue priority of the first task based on the history execution information associated with the first task. Further, the first task is added to the task queue based on the publication priority. Therefore, the task release priority can be dynamically determined at least based on the historical construction time of the task to be released, so that task release can be more reasonably performed, and the task execution efficiency is improved.

In addition, the embodiment of the application also provides a task queue management device, and the structure of the device is shown as a device 300 in fig. 3. The apparatus 300 includes: an acquisition module 310 configured to acquire a task to be published and a task queue associated with the task to be published, wherein the task queue indicates a set of priorities at which the task to be published is published; a first determining module 320 configured to determine, in response to the task to be issued being a first task, an issue priority of the first task based on historical execution information associated with the first task, wherein the historical execution information indicates at least a construction duration of the first task; the adding module 330 is configured to add the first task to the task queue based on the publication priority.

In some embodiments, the apparatus 300 further comprises: and the second determining module is configured to determine the release priority of the second task based on the release time of the second task in response to the task to be released being the second task.

In some embodiments, the apparatus 300 further comprises: and a recording module configured to record historical execution information associated with the second task in response to the second task completing execution.

In some embodiments, the historical execution information further indicates at least one of: the method comprises the steps of historical execution success rate, historical execution failure rate, historical interrupted execution rate, historical interrupted times, historical executed times, the ratio of the executed times of the first task in a unit period to the total number of all executed tasks and historical submitted times.

In some embodiments, if the historical execution information indicates a plurality of items, determining the publication priority of the first task based on the historical execution information associated with the first task includes: and processing the historical execution information associated with the first task by utilizing the pre-configured weight coefficient, and determining the release priority of the first task.

In some embodiments, the apparatus 300 further comprises: and an update module configured to update the history execution information based on the content indicated by the update event in response to receiving the update event for the history execution information, the update event being for indicating at least one of the update history execution information.

In some embodiments, the task queue is used in a continuously integrated CI/continuously delivered CD system.

In some embodiments, the task to be issued indicates at least one of: code addresses, code types, code frame types, and deployment patterns of program items provided in the CI/CD system.

In some embodiments, obtaining the task to be issued includes: and responding to the received task release request, and acquiring the task to be released based on the task release request.

Based on the same inventive concept, the embodiment of the present application further provides an electronic device, where the corresponding method of the electronic device may be the task queue management method in the foregoing embodiment, and the principle of solving the problem is similar to that of the method. The electronic equipment provided by the embodiment of the application comprises: at least one processor; and a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the methods and/or aspects of the various embodiments of the application described above.

The electronic device may be a user device, or a device formed by integrating the user device and a network device through a network, or may also be an application running on the device, where the user device includes, but is not limited to, various terminal devices such as a computer, a mobile phone, a tablet computer, a smart watch, a bracelet, and the network device includes, but is not limited to, a network host, a single network server, a plurality of network server sets, or a computer set based on cloud computing, and the network device may be implemented, for example, to implement a part of processing functions when setting an alarm clock. Here, the Cloud is composed of a large number of hosts or web servers based on Cloud Computing (Cloud Computing), which is a kind of distributed Computing, one virtual computer composed of a group of loosely coupled computer sets.

Fig. 4 shows a structure of a device 400 suitable for implementing the method and/or technical solution in an embodiment of the present application, the device 400 comprising a central processing unit (CPU, central Processing Unit) 401, which may perform various suitable actions and processes according to a program stored in a Read Only Memory (ROM) 402 or a program loaded from a storage section 408 into a random access Memory (RAM, random Access Memory) 403. In the RAM 403, various programs and data required for the system operation are also stored. The CPU 401, ROM 402, and RAM 403 are connected to each other by a bus 404. An Input/Output (I/O) interface 405 is also connected to bus 404.

The following components are connected to the I/O interface 405: an input section 406 including a keyboard, a mouse, a touch panel, a microphone, an infrared sensor, and the like; an output portion 407 including a display such as a Cathode Ray Tube (CRT), a liquid crystal display (LCD, liquid Crystal Display), an LED display, an OLED display, and a speaker; a storage portion 408 comprising one or more computer-readable media of hard disk, optical disk, magnetic disk, semiconductor memory, etc.; and a communication section 409 including a network interface card such as a LAN (local area network ) card, a modem, or the like. The communication section 409 performs communication processing via a network such as the internet.

In particular, the methods and/or embodiments of the present application may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method shown in the flow chart. The above-described functions defined in the method of the present application are performed when the computer program is executed by a Central Processing Unit (CPU) 401.

Another embodiment of the present application also provides a computer readable storage medium having stored thereon computer program instructions executable by a processor to implement the method and/or the technical solution of any one or more of the embodiments of the present application described above.

In particular, the present embodiments may employ any combination of one or more computer-readable media. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples (a non-exhaustive list) of the computer-readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

The computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, either in baseband or as part of a carrier wave. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations of the present application may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, smalltalk, C ++ and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer (for example, through the Internet using an Internet service provider).

The flowchart or block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of devices, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described systems, apparatuses and units may refer to corresponding procedures in the foregoing method embodiments, which are not repeated herein.

In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the elements is merely a logical function division, and there may be additional divisions in actual implementation, e.g., multiple elements or page components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in hardware plus software functional units.

The integrated units implemented in the form of software functional units described above may be stored in a computer readable storage medium. The software functional unit is stored in a storage medium, and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) or a processor (processor) to perform part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present application, and are not limiting; although the application has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present application.

Furthermore, it is evident that the word "comprising" does not exclude other elements or steps, and that the singular does not exclude a plurality. A plurality of units or means recited in the apparatus claims can also be implemented by means of one unit or means in software or hardware. The terms first, second, etc. are used to denote a name, but not any particular order.

Claims (12)

1. A method of managing a task queue, comprising:

acquiring a task to be issued and a task queue associated with the task to be issued, wherein the task queue indicates the issued priority of a group of tasks to be issued;

determining a release priority of the first task based on historical execution information associated with the first task in response to the task to be released being the first task, wherein the historical execution information at least indicates construction duration of the first task; and

the first task is added to the task queue based on the publication priority.

2. The method of claim 1, further comprising:

and responding to the task to be issued as a second task, and determining the issuing priority of the second task based on the issuing time of the second task.

3. The method of claim 2, further comprising:

In response to the second task completing execution, historical execution information associated with the second task is recorded.

4. The method of claim 1, the historical execution information further indicating at least one of: the first task comprises a historical execution success rate, a historical execution failure rate, a historical interrupted execution rate, a historical interrupted number of times, a historical executed number of times, a ratio of the first task executed number of times to the total number of all executed tasks in a unit period and a historical submitted number of times.

5. The method of claim 4, wherein if the historical execution information indicates a plurality of items, the determining a publication priority of the first task based on the historical execution information associated with the first task comprises:

and processing historical execution information associated with the first task by utilizing a pre-configured weight coefficient, and determining the release priority of the first task.

6. The method of claim 4, further comprising:

in response to receiving an update event for the historical execution information, the historical execution information is updated based on content indicated by the update event, the update event being for indicating updating of at least one of the historical execution information.

7. The method of claim 1, the task queue is used in a continuously integrated CI/continuously delivered CD system.

8. The method of claim 7, wherein the task to be issued indicates at least one of: code addresses, code types, code frame types, and deployment patterns of program items provided in the CI/CD system.

9. The method of claim 1, wherein obtaining a task to be published comprises:

and responding to the received task release request, and acquiring the task to be released based on the task release request.

10. A task queue management apparatus, wherein the apparatus comprises:

the system comprises an acquisition module configured to acquire a task to be issued and a task queue associated with the task to be issued, wherein the task queue indicates a group of priorities of the task to be issued;

a first determining module configured to determine, in response to the task to be issued being a first task, an issue priority of the first task based on historical execution information associated with the first task, wherein the historical execution information indicates at least a construction duration of the first task; and

An add module configured to add the first task to the task queue based on the publication priority.

11. An electronic device, the electronic device comprising:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein,

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1 to 9.

12. A computer readable medium having stored thereon computer program instructions executable by a processor to implement the method of any of claims 1 to 9.