WO2011144132A1 - 软件持续集成的方法、装置和系统 - Google Patents

软件持续集成的方法、装置和系统 Download PDF

Info

Publication number
WO2011144132A1
WO2011144132A1 PCT/CN2011/075091 CN2011075091W WO2011144132A1 WO 2011144132 A1 WO2011144132 A1 WO 2011144132A1 CN 2011075091 W CN2011075091 W CN 2011075091W WO 2011144132 A1 WO2011144132 A1 WO 2011144132A1
Authority
WO
WIPO (PCT)
Prior art keywords
subtask
agent
proxy
agents
executable
Prior art date
Application number
PCT/CN2011/075091
Other languages
English (en)
French (fr)
Inventor
王佥
孙达
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2011144132A1 publication Critical patent/WO2011144132A1/zh

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5055Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering software capabilities, i.e. software resources associated or available to the machine

Definitions

  • the present invention relates to the field of continuous integration technologies, and in particular, to a method, device and system for continuous software integration.
  • CI Continuous Integration
  • the CI system decomposes each CI task into multiple CI subtasks, such as splitting the CI task of a software into Get the latest code, compiled code, package, release, install, automated test, quality inspection, and data metrics, etc.
  • Subtasks by continuously executing CI subtasks, can detect and fix software defects as early as possible. It can be seen that the advantages and disadvantages of different CI systems can have different effects on software development efficiency and input cost.
  • the existing CI system is shown in Figure 1. It is mainly composed of a CI master and a CI agent.
  • the main steps of the CI for the software are as follows: First, the user issues a CI task to a CI master; and then, the CI master Controlling the CI task into multiple CI subtasks, and delivering the CI subtask to the corresponding CI agent for execution, wherein each CI agent is responsible for executing the CI task type is fixed; finally, by the corresponding CI The agent executes the CI subtask and returns the execution result to the CI master.
  • the embodiment of the invention provides a method for continuous software integration, so as to implement load sharing between CI agents and improve
  • an embodiment of the present invention provides a method for continuous software integration, including:
  • the destination CI agent sends the current executable subtask to the destination CI agent, so that the destination CI agent executes the executable subtask, and the at least two CI agents are general purpose computing units.
  • the embodiment of the invention further provides a device for continuous integration of software, the device comprising:
  • An executable subtask receiving module is configured to receive and manage a CI subtask sent by the CI master;
  • a destination CI proxy determining module configured to determine to perform at least one CI subtask currently managed according to an online communication state of at least two CI agents in the currently managed CI proxy resource pool, and a computing resource idle state of the at least two CI agents
  • the current CI agent of the current executable subtask and sends the current executable subtask to the destination CI agent, so that the destination CI agent executes the executable subtask, the at least two CI agents It is a general purpose computing unit.
  • the embodiment of the present invention further provides a system for continuous software integration, comprising: at least two CI masters, a CI manager, at least two CI agents, and the at least two CI agents are general-purpose computing units;
  • the CI master is configured to receive a CI task delivered by a user, and decompose the CI task into at least two CI subtasks, and send the currently executable CI subtask to the CI manager;
  • the CI management machine is configured to receive and manage a CI subtask sent by the CI master; according to an online communication status of at least two CI agents in the currently managed CI proxy resource pool, and computing resources of the at least two CI agents.
  • An idle state determining a target CI agent that performs a current executable subtask in at least one CI subtask managed by itself, and sending the currently executable subtask to the destination CI proxy;
  • the CI agent when the CI agent is the destination CI agent determined by the CI manager, configured to receive and execute a current executable subtask sent by the CI manager.
  • the destination CI proxy that executes the executable subtask is determined according to an online communication state of at least two CI agents in the currently managed CI proxy resource pool and a computing resource idle state of the at least two CI agents. , to achieve load sharing between CI agents, improve the utilization of CI agents and the efficiency of continuous integration.
  • FIG. 1 is a schematic structural view of a CI system in the prior art
  • Embodiment 2 is a flowchart of a method for continuous integration of software provided in Embodiment 1 of the present invention
  • Embodiment 3 is a flow chart of a method for continuous integration of software provided in Embodiment 2 of the present invention.
  • FIG. 5 is a schematic flow chart showing the structure of a first type of CI management machine provided in Embodiment 4 of the present invention.
  • FIG. 6 is a schematic flow chart showing the structure of a second CI management machine provided in Embodiment 4 of the present invention
  • 7 is a schematic flow chart showing the structure of a third CI management machine provided in Embodiment 4 of the present invention
  • FIG. 8 is a schematic flow chart showing the structure of a software continuous integration system provided in Embodiment 5 of the present invention. detailed description
  • an embodiment of the present invention provides a method for software continuous integration, where the method includes the following steps: S101: Receive a CI subtask sent by a CI master;
  • S102 Determine, according to an online communication state of at least two CI agents in the currently managed CI proxy resource pool, and a computing resource idle state of the at least two CI agents, to execute a current executable in the currently managed at least one CI subtask.
  • the CI proxy of the task, and the current executable subtask is sent to the destination CI proxy, so that the target CI proxy executes the executable subtask, and the at least two CI proxies are general computing units.
  • the current executable subtask in the currently managed at least one CI subtask may be the CI subtask currently received, or may be a previously received CI subtask.
  • the destination CI proxy that executes the executable subtask is determined according to an online communication state of at least two CI agents in the currently managed CI proxy resource pool and a computing resource idle state of the at least two CI agents. , realize load sharing between CI agents, improve utilization of CI agents and efficiency of continuous integration; receive and manage CI subtasks sent by one or more CI masters through CI manager, and manage them by CI manager The current executable subtask in at least one CI subtask is sent to the CI agent for processing, thereby supporting concurrent task control between the CI masters.
  • an embodiment of the present invention provides a method for software continuous integration, where the method includes the following steps: S201: The CI management machine receives a registration request sent by a CI master and a CI agent.
  • the registration request to the CI manager is sent in the form of a heartbeat, and a communication connection is established with the CI manager, and the CI manager generates a CI composed of all CI agents registered to it.
  • Agent resource pool the CI agent in the resource pool is a general computing unit.
  • the request information of the registration request sent by the CI master includes the subtask dependency between the CI master and the specified CI proxy type. Different types of CI agents can support different operating systems and special CI tasks.
  • the CI management machine receives the registration request sent by the CI master and the CI agent, and sends the registration request according to at least two CI masters. Registering a request, obtaining a subtask dependency between at least two CI masters and a CI proxy type specified by at least two CI masters; acquiring the type of the CI proxy according to a registration request sent by at least two CI agents, at least Two CI agents are organized into different CI agent resource groups according to their types.
  • the CI management machine acquires a subtask dependency between at least two CI hosts and a CI proxy type specified by at least two CI hosts according to the registration request sent by the at least two CI masters, and generates a subtask dependency table. And an online CI proxy type table; the CI manager obtains the type of the CI proxy according to the registration request sent by the at least two CI agents, and organizes at least two CI agents into different CI proxy resource groups according to their types, and the CI proxy CI agents of the same type are divided into the same CI proxy resource group.
  • S203 The user sends a CI task to the CI master
  • the user can send the CI task to the CI master through a Web (Web) or a GUI (Graphical User Interface);
  • Web Web
  • GUI Graphic User Interface
  • the CI task of the software S1 can be sent to the CI master via the Web.
  • the CI master decomposes the received CI task into multiple CI subtasks, and caches the multiple CI subtasks to the main control task queue.
  • the CI master A receives the CI task a for the software S1 sent by the user, the CI task £1 is decomposed, and three CI subtasks a1, a2, and a3 are obtained, and the three CI subtasks are respectively : Get the latest code of software A, install the new code and automatically test the new code; then the CI master caches the above three CI subtasks to the master task queue L1.
  • the cache queue is used to store the CI subtasks obtained by the CI master.
  • the CI master extracts the currently executable CI subtask from the main task queue, and specifies a subtask weight of the currently executable CI subtask;
  • the CI master obtains the currently executable CI subtask from the CI subtask cached in the main task queue, and formulates the subtask weight according to the CPU and memory required to execute the CI subtask.
  • the subtask weight is used to represent the task quantity of the CI subtask.
  • An executable subtask refers to a CI subtask that can be executed without executing the execution result of other CI subtasks, and/or a CI subtask that has been generated by the execution result of other CI subtasks that it needs to rely on;
  • Other CI subtasks can be CI subtasks belonging to the same master, or CI subtasks belonging to different masters.
  • three CI subtasks a1, a2, and a3 are cached in the master task queue LI, respectively, to obtain the latest code of the software A, install the new code, and automatically test the new code, where the CI subtask al, That is, the latest code of the software A is obtained, which is the currently executable CI subtask; the CI subtask a2, that is, the installation of the new code, needs to rely on the execution result of the CI subtask a1; the CI subtask a3, that is, the new code is automatically The test needs to rely on the CI subtask bl in the master B to execute. Then, the currently executable CI subtask obtained by the CI master A from the master task queue L1 is al.
  • the CI master queries the execution result of the other CI subtasks, if the other subtasks have been executed. After that, the CI subtask is the currently executable CI subtask.
  • the CI master sends the query information to the CI manager, by querying the dependent CIs in the CI manager.
  • a task execution status table which acquires execution states of other CI subtasks in other CI hosts that the CI subtask depends on, and if the other CI subtasks have been executed, the CI subtasks are executable subtasks; If the subtask is not executed, the CI subtask is a CI subtask that is currently unexecutable. At this time, the CI subtask needs to wait for the execution of other CI subtasks to be executed. Preferably, if other CI subtasks are not executed.
  • the other CI subtasks can also be preferentially executed by the CI manager.
  • the CI master caches the currently executable CI subtask information to the main control delivery queue, and waits to be sent to the CI management machine.
  • the CI subtask information includes at least the executable subtask and its subtask weights. ;
  • CI Master A sends the currently executable CI subtask a and its subtask weights to the CI manager, while subtasks a2 and a3 continue to be cached in the master task queue L1 until it depends on the CI. After the subtask is executed, it can be executed as the currently executable CI subtask.
  • the CI management machine receives the CI subtask sent by the CI master.
  • the CI manager caches the CI subtask and queues the CI subtask to the CI proxy to execute the CI subtask.
  • the CI management machine extracts the currently executable CI subtask from the management machine task queue, which is simply referred to as the currently executable subtask;
  • the CI management machine determines the destination CI proxy resource group according to the CI proxy type specified by the CI master. Specifically, the CI manager queries the online CI proxy type table, and obtains a CI proxy that sends the executable subtask CI master. Types of. Query each CI proxy resource group to determine the same CI proxy resource group as the CI proxy type. The resource group is the destination CI proxy resource group.
  • the CI manager is in the online communication state when the CI agents in the currently managed CI proxy resource pool are in the root state. Obtaining a computing resource idle state of at least two CI agents according to the idle state query response returned by the at least two CI agents;
  • the CI agent since the CI manager sends a heartbeat polling query to the CI agent to obtain the online communication status, the CI agent sends the heartbeat response information to the CI manager after receiving the heartbeat query information, and the returned heartbeat response information includes the The current computing resource is idle.
  • S210 Generate idle computing resource weights of the at least two CI agents according to the computing resource idle state of the at least two CI agents, if the idle computing resource weight of the current CI agent is greater than or equal to the executable subtask The sub-task weight, then the current CI proxy is the destination CI proxy.
  • the CI management machine obtains the idle resource weight of the CI agent according to the idle state of the computing resource sent by the CI agent.
  • the CI manager determines whether the idle resource weight is greater than or equal to the subtask weight of the executable subtask, and if so, the CI proxy is an optional destination CI proxy, and the CI manager determines the destination CI proxy from the optional destination proxy.
  • the CI management machine may randomly select a CI proxy as the destination CI proxy in the optional CI proxy; or may select the CI proxy with the largest idle resource weight in the optional CI proxy for better completion of the executable subtask.
  • a purpose CI agent may randomly select a CI proxy as the destination CI proxy in the optional CI proxy; or may select the CI proxy with the largest idle resource weight in the optional CI proxy for better completion of the executable subtask.
  • the destination CI proxy refers to a CI proxy whose idle resource weight is greater than or equal to the CI subtask weight of the executable subtask.
  • the weight of the idle computing resource is used to indicate the current computing power of the CI proxy.
  • the idle resource weight can be determined according to the current storage capacity of the CI agent and its processing speed.
  • the CI manager caches the executable sub-tasks to the management machine to send the queues, and queues them to be delivered to the destination CI agent.
  • the executable subtask can be issued according to the priority of the executable subtask.
  • the destination CI agent caches the executable subtasks to the CI proxy task queue and queues for execution.
  • the destination CI agent sends the task execution result to the CI management machine; and backs up the task execution result, and generates a task execution log;
  • the destination CI agent caches the task execution result to the CI agent upload queue, and waits for the task to be uploaded to the CI management machine.
  • the task execution result is backed up by a separate storage device, and the user can directly access the storage device to query the task. Execute the result, or send a query command to the CI master, and the CI master queries the task execution result.
  • the CI management machine receives an execution result of the executable subtask sent by the destination CI agent.
  • S215 The CI management machine sends the received execution result to the CI master;
  • S216 The CI management machine determines, according to the subtask dependency relationship between the at least two CI hosts, whether the execution of the subtasks of other CI hosts depends on the execution result, and if yes, records the execution result;
  • the CI management machine sends the received execution result to the CI master, querying the CI master registry to determine whether there are other master subtasks currently executing depends on the execution result, and if so, relying on the CI
  • the execution result of the executable subtask is recorded in the subtask execution status table, so that the CI master determines the main executable executable subtask by querying the dependent CI subtask execution status table.
  • the sub-task dependency of the CI main space is recorded in the CI main control registry.
  • the table T1 records the CI subtask dependencies between CI masters that issue CI tasks through the CI manager, as shown in Table T1:
  • the CI manager When the CI manager receives the execution result of the CI subtask a of the CI master A, and queries the CI master registry T1, it can be known that the subtask c3 in the CI master C depends on the execution result of the al, and the CI manager is dependent on the CI.
  • the sub-task execution status table records the execution result of the executable sub-task.
  • the CI master C queries the dependent CI sub-task execution status table to obtain that al has been executed, the CI master C determines that c3 is ok. Perform subtasks.
  • the master with the sub-task dependencies can obtain the execution result in time, thereby effectively improving the task execution efficiency of the master and reducing the time required for continuous integration.
  • the other CI masters when there are subtasks in the other CI masters that depend on the execution result, the other CI masters obtain the execution result by sending a request for obtaining the execution result, and when the execution result of the executable subtask is completed, The subtask that depends on the execution result is the executable subtask.
  • S218 The CI manager responds to the request sent by the other CI masters to obtain the execution result, so that the other CI master determines and sends the currently executable CI subtask according to the execution result.
  • S219 Send a heartbeat handshake message to the CI master and the CI agent to detect a communication status of the CI master and the CI agent.
  • the target CI agent is not completed.
  • the task is resent to the destination CI agent that is to execute the executable subtask.
  • the executable task There are various reasons for the executable task to fail. For example, the CI agent fails to execute the executable task, or the online communication status between the CI task and the CI agent is abnormal, resulting in information loss.
  • the CI management machine resends the executable subtask to the same destination CI proxy, or determines a new destination CI proxy according to step S206, and sends the executable subtask to the new destination CI proxy, according to the specific manner.
  • This implementation is not limited to the cause of the failure of the executable task.
  • the retransmission of executable tasks through the CI manager ensures the execution of CI subtasks.
  • the CI manager can preset a time threshold
  • the execution result is not received within the preset time threshold, that is, the current executable task fails to be determined, wherein the preset time value is greater than or equal to The current execution task execution time and the communication time between the CI manager and the CI agent.
  • the destination CI proxy that executes the executable subtask is determined according to an online communication state of at least two CI agents in the currently managed CI proxy resource pool and a computing resource idle state of the at least two CI agents. , realize load sharing between CI agents, improve utilization of CI agents and efficiency of continuous integration; receive and manage CI subtasks sent by one or more CI masters through CI manager, and manage them by CI manager The current executable subtask in at least one CI subtask is sent to the CI agent for processing, thereby supporting concurrent task control between the CI masters.
  • the embodiment of the present invention further provides a method for continuously integrating software, and the method includes the following steps: Steps S301 to S304 are the same as S201 to S204 in Embodiment 3, as shown in Embodiment 3, Let me repeat.
  • S305 The CI master sends an acquisition request for the idle computing resource weight to the CI manager.
  • the CI management machine sends the idle computing resource weight to the CI master in response to the acquiring request.
  • the CI agent in the currently managed CI proxy resource pool is in an online communication state.
  • the idle computing resource weight is
  • the CI master determines the destination CI proxy according to the idle computing resource weight
  • the CI master determines whether the idle resource weight is greater than or equal to the subtask weight of the executable subtask, and if yes, the CI proxy is an optional destination CI proxy, and the CI master determines from the optional destination proxy.
  • Purpose CI agent Preferably, the CI master can randomly select a CI proxy as the destination CI proxy in the optional CI proxy; or, in order to better complete the executable subtask, select the CI proxy with the largest idle resource weight in the optional CI proxy.
  • S308 The CI master sends the currently executable CI subtask to the target CI agent determined according to the idle computing resource weight.
  • the CI master sends an idle computing resource weight acquisition request to the CI manager.
  • the CI manager sends the idle computing resource weight to the CI master according to the acquisition request, and is directly controlled by the CI master.
  • Delivering the executable task to the destination CI agent reduces the load on the CI manager and further improves the execution efficiency of the executable task.
  • an embodiment of the present invention further provides a CI management machine, including:
  • An executable subtask receiving module 401 configured to receive and manage a CI subtask sent by the CI master;
  • the destination CI proxy determining module 402 is configured to determine to perform the currently managed at least one CI sub-port according to the online communication status of the at least two CI agents in the currently managed CI proxy resource pool and the computing resource idle state of the at least two CI agents. a destination CI agent of the current executable subtask in the task, and sending the current executable subtask to the destination CI agent, causing the destination CI agent to execute the executable subtask, the at least two CIs
  • the agent is a general purpose computing unit.
  • the destination CI proxy determining module 402 may include:
  • the computing resource idle state obtaining unit 4021 is configured to acquire at least two CI agents according to the idle state query response returned by the at least two CI agents when the CI agents in the currently managed CI proxy resource pool are all in the online communication state. Calculate the idle state of the resource;
  • the first-purpose CI proxy determining unit 4022 is configured to generate idle computing resource weights of the at least two CI agents according to the computing resource idle state of the at least two CI agents, if the idle computing resource weight of the current CI proxy is greater than or equal to The subtask weight of the executable subtask, then the current CI proxy is the destination CI proxy.
  • the CI management machine of the embodiment of the present invention may further include:
  • the idle computing resource weight obtaining request receiving module 403 is configured to receive an acquisition request of the idle computing resource weight sent by the CI master;
  • the idle computing resource weight obtaining request response module 404 is configured to send the corresponding idle computing resource weight to the CI master in response to the acquiring request, so that the CI master sends the currently executable CI subtask to the The idle computing resource weight is determined by the destination CI agent to execute.
  • the CI management machine of the embodiment of the present invention may further include:
  • the registration request receiving module 405 is configured to receive a registration request sent by the CI master and the CI agent;
  • the CI proxy type obtaining module 406 is configured to obtain, according to the registration request sent by the at least two CI masters, the subtask dependencies between the at least two CI masters and the CI proxy type specified by the at least two CI masters;
  • the CI proxy resource group management module 407 is configured to obtain the type of the CI proxy according to the registration request sent by the at least two CI agents, and organize at least two CI agents into different CI proxy resource groups according to their types.
  • the CI management machine of the embodiment of the present invention may further include:
  • the execution result receiving module 408 is configured to receive an execution result of the executable subtask sent by the destination CI agent, and the execution result recording module 409 is configured to determine, according to the subtask dependency relationship between the at least two CI hosts, whether The execution of the subtasks of other CI masters depends on the execution result, and if so, the execution result is recorded;
  • the execution result obtaining request response module 410 is configured to respond to the request sent by the other CI master to obtain the execution result, so that the other CI master determines and sends the currently executable CI subtask according to the execution result.
  • the CI management machine of the embodiment of the present invention may further include:
  • the communication status detecting module 411 is configured to send a heartbeat handshake message to the CI master and the CI agent to detect the communication status of the CI master and the CI agent.
  • the executable subtask retransmission module 412 is configured to resend the unexecuted executable subtask of the destination CI proxy to the destination CI proxy to execute the executable subtask when detecting that the CI proxy communication status is abnormal.
  • the destination CI proxy determining module 402 may include:
  • the target CI proxy resource group determining unit 4023 is configured to determine a target CI proxy resource group according to the CI proxy type specified by the CI master;
  • the second-purpose CI proxy determining unit 4024 is configured to determine, according to the online communication status of the CI proxy in the target CI proxy resource group, and the idle resource state of the CI proxy in the target CI proxy resource group, The CI agent that performs the subtask's purpose.
  • the CI agent in the destination CI proxy resource group is in the online communication state, obtaining the idle resource status of the CI agent according to the idle state query response returned by the CI agent, according to the idle resource status of the CI agent.
  • the idle computing resource weight of the CI proxy is generated. If the idle computing resource weight of the current CI proxy is greater than or equal to the subtask weight of the executable subtask, the current CI proxy is the destination CI proxy.
  • the computing resources of the CI agent are determined by the parameters of the various aspects of the running of the CI agent. In this embodiment, the more important items are selected, including: CPU resources and memory resources, and the idle state of the computing resources of the CI agent can be used by the CI.
  • the agent is currently characterized by the available CPU resources and their available memory resources.
  • the CI manager sets different constant coefficients for each parameter to indicate the importance of each parameter, then the CI agent is empty.
  • the idle computing resource weight can be described by the formula as:
  • CI proxy weight Rl * f: ree - cpu + R2 * free memory
  • free-cpu indicates the CUP resource currently available to the CI agent
  • R1 is the CUP resource constant coefficient
  • free-memory indicates the currently available memory resource of the CI agent
  • R2 is the memory resource constant coefficient
  • the purpose is determined according to the subtask weight of the executable subtask and the CI proxy idle resource weight.
  • the CI agent implements load sharing between CI agents, improves the utilization of CI agents, and improves the efficiency of continuous integration. It also accepts all CI subtasks through CI management machine and sends CI subtasks to CI agents, thus implementing CI. Concurrency control of the CI agent between the master and the controller; and because the CI agent is a general-purpose computing unit, it is beneficial to realize the increase or decrease of the task, and does not need to modify the CI master and the CI agent, thereby enhancing the system scalability.
  • Example 5 Sending, by the CI master, an acquisition request for the idle computing resource weight to the CI manager; the CI management machine sends the idle computing resource weight to the CI master, and the CI master directly delivers the request Performing the task to the destination CI agent reduces the load on the CI manager and further improves the execution efficiency of the executable task.
  • Example 5 Sending, by the CI master, an acquisition request for the idle computing resource weight to the CI manager; the CI management machine sends the idle computing resource weight to the CI master, and the CI master directly delivers the request Performing the task to the destination CI agent reduces the load on the CI manager and further improves the execution efficiency of the executable task.
  • the embodiment of the present invention further provides a system for continuous software integration, the system comprising: at least two CI masters 501, a CI manager 502, at least two CI agents 503, and at least two
  • the CI agent is a general purpose computing unit;
  • the CI master 501 is configured to receive a CI task delivered by the user, and decompose the CI task into at least two CI subtasks, and send the currently executable CI subtask to the CI manager.
  • the CI management machine 502 is configured to receive and manage a CI subtask sent by the CI master 501; according to an online communication status of at least two CI agents 503 in the currently managed CI proxy resource pool, the at least two CI agents Calculating a resource idle state of 503, determining a target CI agent that performs a current executable subtask in at least one CI subtask managed by itself, and transmitting the current executable subtask to the destination CI proxy;
  • the CI manager 502 obtains at least two CI agents 503 according to the idle state query response returned by the at least two CI agents 503. Calculating the idle resource state of the at least two CI agents 503 according to the calculated resource idle state of the at least two CI agents 503, if the current CI agent 503 is idle computing resource rights If the value is greater than or equal to the subtask weight of the executable subtask, the current CI proxy 503 is the destination CI proxy.
  • the CI master 501 is further configured to send a registration request to the CI manager 502.
  • the CI agent 503 is further configured to send a registration request to the CI manager 502.
  • the CI management machine 502 is further configured to receive the registration request sent by the CI master 501, and obtain the subtask dependencies between the at least two CI masters 501 according to the registration request sent by the at least two CI masters 501.
  • the two CI agents 503 are organized into different CI proxy resource groups according to their types.
  • the CI master 501 is further configured to obtain an acquisition request of the idle computing resource weight sent to the CI manager 502.
  • the CI management machine 502 is further configured to: send, according to the obtaining request, the idle computing resource weight to the CI master 501, so that the CI master 501 sends the currently executable CI subtask to the The idle CI resource weight determined by the destination CI agent is executed.
  • the CI agent 503 When the CI agent 503 is the destination CI agent determined by the CI manager 502, it is also used to send the execution result of the executable task to the CI master 501;
  • the CI management machine 502 is further configured to: receive an execution result of the executable subtask sent by the destination CI proxy; determine, according to the subtask dependency relationship between the at least two CI masters 501, whether there are other CI masters The execution of the subtask of 501 depends on the execution result, and if so, the execution result is recorded;
  • the CI master 501 is further configured to send an execution result acquisition request to the CI manager 502.
  • the CI manager 502 is further configured to respond to the request sent by the other CI master 501 to obtain the execution result, so that the other CI master 501 determines and sends the currently executable CI subtask according to the execution result.
  • the CI management machine 502 is further configured to determine a destination CI proxy resource group according to the CI proxy type specified by the CI master 501;
  • the destination CI proxy that executes the executable subtask is determined according to the online communication status of the CI proxy 503 in the target CI proxy resource group and the computing resource idle state of the CI proxy 503.
  • the CI management machine 502 is configured to send a heartbeat handshake message to the CI master 501 and the CI agent 503 to detect the online communication status of the CI master 501 and the CI agent; when detecting that the destination CI agent communication status is abnormal, the The unexecuted executable subtask of the destination CI agent is resent to the destination CI agent to execute the executable subtask.
  • the CI master, the CI manager, and the CI agent are respectively deployed on different computing nodes, or are combined and deployed in the same computing node.
  • the system of the software continuous integration of the embodiment of the present invention can be configured to be deployed in different environments in different roles, or can be uniformly deployed in the same environment.
  • the destination CI proxy is determined according to the subtask weight of the executable subtask and the CI proxy idle resource weight.
  • the embodiment determines that the executable is executed according to the executable subtask and the CI proxy resource.
  • Task The purpose of the CI agent, the load sharing between the CI agents, improve the utilization of the CI agent, improve the efficiency of continuous integration; accept all CI subtasks simultaneously through the CI manager, and send the CI subtask to the CI agent, and then achieve Concurrency control of CI agents between CI masters.
  • both the CI master controller and the CI agent can be dynamically added and deleted without affecting the availability of the entire system.
  • the device and the system provided in this embodiment may be the same as the method embodiment, and the specific implementation process is described in the method embodiment, and details are not described herein again.
  • a person skilled in the art can understand that all or part of the steps of implementing the above method embodiments may be completed by using hardware related to program instructions, and the foregoing program may be stored in a computer readable storage medium, and the program is executed when executed.
  • the steps of the foregoing method embodiments are included; and the foregoing storage medium includes: a medium that can store program codes, such as a ROM, a RAM, a magnetic disk, or an optical disk.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Hardware Redundancy (AREA)

Abstract

公开了一种软件持续集成的方法。该方法包括:接收并管理CI主控发送的CI子任务;根据当前管理的CI代理资源池中至少两个CI代理的在线通信状态,所述至少两个CI代理的计算资源闲置状态,确定执行当前管理的至少一个CI子任务中的当前可执行子任务的目的CI代理,并将所述当前可执行子任务发送至所述目的CI代理,使所述目的CI代理执行所述可执行子任务,其中,所述至少两个CI代理为通用计算单元。还公开了一种软件集成的装置。该装置包括:可执行子任务接收模块和目的CI代理确定模块。本发明为通用计算单元的目的CI代理发送可执行子任务,增加了执行CI子任务的CI代理的可选性。该系统各装置之间的通信采用动态注册机制,实现了CI主控机和CI代理的动态热插拔和水平扩展,从而有效的提高了系统的扩展性。

Description

软件持续集成的方法、 装置和系统 技术领域
本发明涉及持续集成技术领域, 特别涉及一种软件持续集成的方法、 装置和系统 背景技术 说
CI (Continuous Integration, 持续集成) 是一种自动化的软件创建与测试过程, 在 软件开发项目中, CI系统将每个 CI任务分解成多个 CI子任务, 如将对某软件的 CI任务分 解成获取最新代码、 编译代码、 打包、 发布、 安装、 自动测试、 质量检测和数据度量等 CI
子任务, 通过不断的执行 CI子任务, 可尽早地发现软件缺陷, 并对其进行修复。 由此可见, 不同的 CI系统的优劣可对于软件的开发效率和投入成本造成不同的影响。
现有的 CI系统如图 1所示, 主要由 CI主控和 CI 代理组成, 其对软件进行 CI的主要 步骤为: 首先, 用户向某一 CI主控下发 CI任务; 然后, 该 CI主控将该 CI任务分解成多 个 CI子任务, 并将该 CI子任务下发至相应的 CI 代理执行, 其中每个 CI 代理负责执行的 CI任务类型是固定的; 最后, 由该相应的 CI代理执行该 CI子任务, 并将执行结果返回 CI 主控。
在实现本发明的过程中, 发明人发现现有技术至少存在以下问题:
现有的持续集成系统中, 由于 CI 代理负责执行的 CI任务类型是固定的, CI主控只 能下发固定的 CI任务至相应的 CI 代理, 没有选择的可能性, 从而 CI 代理资源的共享程 度低, 资源利用率低下。 发明内容
本发明实施例提供了一种软件持续集成的方法, 以实现 CI 代理间的负载分担, 提高
CI 代理的利用率。
一方面, 本发明实施例提供一种软件持续集成的方法, 包括:
接收并管理 CI主控发送的 CI子任务;
根据当前管理的 CI代理资源池中至少两个 CI代理的在线通信状态、 所述至少两个 CI 代理的计算资源闲置状态, 确定执行当前管理的至少一个 CI子任务中的当前可执行子任务 的目的 CI 代理, 并将所述当前可执行子任务发送至所述目的 CI 代理, 使所述目的 CI 代 理执行所述可执行子任务, 所述至少两个 CI 代理为通用计算单元。
本发明实施例还提供了一种软件持续集成的装置, 所述装置包括:
可执行子任务接收模块, 用于接收并管理 CI主控发送的 CI子任务;
目的 CI代理确定模块, 用于根据当前管理的 CI代理资源池中至少两个 CI代理的在线 通信状态、 所述至少两个 CI 代理的计算资源闲置状态, 确定执行当前管理的至少一个 CI 子任务中的当前可执行子任务的目的 CI代理, 并将所述当前可执行子任务发送至所述目的 CI 代理, 使所述目的 CI 代理执行所述可执行子任务, 所述至少两个 CI 代理为通用计算 单元。
本发明实施例还提供了一种软件持续集成的系统,包括:至少两个 CI主控、 CI管理机、 至少两个 CI 代理, 所述至少两个 CI 代理为通用计算单元;
所述 CI主控用于接收用户下发的 CI任务, 将所述 CI任务分解成至少两项 CI子任务, 向所述 CI管理机发送当前可执行的 CI子任务;
所述 CI管理机用于接收并管理所述 CI主控发送的 CI子任务; 根据当前管理的 CI代 理资源池中至少两个 CI代理的在线通信状态、 所述至少两个 CI代理的计算资源闲置状态, 确定执行自身管理的至少一个 CI子任务中的当前可执行子任务的目的 CI 代理, 并将所述 当前可执行子任务发送至所述目的 CI 代理;
所述 CI 代理为所述 CI管理机确定的目的 CI代理时, 用于接收并执行所述 CI管理机 发送的当前可执行子任务。
可见, 本实施例通过根据当前管理的 CI代理资源池中至少两个 CI代理的在线通信状 态、 所述至少两个 CI代理的计算资源闲置状态, 确定执行所述可执行子任务的目的 CI 代 理, 实现 CI 代理间的负载分担, 提高 CI 代理的利用率以及持续集成的效率。
附图说明
图 1是现有技术中 CI系统的结构示意图;
图 2是本发明实施例 1中提供的软件持续集成的方法流程图;
图 3是本发明实施例 2中提供的软件持续集成的方法流程图;
图 4是本发明实施例 3中提供的软件持续集成的方法流程图;
图 5是本发明实施例 4中提供的第一种 CI管理机的结构示意流程图;
图 6是本发明实施例 4中提供的第二种 CI管理机的结构示意流程图; 图 7是本发明实施例 4中提供的第三种 CI管理机的结构示意流程图;
图 8是本发明实施例 5中提供的软件持续集成系统的结构示意流程图。 具体实施方式
为使本发明的目的、 技术方案和优点更加清楚, 下面将结合附图对本发明实施方式作 进一步地详细描述。
实施例 1
如图 2所示, 本发明实施例提供了一种软件持续集成的方法, 该方法包括以下步骤: S101 : 接收 CI主控发送的 CI子任务;
S102: 根据当前管理的 CI代理资源池中至少两个 CI代理的在线通信状态、 所述至少 两个 CI代理的计算资源闲置状态, 确定执行当前管理的至少一个 CI子任务中的当前可执 行子任务的目的 CI 代理, 并将所述当前可执行子任务发送至所述目的 CI 代理, 使所述目 的 CI 代理执行所述可执行子任务, 所述至少两个 CI 代理为通用计算单元。
本实施例中, 当前管理的至少一个 CI子任务中的当前可执行子任务, 可以是当前接收 的所述 CI子任务, 也可以是之前接收的 CI子任务。
可见, 本实施例通过根据当前管理的 CI代理资源池中至少两个 CI代理的在线通信状 态、 所述至少两个 CI代理的计算资源闲置状态, 确定执行所述可执行子任务的目的 CI 代 理, 实现 CI 代理间的负载分担, 提高 CI 代理的利用率以及持续集成的效率; 通过 CI管 理机接收并管理一个或多个 CI主控发送的 CI子任务, 并由 CI管理机将自身当前管理的至 少一个 CI子任务中的当前可执行子任务发送给 CI代理处理, 进而支持 CI主控间的并发任 务控制。 实施例 2
如图 3所示, 本发明实施例提供了一种软件持续集成的方法, 该方法包括以下步骤: S201 : CI管理机接收 CI主控和 CI代理发送的注册请求;
具体的, CI主控和 CI代理启动时, 以心跳的形式发送向 CI管理机注册请求, 与 CI 管理机建立通讯连接, CI 管理机中将产生一个由所有向其注册的 CI 代理组成的 CI 代理 资源池, 资源池中的 CI代理为通用的计算单元。
其中, CI主控发送的注册请求的请求信息中包括 CI主控间的子任务依赖关系和其指定 的 CI代理类型, 不同类型的 CI代理可以支持不同操作系统和特殊 CI任务。
S202: CI管理机接收 CI主控和 CI代理发送的注册请求, 根据至少两个 CI主控发送的 注册请求, 获取至少两个 CI主控间的子任务依赖关系和至少两个 CI主控指定的 CI代理类 型; 根据至少两个 CI代理发送的注册请求, 获取所述 CI代理的类型, 将至少两个 CI代理 按其类型组织成不同的 CI代理资源组。
具体的, CI管理机根据至少两个 CI主控发送的注册请求, 获取至少两个 CI主控间的 子任务依赖关系和至少两个 CI主控指定的 CI代理类型, 生成子任务依赖关系表和在线 CI 代理类型表; CI管理机根据至少两个 CI代理发送的注册请求, 获取所述 CI代理的类型, 将至少两个 CI代理按其类型组织成不同的 CI代理资源组, 将 CI代理类型相同的 CI代理 划分在同一个 CI代理资源组中。
S203 :用户发送 CI任务到 CI主控;
具体的, 用户可以通过 Web (网络) 或 GUI (Graphical User Interface, 图形用户接 口) 发送 CI任务到 CI主控;
例如, 用户需要更新其正在开发的 S1软件, 即把对 S1新开发产生的内容与当前的 S1 软件的内容集成起来, 则其可通过 Web将向 CI 主控发送对软件 S1的 CI任务。
S204 : CI主控将接收到的 CI任务分解为多个 CI子任务, 并将该多个 CI子任务缓存至 主控任务队列;
例如, 当 CI主控 A接收到用户发送的针对软件 S1的 CI任务 a后, 对该 CI任务 £1进 行分解, 得到三个 CI子任务 al、 a2和 a3, 该三个 CI子任务分别为: 获取软件 A的最新代 码、 安装该新代码和对该新代码进行自动测试; 然后 CI主控将上述三个 CI子任务缓存至 主控任务队列 Ll。
其中, 缓存队列用于存储由 CI主控分解得到的 CI子任务。
S205 : CI 主控将当前可执行的 CI 子任务从主控任务队列取出, 并指定当前可执行的 CI子任务的子任务权值;
具体的, CI主控从主控任务队列中缓存的 CI子任务中获取当前可执行的 CI子任务, 并根据执行该 CI子任务所需的 CPU和内存来制定子任务权值。
其中, 子任务权值, 用于表示 CI子任务的任务量, 子任务权值越大, 表示该 CI子任 务的任务量越大, 则用于执行该 CI子任务所需的计算资源越多; 子任务权值越小, 表示该 CI子任务的任务量越小, 则用于执行该 CI子任务所需的计算资源越少; 其中, 计算资源包 括执行 CI子任务所需的内存和执行设备的 CPU资源。 可执行子任务, 是指其执行不依赖于 其他 CI子任务的执行结果即可执行的 CI子任务, 和 /或当前其需要依赖的其他 CI子任务 的执行结果已产生的 CI子任务; 其中, 其他 CI子任务即可以是属于同一个主控的 CI子任 务, 也可以是属于不同主控的 CI子任务。 例如, 主控任务队列 LI中缓存了三个 CI子任务 al、 a2和 a3, 分别为获取软件 A的最 新代码、 安装该新代码和对该新代码进行自动测试, 其中, CI子任务 al, 即获取软件 A的 最新代码, 是当前可执行的 CI子任务; CI子任务 a2, 即安装该新代码, 需要依赖 CI子任 务 al的执行结果; CI子任务 a3, 即对该新代码进行自动测试, 需要依赖主控 B中的 CI子 任务 bl才能执行。则 CI主控 A从主控任务队列 L1中获取的当前可执行的 CI子任务为 al。 当主控任务队列中的 CI子任务的执行依赖于其所在 CI主控中的其他 CI子任务的执行结果 时, CI主控查询该其他 CI子任务的执行结果, 如果该其他子任务已执行完, 则该 CI子任 务为当前可执行的 CI子任务。
当主控任务队列中的 CI子任务的执行依赖于其他 CI主控中的其他 CI子任务的执行结 果时, CI主控向 CI管理机发送查询信息, 通过查询 CI管理机中的依赖 CI子任务执行状态 表, 获取该 CI子任务依赖的其他 CI主控中的其他 CI子任务的执行状态, 如果该其他 CI 子任务已执行完, 则该 CI子任务为可执行子任务; 如果该其他子任务未执行, 则该 CI子 任务为当前不可执行的 CI子任务, 此时, CI子任务需等待其他 CI子任务顺序执行完毕后, 方可执行; 优选的, 如果其他 CI子任务未执行, 也可由 CI管理机优先执行该其他 CI子任 务。
S206: CI主控将当前可执行的 CI子任务发送至 CI管理机;
具体的, CI主控将当前可执行的 CI子任务信息缓存至主控下发队列, 排队等待下发至 CI管理机, 该 CI子任务信息中至少包括可执行子任务及其子任务权值;
例如, CI主控 A将当前可执行的 CI子任务 al及其子任务权值发送至 CI管理机, 而子 任务 a2和 a3则继续缓存在该主控任务队列 L1中, 直至其依赖的 CI子任务执行完毕, 使 其成为当前可执行的 CI子任务后方可执行。
S207: CI管理机接收 CI主控发送的 CI子任务;
具体的, CI 管理机接收 CI 子任务后, 将其缓存至管理机任务队列, 并排队等待将该 CI子任务下发至 CI 代理, 使其执行该 CI子任务。
其中, CI管理机从管理机任务队列中取出自身当前可执行的 CI子任务, 简称为当前可 执行子任务;
S208: CI管理机根据所述 CI主控指定的 CI代理类型, 确定目的 CI代理资源组; 具体的, CI管理机查询在线 CI代理类型表, 获取发送该可执行子任务 CI主控的 CI代 理类型。 查询各 CI代理资源组, 确定与该 CI代理类型相同的 CI代理资源组, 该资源组为 目的 CI代理资源组。
S209: CI管理机在当前管理的 CI代理资源池中的 CI代理均处于在线通信状态时, 根 据所述至少两个 CI代理返回的空闲状态查询响应, 获取至少两个 CI代理的计算资源闲置 状态;
具体的, 由于 CI管理机定时向 CI代理发送心跳轮询查询, 获取的在线通信状态, CI 代理收到心跳查询信息后向 CI管理机发送心跳响应信息, 其返回的心跳响应信息中, 包含 其当前的计算资源闲置状态。
S210: 根据所述至少两个 CI代理的计算资源闲置状态生成所述至少两个 CI代理的空 闲计算资源权值, 如果当前 CI代理的空闲计算资源权值大于或等于所述可执行子任务的子 任务权值, 则所述当前 CI代理为目的 CI代理。
具体的, CI管理机根据 CI代理发送的计算资源闲置状态, 得到 CI代理的空闲资源权 值。 CI 管理机判断该空闲资源权值是否大于或等于可执行子任务的子任务权值, 如果是, 则该 CI代理为可选目的 CI代理, CI管理机从可选目的代理中确定目的 CI 代理。 优选的, CI管理机可通过在可选 CI代理中随机选择一个 CI代理作为目的 CI代理;也可以为了更好 的完成可执行子任务, 选择可选 CI代理中空闲资源权值最大的 CI代理作为目的 CI代理。
其中, 目的 CI 代理是指其空闲资源权值大于或等于可执行子任务的 CI子任务权值的 CI 代理。 空闲计算资源的权值, 用于表示 CI 代理当前的计算能力, 空闲资源权值越大, CI代理当前的计算能力越强, 则 CI代理可执行子任务的任务量越大; 空闲资源权值越小, CI 代理当前的计算能力越弱, 则 CI 代理可执行子任务的任务量越小, 优选的, 可根据 CI 代理当前的存储容量和其处理速度来制定其空闲资源权值。
S211 : CI管理机将当前可执行子任务发送给目的 CI 代理;
具体的, CI管理机将可执行子任务缓存至管理机下发队列, 排队等待下发至目的 CI代 理。
优选的, 可根据可执行子任务的优先级下发可执行子任务。
S212 : 目的 CI 代理接收可执行子任务;
具体的, 目的 CI 代理将可执行子任务缓存至 CI 代理任务队列, 排队等待执行。
S213 : 目的 CI 代理将任务执行结果发送至 CI管理机; 并备份该任务执行结果, 生成 任务执行日志;
具体的, 目的 CI 代理将任务执行结果缓存至 CI 代理上传队列, 排队等待上传至 CI 管理机; 优选的, 可采用单独的存储设备对任务执行结果进行备份, 用户可直接访问该存 储设备查询任务执行结果, 或通过发下查询命令至 CI主控, 由 CI主控查询任务执行结果。
S214: CI管理机接收所述目的 CI代理发送的所述可执行子任务的执行结果;
S215: CI管理机将接收到的执行结果发送给 CI主控; S216: CI管理机根据所述至少两个 CI主控间的子任务依赖关系, 判断是否有其他 CI 主控的子任务的执行依赖所述执行结果, 如果有, 则记录所述执行结果;
具体的, CI管理机将接收到的执行结果发送给 CI主控后, 查询 CI主控注册表, 判断 当前是否有其他主控子任务的执行需要依赖所述执行结果, 如果有, 则依赖 CI子任务执行 状态表中记录该可执行子任务的执行结果, 以便 CI主控通过查询该依赖 CI子任务执行状 态表, 从而确定该主控可执行子任务。
其中, CI主控注册表中记载了 CI主空间的子任务依赖。
例如, CI管理机中存在一 CI主控注册表 Tl, 该表 T1中记载了通过 CI管理机下发 CI 任务的 CI主控间的 CI子任务依赖关系, 如表 T1所示: 表 T1 :
Figure imgf000009_0001
当 CI管理机接收到 CI主控 A的 CI子任务 al的执行结果, 查询 CI主控注册表 Tl, 可 知 CI主控 C中的子任务 c3依赖 al的执行结果, 则 CI管理机在依赖 CI子任务执行状态表 中记录该可执行子任务的执行结果, 当 CI主控 C在查询该依赖 CI子任务执行状态表时, 可获取到 al已执行完, 则 CI主控 C确定 c3为可执行子任务。
通过由 CI管理机确定主控间子任务的依赖, 使具有子任务依赖关系的主控及时的获取 执行结果, 从而有效地提高了主控的任务执行效率, 减少了持续集成所需的时间。
S217: 其他 CI主控发送获取所述执行结果的请求;
具体的, 当其他 CI主控中存在依赖该执行结果的子任务时, 其他 CI主控通过发送获 取执行结果的请求, 获取该执行结果, 当该可执行子任务的执行结果执行完毕时 , 则该依 赖于该执行结果的子任务即为可执行子任务。
S218: CI 管理机响应所述其他 CI 主控发送的获取所述执行结果的请求, 使所述其他 CI主控根据所述执行结果确定并发送当前可执行的 CI子任务。
S219: 向 CI主控和 CI代理发送心跳握手消息, 以检测 CI主控和 CI代理的通信状态; 当检测到所述目的 CI代理通信状态异常, 将所述目的 CI代理未完成的可执行子任务重新 发送给待执行所述可执行子任务的目的 CI代理。 其中, 使可执行任务失败存在多种原因, 例如 CI 代理执行该可执行任务失败, 或 CI 任务与 CI 代理间的在线通信状态异常导致信息丢失。
具体的, CI管理机重新发送可执行子任务至同一目的 CI 代理, 或根据 S206步骤确定 一个新的目的 CI 代理, 并将所述可执行子任务发送至新的目的 CI 代理, 具体方式可根据 可执行任务失败原因而定, 本实施并不限定。 通过 CI管理机对可执行任务的重新发送, 确 保了 CI 子任务的执行。
优选的, 当 CI管理机可预设一时间阀值, 当可执行任务后在预设时间阀值内未收到执 行结果, 即判定当前可执行任务执行失败, 其中预设时间值大于或等于当前可执行任务执 行时间和 CI管理机与 CI 代理间的通信时间之和。
可见, 本实施例通过根据当前管理的 CI代理资源池中至少两个 CI代理的在线通信状 态、 所述至少两个 CI代理的计算资源闲置状态, 确定执行所述可执行子任务的目的 CI 代 理, 实现 CI 代理间的负载分担, 提高 CI 代理的利用率以及持续集成的效率; 通过 CI管 理机接收并管理一个或多个 CI主控发送的 CI子任务, 并由 CI管理机将自身当前管理的至 少一个 CI子任务中的当前可执行子任务发送给 CI代理处理, 进而支持 CI主控间的并发任 务控制。 实施例 3
如图 4所示, 本发明实施例还提供了一种软件持续集成的方法, 该方法包括以下步骤: 步骤 S301~S304与实施例 3中 S201~S204相同, 详见实施例 3, 此处不再赘述。
S305 : CI主控向 CI管理机发送空闲计算资源权值的获取请求;
S306 : CI管理机响应所述获取请求, 将所述空闲计算资源权值发送给所述 CI主控; 具体的, CI管理机在当前管理的 CI代理资源池中的 CI代理均处于在线通信状态时, 根据所述至少两个 CI代理返回的空闲状态查询响应, 获取至少两个 CI代理的计算资源闲 置状态; 根据所述至少两个 CI代理的计算资源闲置状态生成所述至少两个 CI代理的空闲 计算资源权值。
S307 : CI主控根据所述空闲计算资源权值确定目的 CI代理;
具体的, CI 主控判断该空闲资源权值是否大于或等于可执行子任务的子任务权值, 如 果是, 则该 CI代理为可选目的 CI代理, CI主控从可选目的代理中确定目的 CI 代理。 优 选的, CI主控可通过在可选 CI代理中随机选择一个 CI代理作为目的 CI代理; 也可以为了 更好的完成可执行子任务, 选择可选 CI代理中空闲资源权值最大的 CI代理作为目的 CI代 理。 S308: CI主控将其当前可执行的 CI子任务发送给根据所述空闲计算资源权值确定的目 的 CI代理执行;
S309: 目的 CI代理接收该可执行子任务执行, 并将执行结果返回 CI主控。
本实施例通过 CI主控向 CI管理机发送空闲计算资源权值的获取请求; CI管理机响应 该获取请求, 将所述空闲计算资源权值发送给所述 CI主控, 由 CI主控直接下发可执行任 务至目的 CI代理, 减少了 CI管理机的负荷, 进一步提高了可执行任务的执行效率。 实施例 4
如图 5所示, 本发明实施例还提供了一种 CI管理机, 包括:
可执行子任务接收模块 401, 用于接收并管理 CI主控发送的 CI子任务;
目的 CI 代理确定模块 402, 用于根据当前管理的 CI代理资源池中至少两个 CI代理的 在线通信状态、 所述至少两个 CI代理的计算资源闲置状态, 确定执行当前管理的至少一个 CI 子任务中的当前可执行子任务的目的 CI 代理, 并将所述当前可执行子任务发送至所述 目的 CI 代理, 使所述目的 CI 代理执行所述可执行子任务, 所述至少两个 CI 代理为通用 计算单元。
如图 6所示, 在一种实现方式下, 本发明实施例提供的 CI管理机中, 目的 CI 代理确 定模块 402可以包括:
计算资源闲置状态获取单元 4021, 用于在当前管理的 CI代理资源池中的 CI代理均处 于在线通信状态时, 根据该至少两个 CI 代理返回的空闲状态查询响应, 获取至少两个 CI 代理的计算资源闲置状态;
第一目的 CI代理确定单元 4022, 用于根据该至少两个 CI代理的计算资源闲置状态生 成该至少两个 CI代理的空闲计算资源权值, 如果当前 CI代理的空闲计算资源权值大于或 等于该可执行子任务的子任务权值, 则该当前 CI代理为目的 CI代理。
以及, 如图 6所示, 本发明实施例的 CI管理机还可以包括:
空闲计算资源权值获取请求接收模块 403, 用于接收该 CI主控发送的该空闲计算资源 权值的获取请求;
空闲计算资源权值获取请求响应模块 404, 用于响应该获取请求, 将对应的空闲计算资 源权值发送给该 CI主控, 使该 CI主控将其当前可执行的 CI子任务发送给根据该空闲计算 资源权值确定的目的 CI代理执行。
以及, 如图 6所示, 本发明实施例的 CI管理机还可以包括:
注册请求接收模块 405, 用于接收 CI主控和 CI代理发送的注册请求; CI代理类型获取模块 406, 用于根据至少两个 CI主控发送的注册请求, 获取至少两个 CI主控间的子任务依赖关系和所述至少两个 CI主控指定的 CI代理类型;
CI代理资源组管理模块 407, 用于根据至少两个 CI代理发送的注册请求, 获取该 CI 代理的类型, 将至少两个 CI代理按其类型组织成不同的 CI代理资源组。
以及, 如图 6所示, 本发明实施例的 CI管理机还可以包括:
执行结果接收模块 408, 用于接收该目的 CI代理发送的该可执行子任务的执行结果; 执行结果记录模块 409, 用于根据该至少两个 CI主控间的子任务依赖关系, 判断是否 有其他 CI主控的子任务的执行依赖该执行结果, 如果有, 则记录该执行结果;
执行结果获取请求响应模块 410, 用于响应该其他 CI主控发送的获取该执行结果的请 求, 使该其他 CI主控根据所述执行结果确定并发送其当前可执行的 CI子任务。
以及, 如图 6所示, 本发明实施例的 CI管理机还可以包括:
通信状态检测模块 411, 用于向 CI主控和 CI代理发送心跳握手消息, 以检测 CI主控 和 CI代理的通信状态;
可执行子任务重发模块 412, 用于当检测到该目的 CI代理通信状态异常, 将该目的 CI 代理未完成的可执行子任务重新发送给待执行该可执行子任务的目的 CI代理。
如图 7所示, 在另一种实现方式下, 本发明实施例提供的 CI管理机中, 目的 CI 代理 确定模块 402可以包括:
目的 CI代理资源组确定单元 4023, 用于根据该 CI主控指定的 CI代理类型, 确定目的 CI代理资源组;
第二目的 CI 代理确定单元 4024, 用于在该目的 CI代理资源组中, 根据该目的 CI代 理资源组中的 CI代理的在线通信状态、 所述 CI代理的计算资源闲置状态, 确定执行所述 可执行子任务的目的 CI 代理。
具体的, 如果该目的 CI代理资源组中的 CI代理均处于在线通信状态时, 根据该 CI代 理返回的空闲状态查询响应, 获取 CI代理的计算资源闲置状态, 根据该 CI代理的计算资 源闲置状态生成该 CI代理的空闲计算资源权值, 如果当前 CI代理的空闲计算资源权值大 于或等于该可执行子任务的子任务权值, 则该当前 CI代理为目的 CI代理。
CI代理的计算资源由该 CI代理运行时各方面的参数决定,本实施例中主要选取较重要 的几项, 包括: CPU资源和内存资源, 则 CI代理的计算资源的闲置状态可以用该 CI代理当 前可用的 CUP资源及其可用的内存资源来表征。
优选的, 为了方便在系统运行过程中针对不同的应用对各个参数的比例进行适当调整,
CI 管理机为各参数设定不同的常量系数, 用来表示各个参数的重要程度, 则 CI 代理的空 闲计算资源权值可以通过公式描述为:
CI代理权值 =Rl*f:ree— cpu + R2* free memory
其中, free— cpu表示 CI代理当前可用的 CUP资源, R1为 CUP资源常量系数, free—memory 表示 CI代理当前可用的内存资源, R2为内存资源常量系数。
本实施例通过根据可执行子任务的子任务权值和 CI 代理空闲资源权值为其确定目的
CI 代理, 实现 CI 代理间的负载分担, 提高 CI 代理的利用率, 提高了持续集成的效率; 通过 CI管理机同时接受所有 CI子任务, 并将 CI子任务发送给 CI代理, 进而实现了 CI主 控间对 CI 代理的并发控制; 并且由于 CI代理为通用的计算单元, 使有利于实现任务的增 减, 无需修改 CI主控和 CI代理, 进而增强了系统可扩展性。 通过 CI主控向 CI管理机发 送空闲计算资源权值的获取请求; CI 管理机响应该获取请求, 将所述空闲计算资源权值发 送给所述 CI主控, 由 CI主控直接下发可执行任务至目的 CI代理, 减少了 CI管理机的负 荷, 进一步提高了可执行任务的执行效率。 实施例 5
如图 8 所示, 本发明实施例还提供了一种软件持续集成的系统, 该系统包括: 至少两 个 CI主控 501、 CI管理机 502、 至少两个 CI代理 503, 所述至少两个 CI 代理为通用计算 单元;
该 CI主控 501用于接收用户下发的 CI任务, 将所述 CI任务分解成至少两项 CI子任 务, 向所述 CI管理机发送当前可执行的 CI子任务;
该 CI管理机 502, 用于接收并管理所述 CI主控 501发送的 CI子任务; 根据当前管理 的 CI代理资源池中至少两个 CI代理 503的在线通信状态、 所述至少两个 CI代理 503的计 算资源闲置状态,确定执行自身管理的至少一个 CI子任务中的当前可执行子任务的目的 CI 代理, 并将所述当前可执行子任务发送至所述目的 CI 代理;
具体的, 在当前管理的 CI代理资源池中的 CI代理 503均处于在线通信状态时, CI管 理机 502根据所述至少两个 CI代理 503返回的空闲状态查询响应, 获取至少两个 CI代理 503的计算资源闲置状态; CI管理机 502根据所述至少两个 CI代理 503的计算资源闲置状 态生成所述至少两个 CI代理 503的空闲计算资源权值, 如果当前 CI代理 503的空闲计算 资源权值大于或等于所述可执行子任务的子任务权值, 则所述当前 CI代理 503为目的 CI 代理。
该 CI 代理为 CI管理机 502确定的目的 CI代理时, 用于接收并执行 CI管理机 502发 送的可执行子任务。 所述 CI主控 501, 还用于向所述 CI管理机 502发送注册请求;
所述 CI代理 503, 还用于向所述 CI管理机 502发送注册请求;
所述 CI管理机 502, 还用于接收所述 CI主控 501发送的注册请求, 根据至少两个 CI 主控 501发送的注册请求, 获取至少两个 CI主控 501间的子任务依赖关系和至少两个 CI 主控 501指定的 CI代理类型; 接收所述 CI代理 503发送的注册请求, 根据至少两个 CI代 理 503发送的注册请求, 获取所述至少两个 CI代理 503的类型, 将至少两个 CI代理 503 按其类型组织成不同的 CI代理资源组。
CI主控 501, 还用于向 CI管理机 502发送的所述空闲计算资源权值的获取请求;
CI管理机 502还用于, 响应所述获取请求, 将所述空闲计算资源权值发送给所述 CI主 控 501,使所述 CI主控 501将其当前可执行的 CI子任务发送给根据所述空闲计算资源权值 确定的目的 CI代理执行。
该 CI 代理 503为 CI管理机 502确定的目的 CI代理时, 还用于向 CI主控 501发送该 可执行任务的执行结果;
CI管理机 502还用于, 接收所述目的 CI代理发送的所述可执行子任务的执行结果; 根 据所述至少两个 CI主控 501间的子任务依赖关系, 判断是否有其他 CI主控 501的子任务 的执行依赖所述执行结果, 如果有, 则记录所述执行结果;
CI主控 501, 还用于向 CI管理机 502发送执行结果获取请求;
CI管理机 502, 还用于响应所述其他 CI主控 501发送的获取所述执行结果的请求, 使 所述其他 CI主控 501根据所述执行结果确定并发送当前可执行的 CI子任务。
CI管理机 502, 还用于根据所述 CI主控 501指定的 CI代理类型, 确定目的 CI代理资 源组;
在所述目的 CI代理资源组中, 根据所述目的 CI代理资源组中的 CI代理 503的在线通 信状态、 CI代理 503的计算资源闲置状态, 确定执行所述可执行子任务的目的 CI 代理。
CI管理机 502, 用于向 CI主控 501和 CI代理 503发送心跳握手消息, 以检测 CI主控 501和 CI代理的在线通信状态; 当检测到所述目的 CI代理通信状态异常, 将所述目的 CI 代理未完成的可执行子任务重新发送给待执行所述可执行子任务的目的 CI代理。
在不同实现方式下, 所述 CI主控、 CI管理机、 CI 代理分别部署于不同的计算节点, 或者组合部署于同一计算节点。 换言之, 本发明实施例的软件持续集成的系统, 既可以配 置为不同角色部署在不同环境中, 也可以统一部署在同一个环境中。
可见, 本实施例通过根据可执行子任务的子任务权值和 CI代理空闲资源权值为其确定 目的 CI 代理, 本实施例通过根据该可执行子任务和 CI 代理资源确定执行该可执行子任务 的目的 CI 代理, 实现 CI 代理间的负载分担, 提高 CI 代理的利用率, 提高了持续集成的 效率; 通过 CI管理机同时接受所有 CI子任务, 并将 CI子任务发送给 CI 代理, 进而实现 了 CI主控间对 CI 代理的并发控制。
进一步的, 本发明实施例中, 通过心跳注册通信机制和并发任务控制管理, 达到 CI主 控和 CI Agent都可以动态增删而不影响整个系统的可用性。 本实施例提供的装置、 系统, 具体可以, 与方法实施例属于同一构思, 其具体实现过 程详见方法实施例, 这里不再赘述。 本领域普通技术人员可以理解: 实现上述方法实施例的全部或部分步骤可以通过程序 指令相关的硬件来完成, 前述的程序可以存储于一计算机可读取存储介质中, 该程序在执 行时, 执行包括上述方法实施例的步骤; 而前述的存储介质包括: R0M、 RAM, 磁碟或者光 盘等各种可以存储程序代码的介质。
以上所述仅为本发明的较佳实施例, 并不用以限制本发明, 凡在本发明的精神和原则 之内, 所作的任何修改、 等同替换、 改进等, 均应包含在本发明的保护范围之内。

Claims

权 利 要 求 书
1、 一种软件持续集成的方法, 其特征在于, 所述方法包括:
接收并管理持续集成 CI主控发送的 CI子任务;
根据当前管理的 CI代理资源池中至少两个 CI代理的在线通信状态及所述至少两个 CI代 理的计算资源闲置状态,确定执行当前管理的至少一个 CI子任务中的当前可执行子任务的目 的 CI 代理, 并将所述当前可执行子任务发送至所述目的 CI 代理, 使所述目的 CI 代理执行 所述可执行子任务, 所述至少两个 CI 代理为通用计算单元。
2、 根据权利要求 1所述方法, 其特征在于, 所述根据当前管理的 CI代理资源池中至少 两个 CI代理的在线通信状态、 所述至少两个 CI代理的计算资源闲置状态, 确定执行所述可 执行子任务的目的 CI 代理, 包括:
在当前管理的 CI代理资源池中的至少两个 CI代理均处于在线通信状态时, 根据所述至 少两个 CI代理返回的空闲状态查询响应, 获取至少两个 CI代理的计算资源闲置状态;
根据所述至少两个 CI代理的计算资源闲置状态生成所述至少两个 CI代理的空闲计算资 源权值, 如果当前 CI代理的空闲计算资源权值大于或等于所述可执行子任务的子任务权值, 则所述当前 CI代理为目的 CI代理。
3、 根据权利要求 2所述方法, 其特征在于, 所述方法还包括:
接收所述 CI主控发送的所述空闲计算资源权值的获取请求;
响应所述获取请求, 将所述空闲计算资源权值发送给所述 CI主控, 使所述 CI主控将其 当前可执行的 CI子任务发送给根据所述空闲计算资源权值确定的目的 CI代理执行。
4、根据权利要求 1所述方法, 其特征在于, 所述接收 CI主控发送的可执行子任务之前, 所述方法还包括:
接收 CI主控和 CI代理发送的注册请求;
根据至少两个 CI主控发送的注册请求, 获取所述至少两个 CI主控间的子任务依赖关系 和所述至少两个 CI主控指定的 CI代理类型;
根据至少两个 CI代理发送的注册请求, 获取所述至少两个 CI代理的类型, 将所述至少 两个 CI代理按其类型组织成不同的 CI代理资源组。
5、 根据权利要求 4所述方法, 其特征在于, 所述根据当前管理的 CI代理资源池中至少 两个 CI代理的在线通信状态、 所述至少两个 CI代理的计算资源闲置状态, 确定执行当前管 理的至少一个 CI子任务中的当前可执行子任务的目的 CI代理, 并将所述可执行子任务发送 至所述目的 CI 代理, 使所述目的 CI 代理执行所述可执行子任务, 所述 CI 代理为通用计算 单元之后, 所述方法还包括:
接收所述目的 CI代理发送的所述可执行子任务的执行结果;
根据所述至少两个 CI主控间的子任务依赖关系, 判断是否有其他 CI主控的子任务的执 行依赖所述执行结果, 如果有, 则记录所述执行结果;
响应所述其他 CI主控发送的获取所述执行结果的请求, 使所述其他 CI主控根据所述执 行结果确定并发送当前可执行的 CI子任务。
6、根据权利要求 4所述方法, 其特征在于, 所述接收 CI主控发送的可执行子任务之后, 所述方法还包括;
根据所述 CI主控指定的 CI代理类型, 确定目的 CI代理资源组;
所述根据当前管理的 CI代理资源池中至少两个 CI代理的在线通信状态、 所述至少两个
CI代理的计算资源闲置状态, 确定执行所述可执行子任务的目的 CI 代理, 包括:
在所述目的 CI代理资源组中,根据所述目的 CI代理资源组中的 CI代理的在线通信状态、 所述 CI代理的计算资源闲置状态, 确定执行所述可执行子任务的目的 CI 代理。
7、 根据权利要求 1所述方法, 其特征在于, 所述方法还包括:
向 CI主控和 CI代理发送心跳握手消息,以检测所述 CI主控和所述 CI代理的通信状态; 当检测到所述目的 CI代理通信状态异常, 将所述目的 CI代理未完成的可执行子任务重新发 送给待执行所述可执行子任务的目的 CI代理。
8、 一种 CI管理机, 其特征在于, 所述 CI管理机包括:
可执行子任务接收模块, 用于接收并管理 CI主控发送的 CI子任务;
目的 CI 代理确定模块, 用于根据当前管理的 CI代理资源池中至少两个 CI代理的在线 通信状态、 所述至少两个 CI代理的计算资源闲置状态, 确定执行当前管理的至少一个 CI子 任务中的当前可执行子任务的目的 CI代理,并将所述可执行子任务发送至所述目的 CI代理, 使所述目的 CI 代理执行所述可执行子任务, 所述至少两个 CI 代理为通用计算单元。
9、 根据权利要求 8所述 CI管理机, 其特征在于, 所述目的 CI 代理确定模块包括: 计算资源闲置状态获取单元, 用于在当前管理的 CI代理资源池中的至少两个 CI代理均 处于在线通信状态时, 根据所述至少两个 CI 代理返回的空闲状态查询响应, 获取至少两个 CI代理的计算资源闲置状态;
第一目的 CI代理确定单元, 用于根据所述至少两个 CI代理的计算资源闲置状态生成所 述至少两个 CI代理的空闲计算资源权值, 如果当前 CI代理的空闲计算资源权值大于或等于 所述可执行子任务的子任务权值, 则所述当前 CI代理为目的 CI代理。
10、 根据权利要求 9所述 CI管理机, 其特征在于, 所述 CI管理机还包括:
空闲计算资源权值获取请求接收模块,用于接收所述 CI主控发送的所述空闲计算资源权 值的获取请求;
空闲计算资源权值获取请求响应模块, 用于响应所述获取请求, 将所述空闲计算资源权 值发送给所述 CI主控,使所述 CI主控将其当前可执行的 CI子任务发送给根据所述空闲计算 资源权值确定的目的 CI代理执行。
11、 根据权利要求 8所述 CI管理机, 其特征在于, 所述 CI管理机还包括:
注册请求接收模块, 用于接收 CI主控和 CI代理发送的注册请求;
CI代理类型获取模块, 用于根据至少两个 CI主控发送的注册请求, 获取所述至少两个
CI主控间的子任务依赖关系和所述至少两个 CI主控指定的 CI代理类型;
CI代理资源组管理模块, 用于根据至少两个 CI代理发送的注册请求, 获取所述至少两 个 CI代理的类型, 将所述至少两个 CI代理按其类型组织成不同的 CI代理资源组。
12、 根据权利要求 11所述 CI管理机, 其特征在于, 所述 CI管理机还包括: 执行结果接收模块, 用于接收所述目的 CI代理发送的所述可执行子任务的执行结果; 执行结果记录模块, 用于根据所述至少两个 CI主控间的子任务依赖关系, 判断是否有其 他 CI主控的子任务的执行依赖所述执行结果, 如果有, 则记录所述执行结果;
执行结果获取请求响应模块, 用于响应所述其他 CI 主控发送的获取所述执行结果的请 求, 使所述其他 CI主控根据所述执行结果确定并发送当前可执行的 CI子任务。
13、 根据权利要求 11所述 CI管理机, 其特征在于, 所述目的 CI 代理确定模块包括: 目的 CI代理资源组确定单元, 用于根据所述 CI主控指定的 CI代理类型, 确定目的 CI 代理资源组;
第二目的 CI 代理确定单元, 用于在所述目的 CI代理资源组中, 根据所述目的 CI代理 资源组中的 CI代理的在线通信状态、 所述 CI代理的计算资源闲置状态, 确定执行所述可执 行子任务的目的 CI 代理。
14、 根据权利要求 8所述 CI管理机, 其特征在于, 所述 CI管理机还包括:
通信状态检测模块, 用于向 CI主控和 CI代理发送心跳握手消息, 以检测所述 CI主控和 所述 CI代理的通信状态;
可执行子任务重发模块, 用于当检测到所述目的 CI代理通信状态异常, 将所述目的 CI 代理未完成的可执行子任务重新发送给待执行所述可执行子任务的目的 CI代理。
15、 一种软件持续集成的系统, 其特征在于, 所述系统包括: 至少两个 CI主控、 CI管 理机、 至少两个 CI 代理, 所述至少两个 CI 代理为通用计算单元;
所述 CI主控用于接收用户下发的 CI任务, 将所述 CI任务分解成至少两项 CI子任务, 向所述 CI管理机发送当前可执行的 CI子任务;
所述 CI管理机用于接收并管理所述 CI主控发送的 CI子任务; 根据当前管理的 CI代理 资源池中至少两个 CI代理的在线通信状态、 所述至少两个 CI代理的计算资源闲置状态, 确 定执行自身管理的至少一个 CI子任务中的当前可执行子任务的目的 CI代理, 并将所述当前 可执行子任务发送至所述目的 CI 代理;
所述 CI代理为所述 CI管理机确定的目的 CI代理时, 用于接收并执行所述 CI管理机发 送的当前可执行子任务。
16、 根据权利要求 13所述的系统, 其特征在于, 所述系统还包括:
所述 CI主控, 还用于向所述 CI管理机发送注册请求;
所述 CI代理, 还用于向所述 CI管理机发送注册请求;
所述 CI管理机, 还用于接收所述 CI主控发送的注册请求, 根据至少两个 CI主控发送的 注册请求, 获取所述至少两个 CI主控间的子任务依赖关系和所述至少两个 CI主控指定的 CI 代理类型; 接收所述 CI代理发送的注册请求, 根据至少两个 CI代理发送的注册请求, 获取 所述至少两个 CI代理的类型,将所述至少两个 CI代理按其类型组织成不同的 CI代理资源组。
PCT/CN2011/075091 2010-09-19 2011-06-01 软件持续集成的方法、装置和系统 WO2011144132A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201010290480.1 2010-09-19
CN2010102904801A CN101957778B (zh) 2010-09-19 2010-09-19 软件持续集成的方法、装置和系统

Publications (1)

Publication Number Publication Date
WO2011144132A1 true WO2011144132A1 (zh) 2011-11-24

Family

ID=43485118

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/075091 WO2011144132A1 (zh) 2010-09-19 2011-06-01 软件持续集成的方法、装置和系统

Country Status (2)

Country Link
CN (1) CN101957778B (zh)
WO (1) WO2011144132A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104298588A (zh) * 2013-07-16 2015-01-21 阿里巴巴集团控股有限公司 一种持续集成的实现方法及装置

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101957778B (zh) * 2010-09-19 2012-11-21 华为技术有限公司 软件持续集成的方法、装置和系统
CN103577907B (zh) * 2012-07-24 2016-12-07 阿里巴巴集团控股有限公司 一种持续集成测试方法和系统
CN104778032A (zh) * 2014-01-09 2015-07-15 阿尔卡特朗讯 一种用于进行持续集成的方法和设备
CN109032769B (zh) * 2017-06-08 2020-09-11 中国移动通信集团浙江有限公司 一种基于容器的持续集成ci任务处理方法及装置
CN110018951B (zh) * 2018-01-10 2022-12-27 武汉斗鱼网络科技有限公司 一种js代码的测试方法、存储介质、设备和系统
CN108388988B (zh) * 2018-02-26 2021-07-06 深圳智乾区块链科技有限公司 基于区块链的协同办公方法、系统及计算机可读存储介质
CN109240810B (zh) * 2018-08-03 2021-02-23 腾讯科技(深圳)有限公司 任务处理方法、装置及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1622675A (zh) * 2003-11-28 2005-06-01 中兴通讯股份有限公司 第三代移动通信用户接纳控制系统及处理方法
CN101515232A (zh) * 2008-02-21 2009-08-26 卓望数码技术(深圳)有限公司 一种软件持续集成系统及方法
US20100114830A1 (en) * 2008-11-06 2010-05-06 Amadeus S.A.S Method of integrating in real time large volumes of updates in a database
CN101957778A (zh) * 2010-09-19 2011-01-26 华为技术有限公司 软件持续集成的方法、装置和系统

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101359295B (zh) * 2007-08-01 2012-05-02 阿里巴巴集团控股有限公司 一种批量任务调度分配方法及系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1622675A (zh) * 2003-11-28 2005-06-01 中兴通讯股份有限公司 第三代移动通信用户接纳控制系统及处理方法
CN101515232A (zh) * 2008-02-21 2009-08-26 卓望数码技术(深圳)有限公司 一种软件持续集成系统及方法
US20100114830A1 (en) * 2008-11-06 2010-05-06 Amadeus S.A.S Method of integrating in real time large volumes of updates in a database
CN101957778A (zh) * 2010-09-19 2011-01-26 华为技术有限公司 软件持续集成的方法、装置和系统

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104298588A (zh) * 2013-07-16 2015-01-21 阿里巴巴集团控股有限公司 一种持续集成的实现方法及装置

Also Published As

Publication number Publication date
CN101957778B (zh) 2012-11-21
CN101957778A (zh) 2011-01-26

Similar Documents

Publication Publication Date Title
WO2011144132A1 (zh) 软件持续集成的方法、装置和系统
JP6373432B2 (ja) 仮想環境における演算インフラストラクチャのリアルタイム最適化
US10884787B1 (en) Execution guarantees in an on-demand network code execution system
US11010188B1 (en) Simulated data object storage using on-demand computation of data objects
JP6352535B2 (ja) プログラム・コードを実行するための要求に対するプログラム的イベント検出及びメッセージ生成
US8938510B2 (en) On-demand mailbox synchronization and migration system
US8881149B2 (en) Control of java resource runtime usage
US7779410B2 (en) Control interfaces for distributed system applications
TWI446184B (zh) 在一混合計算環境之資料處理
KR101855541B1 (ko) 컴퓨트 클러스터에서의 디버거 런칭 및 첨부 기법
JP4421637B2 (ja) サブタスク・プロセッサの分散スケジューリング
JP2020501253A (ja) 局所化されたデバイスコーディネータにおけるオンデマンドコード実行
US8239588B2 (en) System and method for improved I/O node control in computer system
US11030009B2 (en) Systems and methods for automatically scaling compute resources based on demand
US9164806B2 (en) Processing pattern framework for dispatching and executing tasks in a distributed computing grid
US20130275968A1 (en) Application management methods and systems
US20130061220A1 (en) Method for on-demand inter-cloud load provisioning for transient bursts of computing needs
US20110252137A1 (en) Systems and Methods for Dynamically Provisioning Cloud Computing Resources
JP2004252975A (ja) 自己最適化のために観察されたリソース要件を使用するオートノミック・サービス・ルーティング
JP2020502643A (ja) オンデマンドコード実行能力を有する局所化されたデバイスコーディネータ
JP2014528116A (ja) ポータブルコンピューティングデバイスにおける分散リソース管理
WO2019006808A1 (zh) 一种处理长连接建立请求的方法和装置
JP2007506157A (ja) マルチノードシステムにおけるリソースの動的な割当の階層的管理
JP2012198843A (ja) 仮想サーバ調整システム、仮想サーバ制御装置及びプログラム
JP2014528611A (ja) トランザクションミドルウェアマシン環境においてシングルポイントボトルネックを防止するためのシステムおよび方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11783049

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11783049

Country of ref document: EP

Kind code of ref document: A1