WO2023273164A1

WO2023273164A1 - Code integrated verification method and device

Info

Publication number: WO2023273164A1
Application number: PCT/CN2021/135869
Authority: WO
Inventors: 梁正斌; 杨扬; 曲建伟; 薛明忠
Original assignee: 中兴通讯股份有限公司
Priority date: 2021-06-30
Filing date: 2021-12-06
Publication date: 2023-01-05
Also published as: CN115543277A

Abstract

A code integrated verification method and device. The method comprises: constituting, into a change order group, a plurality of change orders received from a code hosting system, having an association relation, and used for code change (S202); determining a code merging order of each change order in the change order group according to the dependency among the plurality of change orders (S204); respectively performing code merging on the change orders in the change order group according to the code merging order (S206); and invoking a code integration system to perform integrated verification on the merged code in the change order group (S208).

Description

Code integration verification method and device

Cross References to Related Applications

This application is based on a Chinese patent application with application number 202110743930.6 and a filing date of June 30, 2021, and claims the priority of this Chinese patent application. The entire content of this Chinese patent application is hereby incorporated by reference into this application.

technical field

The embodiments of the present application relate to the technical field of software engineering, and in particular, to a code integration verification method and device.

Background technique

Members of a software development team often need to integrate their code writing work, and usually each member integrates at least once a day, which means that integration may occur multiple times a day. The general process is that the developer completes the development locally, and then submits it to the code management system. The code management system and the code integration system complete the pre-integration check of the code. After the check is passed, it is merged into the corresponding code integration branch to complete the local Integration of development code.

The current general practice is that each developer submits the code to the code review system after completing local development, and triggers an automated continuous integration pipeline for automated construction, such as compilation, release, and automated testing, to test and verify the changed code .

As the size of the code increases, when multiple people need to submit the code review system at the same time and trigger the build, each person's verification only has their own changes, and the purpose of integration cannot be achieved. The current general practice is that each change is verified separately and merged in separately. If a build verification fails, it will be repaired. In this way, the continuity of code integration may be affected, resulting in phased versions being unavailable. That is, the construction verification of the change of the current software code is only for the verification of a change order, and there is a lack of a solution for simultaneous change verification of multiple changes to the software.

Contents of the invention

The embodiment of the present application provides a code integration verification method and device to at least solve one of the related technical problems to a certain extent, including the forced integration of a single change order when multiple change orders have dependencies. Problems will lead to staged unsustainable integration of the entire software/subsystem, thereby blocking the reintegration of the entire system, resulting in blocking waiting and waste.

According to one embodiment of the present application, a method for code integration verification is provided, including: combining multiple change orders for code changes received from the code hosting system into a change order group; according to the multiple change orders Determine the code merging sequence of each change order in the change order group according to the dependency relationship between orders; perform code merging on each change order in the change order group according to the code merging order; call the code integration system to The code after the change order group is merged undergoes integration verification.

According to another embodiment of the present application, a code integration verification device is provided, including: a composition module configured to compose a plurality of change orders for code changes received from a code hosting system with an association relationship into a change order group ; The determination module is configured to determine the code merging sequence of each change order in the change order group according to the dependency relationship between the multiple change orders; the merging module is configured to perform the changes according to the code merging sequence The codes of the change orders in the single group are merged separately; the calling module is set to call the code integration system to perform integration verification on the code after the merged change order group.

According to yet another embodiment of the present application, a computer-readable storage medium is also provided, and a computer program is stored in the computer-readable storage medium, wherein the computer program is configured to perform any one of the above-mentioned methods when running Steps in the examples.

According to yet another embodiment of the present application, there is also provided an electronic device, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to perform any of the above Steps in the method examples.

Description of drawings

FIG. 1 is a block diagram of a hardware structure of a computer terminal according to an embodiment of the present application;

Fig. 2 is a flow chart of the code integration verification method according to the embodiment of the present application;

Fig. 3 is a flowchart of a code integration verification device according to an embodiment of the present application;

FIG. 4 is a flowchart of a code integration verification device according to another embodiment of the present application;

Fig. 5 is a schematic diagram of a code gating system according to an embodiment of the present application;

Fig. 6 is a flow chart of simultaneous construction verification of multiple change orders according to an embodiment of the present application;

Fig. 7 is a flow chart of code integration verification of multiple change orders in a single code warehouse according to an embodiment of the present application;

Fig. 8 is a flowchart of code integration verification of multiple change orders of multiple code warehouses according to an embodiment of the present application;

Fig. 9 is a flow chart of code integration verification for dynamically adjusting and changing odd numbers according to an embodiment of the present application;

Fig. 10 is a flow chart of code integration verification with a preceding change order or a group of preceding change orders according to an embodiment of the present application.

detailed description

Embodiments of the present application will be described in detail below with reference to the drawings and in combination with the embodiments.

It should be noted that the terms "first" and "second" in the description and claims of the present application and the above drawings are used to distinguish similar objects, but not necessarily used to describe a specific sequence or sequence.

The method embodiments provided in the embodiments of the present application may be executed in mobile terminals, computer terminals or similar computing devices. Taking running on a computer terminal as an example, FIG. 1 is a block diagram of the hardware structure of a computer terminal in a code integration verification method according to an embodiment of the present application. As shown in Figure 1, the computer terminal may include one or more (only one is shown in Figure 1) processors 102 (processors 102 may include but not limited to processing devices such as microprocessor MCU or programmable logic device FPGA, etc.) and a memory 104 for storing data, wherein the above-mentioned computer terminal may also include a transmission device 106 and an input and output device 108 for communication functions. Those skilled in the art can understand that the structure shown in FIG. 1 is only for illustration, and it does not limit the structure of the above computer terminal. For example, the computer terminal may also include more or fewer components than shown in FIG. 1 , or have a different configuration than that shown in FIG. 1 .

The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the code integration verification method in the embodiment of the present application, and the processor 102 executes the computer program stored in the memory 104 by running the computer program. Various functional applications and data processing are to realize the above-mentioned method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory located remotely relative to the processor 102, and these remote memories may be connected to a computer terminal through a network. Examples of the aforementioned networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The transmission device 106 is used to receive or transmit data via a network. The specific example of the above-mentioned network may include a wireless network provided by the communication provider of the computer terminal. In one example, the transmission device 106 includes a network interface controller (NIC for short), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 may be a radio frequency (Radio Frequency, referred to as RF) module, which is used to communicate with the Internet in a wireless manner.

The following briefly describes the following software continuous integration terms involved in the embodiments of the present application.

Change order: The software developer submits the local code changes to the code hosting system, and the code hosting system generates a change record, that is, a change order, such as but not limited to Gerrit's change.

Change order information: Change order information includes, but is not limited to: one-way dependency information, change group information (hash code, group size, etc.), change information (code project name, branch), etc.

For example, the following one-way change order group information format, but not limited to this format:

comment: this is a comment

depends: other-change-id

change-id:my-change-id

For example, the following two-way change order group information and change information format, but not limited to this format:

comment: this is a comment

group-id:my-group-change-id

goup-size: 2

change-id:my-change-id

One-way change order: A change order associated through the one-way change order message format. Its characteristics are: this change order indicates that it depends on other change orders, and other change orders do not depend on this change order. The so-called not relying on other change orders means that code integration will not fail in the absence of other change orders.

One-way change order group: multiple related one-way change orders, called one-way change order group.

Bidirectional Change Order: A series of Change Orders linked through the Bidirectional Change Order message format. Its characteristics are: one or more of multiple change orders may cause code integration failure when other change orders are missing.

Bidirectional change order group: multiple related bidirectional change orders, called bidirectional change order group

Pre-sequence change order: When one or more change orders are not completed, the unfinished change is called the previous change order.

Pre-sequence change order group: When one or more change order groups are incomplete and a new change order group meets the merge condition, the unfinished change order group is called the previous change order group.

In this embodiment, a code integration verification method is provided. When a single change order is forcibly merged into multiple change orders with dependencies, a local pre-merge method is used to merge multiple related change orders into a change order group to ensure its atomicity. Then conduct continuous integration verification, and integrate or not integrate the same group of change orders at the same time according to the verification results. In this way, the continuous integration of products is guaranteed to be available, thereby improving the efficiency of software development and verification.

FIG. 2 is a flowchart of a code integration verification method according to an embodiment of the present application, and the method can be applied to the hardware structure shown in FIG. 1 . As shown in Figure 2, the process includes the following steps:

Step S202, combining multiple associated change orders received from the code hosting system for code change into a change order group;

Step S204, determining the code merging order of each change order in the change order group according to the dependencies among the plurality of change orders;

Step S206, perform code merging on each change order in the change order group according to the code merging sequence;

Step S208, calling the code integration system to perform integration verification on the merged code of the change order group.

In this embodiment, the change order group may be one of the following: a one-way change order group, a two-way change order group, and a preceding change order group.

In step S202 of this embodiment, combining multiple change orders with associated relationships received from the code hosting system into a change order group may include: obtaining all associated change orders according to the identification query of the dependency information of the multiple change orders the plurality of change orders; forming the plurality of change orders into the change order group.

Before step S202 of this embodiment, it may also include: receiving multiple requests for changing the hosted code submitted by the user through the code hosting system, and generating multiple change orders and corresponding change order information, wherein, The change order information is at least one of the following: one-way dependency information, change order group information, and change information.

In step S204 of this embodiment, determining the code merging order of each change order in the change order group according to the dependency relationship between the plurality of change orders may include: the change order group is a one-way change order group , determining the code merging sequence of each change order according to the dependency sequence of each change order in the one-way change order group.

In step S206 of this embodiment, performing code merging on each change order in the change order group according to the code merging sequence may include: downloading each change order in the change order group from the code hosting system The code corresponding to the order is downloaded locally, such as downloaded to the local storage or server; according to the code merging sequence, the code change of each change order is merged with the code corresponding to the change order downloaded from the code hosting system, and marked with Label information for the change order group.

In step S208 of this embodiment, invoking the code integration system to perform integration verification on the merged code of the change order group may include: transferring the label information of the change order group to the code integration system, so that the The code integration system downloads the corresponding code according to the label information of the change order group, and performs integration verification.

After step S208 of this embodiment, it may also include: receiving the verification result of the code integration of the change order group fed back by the code integration system; All change order feedback code changes in the change order group can be integrated, and the code integration of the change order group is completed; if the verification result is that the code integration is unsuccessful, all change order feedback code changes in the change order group cannot be integrated .

In this embodiment, when the change order group includes a preceding change order group, the method may further include: merging multiple preceding change order groups being verified with the change order group into a first A change order group; determine the code merging of each preceding change order group in the first change order group according to the dependency relationship between the multiple preceding change order groups (if there is no dependency, follow the order of submission time of the change order) Sequence: according to the code merging sequence, perform code merging for each preceding change order group in the first change order group; call the code integration system to perform integration verification on the code after the first change order group is merged. That is, in the embodiment, when there is a previous change order group in the change order group, multiple previous change order groups with associated relationships can be further merged into one large change order group, so that the merged Code verification and integration is performed in units of large change order groups.

Through the above-mentioned steps of this embodiment, multiple associated change orders are merged into one change order group to ensure its atomicity, which solves the problem that the construction verification of software code changes only supports single change verification and that multiple change orders are forcibly merged into a single change order. When there are multiple change orders with dependencies, the blocking waiting and waste are caused, which improves the efficiency of software development and verification.

Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by means of software plus a necessary general-purpose hardware platform, and of course also by hardware, but in many cases the former is better implementation. Based on such an understanding, the technical solution of the present application can be embodied in the form of a software product in essence or the part that contributes to the prior art, and the computer software product is stored in a storage medium (such as ROM/RAM, disk, CD) contains several instructions to enable a terminal device (which may be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in the various embodiments of the present application.

In this embodiment, a code integration verification device is also provided, which is used to implement the above embodiments and other implementation modes, and what has been described will not be repeated. As used below, the term "module" or "unit" may be a combination of software and/or hardware that realizes a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementations in hardware, or a combination of software and hardware are also possible and contemplated.

Fig. 3 is a structural block diagram of a code integration verification device according to an embodiment of the present application. As shown in Fig. 3 , the device includes a composition module 10, a determination module 20, a combination module 30 and a calling module 40

The composition module 10 is configured to compose a plurality of change orders for code change received from the code escrow system and having an association relationship into a change order group.

The determining module 20 is configured to determine the code merging sequence of each change order in the change order group according to the dependency relationship among the plurality of change orders.

The merging module 30 is configured to perform code merging on each change order in the change order group according to the code merging sequence.

The calling module 40 is configured to call the code integration system to perform integration verification on the merged code of the change order group.

Through the code integration verification device provided in this embodiment, multiple associated change orders can be merged into a change order group to ensure its atomicity, which solves the problem that the construction verification of software code changes only supports single change verification and the When multiple change orders with dependencies are forcibly merged, the blocking waiting and waste caused, which improves the efficiency of software development and verification.

Fig. 4 is a structural block diagram of a code integration verification device according to another embodiment of the present application. As shown in Fig. 4, the device includes all the modules in the above-mentioned embodiments, in this embodiment, the component module 10 can be It further includes a query unit 11 and a composition unit 12 .

The query unit 11 is configured to query and obtain the multiple change orders with an association relationship according to the dependency information identification query of the multiple change orders.

The composition unit 12 is configured to compose the plurality of change orders into the change order group.

In this embodiment, the merging module 20 may further include a download unit 21 and a merging unit 22 .

The downloading unit 21 is configured to download the code corresponding to each change order in the change order group from the code escrow system to a local, for example, to a memory or a server of a code integration verification device.

The merging unit 22 is configured to merge the code changes of each change order with the code corresponding to the change order downloaded from the code escrow system according to the code merging sequence, and add the tag information of the change order group.

In this embodiment, the code integration verification device may further include a receiving module 50 , a first feedback module 60 and a second feedback module 70 .

The receiving module 50 is configured to receive the code integration verification result of the change order group fed back by the code integration system.

The first feedback module 60 is configured to feedback that code changes can be integrated for all change orders in the change order group when the verification result is that the code integration is successful, and complete the code integration of the change order group.

The second feedback module 70 is configured to, when the verification result is that the code integration is unsuccessful, feedback that the code change cannot be integrated for all change orders in the change order group.

It should be noted that the above-mentioned modules can be realized by software or hardware. For the latter, it can be realized by the following methods, but not limited to this: the above-mentioned modules are all located in the same processor; or, the above-mentioned modules can be combined in any combination The forms of are located in different processors.

In order to facilitate the understanding of the technical solutions provided by the present application, the following will describe in detail in conjunction with embodiments of specific scenarios.

In software development, when there are multiple change orders, especially the scenario where multiple change orders have dependencies, this embodiment provides a code gating system. As shown in Figure 5, the systems and modules involved in this embodiment are as follows:

Code hosting system: a system for code hosting and review. In this embodiment, the code hosting system may include but not limited to: Gerrit, Gitlab, etc. The code hosting system is used to host the user's code, receive the user's code changes, and generate change order.

For the code gating system 200 provided in this embodiment, it should be noted that the division of module functions in this embodiment is different from the division of modules in the foregoing embodiments. As shown in FIG. 5 , the code gating system 200 in this embodiment may include a scheduling module 201 , a combining module 202 and an executing module 203 .

Scheduling module 201: receives and stores the change information from the upstream code hosting system 100, and when there are multiple change orders, combines the multiple change orders into a change order group and sends it to the merge module.

The merging module 202: receives the change order group request from the scheduling module 201, pulls the change order codes and change information one by one from the code hosting system 100 in units of change order groups, and performs local merging.

Execution module 203 : receives the execution request from the scheduling module 201 , and transmits the merged change order group information to the continuous integration system 300 .

Continuous integration system 300: a system capable of obtaining a change order and performing build verification based on the change order. In this embodiment, the continuous integration system 300 may include but not limited to: Jenkins, GoCD, etc.

Based on the above system, this embodiment provides a code integration verification method. In this embodiment, the user submits multiple changes in the code hosting system, and enters the associated information of multiple change orders into the information of multiple change orders middle.

As shown in Figure 6, the method includes the following steps:

Step S601, submitting changes. Through the code hosting system, receive multiple changes from one user, or multiple changes from multiple users, and generate multiple change orders.

Step S602, cache modification. The scheduling module receives the change order from the code hosting system in real time, and the scheduling module queries the code hosting system for the information of the dependent order. The specific processing method is as follows:

a. For one-way change orders

Dependency information identification of a one-way change order: For example, the depends (depends) identification in the change information, but not limited to this identification, and multiple change orders that depend on this identification are called a one-way change order group.

Obtain dependent change order information: According to the dependent change order ID identified by the change order, it can be obtained by querying the cached change order information. For example, it can be obtained by querying the code hosting system, or querying other change order caches to obtain dependency information.

Obtain one-way change order group: form the queried related one-way change order into one-way change order group.

Complete the collection of change order groups: After the scheduling module receives each change submission event, follow the above method to query all dependent change order information.

b. For two-way change orders

According to the group ID and group size, the scheduling module collects all change order information of the change order group from the code hosting system.

The identification method of the two-way change order: it can be, but not limited to, identified by information such as group identification and group size.

Obtain bidirectional change order information: According to the dependent change order ID identified by the change order, it can be obtained by querying the cached change order information. For example, it can be obtained by querying the code hosting system, or querying other change order caches to obtain dependency information.

Obtain bidirectional change order group: convert the queried related bidirectional change order group into a bidirectional change order group.

Completing the collection of two-way change order groups: After the scheduling module receives each change submission event, it can query all dependent change order information according to the above method, wherein the number of two-way change order groups in the two-way change order group can be changed from Obtained from the description under the group of single information.

Step S603, determining the pre-merging order of the change order.

In this embodiment, it is first necessary to determine the sequence within the change order group. After the scheduling module completes the information collection of the change order group, it enters the link of determining the order of the change order:

a. For a one-way change order group, determine the pre-merging order of each one-way change order in the one-way change order group according to the order of depends.

b. For the two-way change order group, there is no order requirement, as long as all the change orders of the two-way change order group have been submitted to the code hosting system.

In this embodiment, the change combination merge request is then submitted. That is, submit the complete set of change orders to the merge module.

Step S604, merging change order groups.

In this embodiment, after the merging module receives the merging request of the change order group, it performs the following operations:

Download the change order code:

According to the change order group information and sequence, the change order code can be downloaded to the code escrow system to the local, for example, the change order code can be downloaded to the storage or server of the code gating system 200 .

Merge change group code:

The change group code can be merged through a distributed code management system provided locally, which can be but not limited to git.

Iterate over each change order in a change order group:

Code base merged for the first time: Merge the code changes of each change order with the latest code in the code hosting system of the change order, and label the code. The code label can be but not limited to:

refs/service/.../denpends-id

refs/service/.../groups-id.

In this embodiment, if there is a conflict between the change orders, an error is reported to the scheduling module, and the processing flow is transferred. Step S605, scheduling change order groups. After the scheduling module receives the label information of the change order group, it notifies the execution module to schedule the code integration of the change group, and specifically performs the following operations:

Transfer change order group labels: After receiving the change order group label information, the execution module calls the code integration system for integration verification, and at the same time transmits the change order group label information to the code integration system; the code integration system downloads the corresponding code according to the code label, Perform integration verification.

Collect change order code integration results: After the code integration system completes the integration verification, the execution module obtains the verification results and transmits them to the scheduling module.

Step S606, change order group integration. After the scheduling module receives the code integration result, it does the following:

For code change groups with successful code integration: For all change orders in the change order group, feedback that the code change can be integrated, and complete the automatic code integration. Feedback methods can be, but are not limited to: scoring the corresponding code integration results, automatically incorporating change orders, etc.

For code change groups whose code integration fails: For all change orders in the change order group, feedback that the code change cannot be integrated. The feedback method can be but not limited to: scoring the corresponding code integration results.

The technical solutions provided by this application will be described below in conjunction with specific scenarios.

The embodiment of this application provides a code integration verification method for multiple change order scenarios in a single code warehouse. As shown in Figure 7, this implementation includes the following steps:

Step S701, submit and update. In this embodiment, multiple code changes submitted by a single person or multiple people are all aimed at the same code warehouse, and the change orders are identified as a one-way change order group through the change order information. The rest of the process is the same as the above-mentioned embodiment shown in FIG. 6 .

Step S702, cache changes, and form multiple submitted changes into a one-way change order group. The specific process is the same as the embodiment shown above.

Step S703, determining the pre-merging sequence of the one-way change order group. The specific process is the same as the embodiment shown above.

Step S704, merging the one-way change order groups. If there is a conflict between change orders, report the error to the scheduling module and transfer to the processing flow. The rest of the flow process is the same as the embodiment shown above.

Step S705, scheduling the one-way change order group. The specific process is the same as the embodiment shown above.

Step S706, integrating the one-way change order group. The specific process is the same as the embodiment shown above.

The embodiment of this application also provides a code integration verification method for multiple change order scenarios in multiple code warehouses, as shown in Figure 8, this implementation includes the following steps:

Step S801, submit and update. In this embodiment, multiple code changes submitted by a single person or multiple people are aimed at the same multiple code warehouses, and the change orders are identified as two-way change order groups through change order information. The rest of the flow process is the same as the embodiment shown in Fig. 6 .

Step S802, cache the change order, and form a two-way change order group. The specific process is the same as the embodiment shown above.

Step S803, determining the pre-merging order of the change order group. The specific process is the same as the embodiment shown above.

Step S804, merging change order groups. If there is a conflict between change orders, report the error to the scheduling module and transfer to the error handling process. The rest of the flow process is the same as the embodiment shown above.

Step S805, scheduling change order groups. The specific process is the same as the embodiment shown above.

Step S806, integrating the change orders into groups. The specific process is the same as the embodiment shown above.

The embodiment of this application also provides a code integration verification method for multiple change order scenarios in multiple code warehouses that dynamically adjust the number of change orders. As shown in Figure 9, this implementation includes the following steps:

Step S901, submit and update. In this embodiment, multiple code changes submitted by a single person or multiple people are aimed at the same multiple code warehouses, and the change orders are identified as two-way change order groups through change order information. When there is a new change order that needs to be added to the two-way change group, it is only necessary to indicate the group size information in the change order information. When the scheduling module receives the change order information, it takes all the change order information The largest value of the group size is used as the group size of this change order. The rest of the flow process is the same as the embodiment shown in Fig. 6 .

Step S902, cache modification. The specific process is the same as the embodiment shown above.

Step S903, determining the pre-merging order of the change order group. The specific process is the same as the embodiment shown above.

Step S904, merging change order groups. If there is a conflict between change orders, report the error to the scheduling module and transfer to the error handling process. The rest of the flow process is the same as the embodiment shown above.

Step S905, scheduling change order groups. The specific process is the same as the embodiment shown above.

Step S906, change order group integration. The specific process is the same as the embodiment shown above.

The embodiment of this application also provides a code integration verification method for multiple change order scenarios in multiple code warehouses, that is, for multiple change order group parallel scenarios, as shown in Figure 10, this implementation includes the following steps:

Step S1001, submit and update. In this embodiment, when a change order group has completed code pre-merging but has not completed integration verification, the scheduler receives a new change order group, that is, when there is a previous change order or a previous change order group. The rest of the flow process is the same as the embodiment shown above.

Step S1002, cache modification. When the scheduling module inquires about a change order group that has not completed integration verification, it will transfer the code labels or change order information of one or more uncompleted change order groups to the new change order group, that is, there is a previous change order group or a previous change order group. When the order is changed, all the other processes are the same as the above-mentioned embodiment.

Step S1003, determining the pre-merging sequence of the change order. In this embodiment, when the new change order group has a previous change order group or a previous change order group, the previous change order group is taken as the first in the pre-merging order of the new change order, and the rest of the process is the same as that shown in Figure 6 Example.

Step S1004, merging change order groups. If there is a conflict between change orders, report the error to the scheduling module and transfer to the error handling process. The rest of the flow process is the same as the embodiment shown above.

Step S1005, scheduling change order groups. The specific process is the same as the embodiment shown above.

Step S1006, change the single group integration. The specific process is the same as the embodiment shown above.

Embodiments of the present application also provide a computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to perform the steps in any one of the above method embodiments when running.

In one embodiment, the above-mentioned computer-readable storage medium may include but not limited to: U disk, read-only memory (Read-Only Memory, referred to as ROM), random access memory (Random Access Memory, referred to as RAM), mobile Various media that can store computer programs, such as hard disks, magnetic disks, or optical disks.

An embodiment of the present application also provides an electronic device, including a memory and a processor, where a computer program is stored in the memory, and the processor is configured to run the computer program to perform the steps in any one of the above method embodiments.

In an embodiment, the electronic device may further include a transmission device and an input and output device, wherein the transmission device is connected to the processor, and the input and output device is connected to the processor.

For specific examples in this embodiment, reference may be made to the examples described in the foregoing embodiments and other implementation manners, and details will not be repeated here in this embodiment.

Through the above-mentioned embodiments of the present application, multiple associated change orders can be combined into one change order group to ensure its atomicity, and then continuous integration verification is performed. This solves the problem that when a single change order is forcibly merged into multiple change orders with dependencies, it sometimes leads to unsustainable integration in stages, resulting in blocking waiting and waste, and achieves the effect of simultaneous change verification of multiple change orders.

Obviously, those skilled in the art should understand that each module or each step of the above-mentioned application can be realized by a general-purpose computing device, and they can be concentrated on a single computing device, or distributed in a network composed of multiple computing devices In fact, they can be implemented in program code executable by a computing device, and thus, they can be stored in a storage device to be executed by a computing device, and in some cases, can be executed in an order different from that shown here. Or described steps, or they are fabricated into individual integrated circuit modules, or multiple modules or steps among them are fabricated into a single integrated circuit module for implementation. As such, the present application is not limited to any specific combination of hardware and software.

The above descriptions are only some embodiments of the present application, and are not intended to limit the present application. For those skilled in the art, the present application can have various modifications and changes. Any modifications, equivalent replacements, improvements, etc. made within the principles of this application shall be included within the scope of protection of this application.

Claims

A code integration verification method comprising:

Combine multiple associated change orders received from the code hosting system for code changes into a change order group;

determining the code merging sequence of each change order in the change order group according to the dependency relationship among the plurality of change orders;

Perform code merging for each change order in the change order group according to the code merging sequence;

Invoke the code integration system to perform integration verification on the merged code of the change order group.
The method according to claim 1, wherein the change order group is one of the following: a one-way change order group, a two-way change order group, and a preceding change order group.
The method according to claim 1, wherein forming a plurality of change orders received from the code hosting system with associated relationships into a change order group comprises:

Obtaining the plurality of change orders with an association relationship according to the dependency information identification query of the plurality of change orders;

Composing the plurality of change orders into the change order group.
The method according to claim 1, wherein, before composing a plurality of change orders with associated relationships received from the code hosting system into a change order group, further comprising:

Multiple requests for changes to the hosted code submitted by users are received through the code hosting system, and multiple change orders and corresponding change order information are generated, wherein the change order information is at least one of the following: one-way dependency information, change order group information, change information.
The method according to claim 2, wherein determining the code merging order of each change order in the change order group according to the dependency relationship among the plurality of change orders comprises:

The change order group is a one-way change order group, and the code merging sequence of each change order is determined according to the dependency sequence of each change order in the one-way change order group.
The method according to claim 1, wherein code merging is performed on each change order in the change order group according to the code merging sequence, including:

Download the code corresponding to each change order in the change order group from the code hosting system to the local;

According to the code merging sequence, the code change of each change order is merged with the code corresponding to the change order downloaded from the code escrow system, and the label information of the change order group is marked.
The method according to claim 6, wherein calling the code integration system to perform integration verification on the code after the change order group is merged includes:

The label information of the change order group is transmitted to the code integration system, so that the code integration system downloads the corresponding code according to the label information of the change order group, and performs integration verification.
The method according to claim 7, wherein, after invoking the code integration system to perform integration verification on the code after the change order group is merged, further comprising:

receiving the code integration verification result of the change order group fed back by the code integration system;

If the verification result shows that the code integration is successful, feedback code changes for all change orders in the change order group can be integrated, and complete the code integration of the change order group;

If the verification result is that the code integration is unsuccessful, all change orders in the change order group are fed back that the code changes cannot be integrated.
The method according to claim 2, wherein, when there is a previous change order and/or a group of previous change orders that have not completed integration verification in the change order group, the method further comprises:

combining the preceding change order and/or the set of preceding change orders with the set of change orders into a first set of change orders;

For the change orders with dependencies in the first change order group, determine the merge order according to the dependencies, and determine the merge order according to the submission order for the change orders without dependencies;

Perform code merging of each change order in the first change order group according to the merging sequence;

The code integration system is invoked to perform integration verification on the merged code of the first change order group.
A code integration verification device, comprising:

A composition module, configured to compose a plurality of change orders for code change received from the code hosting system with an associated relationship into a change order group;

The determination module is configured to determine the code merging sequence of each change order in the change order group according to the dependency relationship among the plurality of change orders;

The merging module is configured to perform code merging on each change order in the change order group according to the code merging sequence;

The calling module is configured to call the code integration system to perform integration verification on the code after the change order group is merged.
The apparatus according to claim 10, wherein said constituent modules comprise:

The query unit is configured to query and obtain the multiple change orders with an association relationship according to the identification of the dependency information of the multiple change orders;

A composing unit configured to compose the plurality of change orders into the change order group.
The apparatus according to claim 10, wherein the merging module comprises:

The download unit is configured to download the code corresponding to each change order in the change order group from the code hosting system to the local;

The merging unit is configured to merge the code changes of each change order with the code corresponding to the change order downloaded from the code escrow system according to the code merging sequence, and add the label information of the change order group.
The apparatus of claim 10, further comprising:

The receiving module is configured to receive the code integration verification result of the change order group fed back by the code integration system;

The first feedback module is configured to, when the verification result indicates that the code integration is successful, feedback that code changes can be integrated for all change orders in the change order group, and complete the code integration of the change order group;

The second feedback module is configured to feedback that code changes cannot be integrated for all change orders in the change order group when the verification result is code integration failure.
A computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, the steps of the method described in any one of claims 1 to 9 are realized.
An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor implements claims 1 to 9 when executing the computer program The step of the method described in any one.