Code integration method, device, equipment and storage medium

Abstract

The present application provides a code merging method, apparatus, device, and storage medium. The method includes: when a code merging execution condition is met, obtaining identification information of the code to be merged; based on the identification information, obtaining software defect information and a target merging branch corresponding to the code to be merged; determining information to be verified for the code to be merged based on the identification information and the target merging branch; when it is determined that the information to be verified meets the merging condition corresponding to the target merging branch, merging the code to be merged into the target merging branch; and sending a verification notification message to a test terminal corresponding to the software defect information to notify the test terminal to verify the code to be merged. In this way, code merging can be automatically performed when the code merging condition is met, thereby improving merging efficiency.

Description

Technical Field

[0001] The present application relates to the field of computer science and technology, and in particular to a code incorporation method, apparatus, device, and storage medium. Background Art

[0002] During software development or updates, developers often need to update or add new code and merge the changed code into the repository. Currently, after a developer submits a merge request, the test manager often needs to communicate with the developer and testers multiple times to determine whether the changed code can be merged. This not only increases communication costs and prolongs the merge time, but also makes it easy for omissions to occur. Summary of the Invention

[0003] The embodiments of the present application provide a code merging method, device, and storage medium, which can automatically merge codes and improve the efficiency and accuracy of code merging.

[0004] The technical solution of the embodiment of the present application is implemented as follows:

[0005] The present invention provides a method for integrating code, including:

[0006] When the execution condition for code merging is met, the identification information of the code to be merged is obtained;

[0007] Based on the identification information, obtaining software defect information and a target merge branch corresponding to the code to be merged;

[0008] Determining information to be verified of the code to be merged based on the identification information and the target merge branch;

[0009] When it is determined that the information to be verified meets the merging condition corresponding to the target merging branch, the code to be merged is merged into the target merging branch;

[0010] A verification notification message is sent to the test terminal corresponding to the software defect information to notify the test terminal to verify the code to be merged.

[0011] In some embodiments, the method further comprises:

[0012] When the trunk branch verification result is verification passed, it is determined that the information to be verified meets the merging condition corresponding to the target merging branch.

[0013] In some embodiments, the method further comprises:

[0014] When the software defect information does not include the trunk and branch verification result, a second prompt message for trunk and branch verification is sent to the test terminal corresponding to the software defect information.

[0015] In some embodiments, the method further comprises:

[0016] When the trunk branch verification result is verification failure, a third prompt message is sent to the test terminal corresponding to the software defect information to prompt the test terminal to reopen the software defect information and notify the development terminal to repair the corresponding software defect.

[0017] The present embodiment provides a code integration device, including:

[0018] A first acquisition module is used to acquire identification information of the code to be merged when the execution condition of code merging is met;

[0019] A second acquisition module is configured to acquire software defect information and a target merge branch corresponding to the code to be merged based on the identification information;

[0020] A first determining module, configured to determine information to be verified of the code to be merged based on the identification information and the target merge branch;

[0021] A code merging module, configured to merge the code to be merged into the target merging branch when it is determined that the information to be verified meets the merging condition corresponding to the target merging branch;

[0022] The first sending module is configured to send a verification notification message to a test terminal corresponding to the software defect information, so as to notify the test terminal to verify the code to be merged.

[0023] In some embodiments, the code incorporation device further comprises:

[0024] The third acquisition module is used to obtain the current time;

[0025] The second determining module is configured to determine that the execution condition for code integration is met when the current moment reaches a preset code integration moment; or

[0026] The third determining module is configured to determine, when receiving a code merging request, whether or not a code merging execution condition has been met.

[0027] In some embodiments, the second acquisition module is further configured to:

[0028] Based on the identification information, determining whether the merge request corresponding to the code to be merged includes software defect information;

[0029] When the merge request includes software defect information, the software defect information in the merge request is obtained.

[0030] In some embodiments, the second acquisition module is further configured to:

[0031] When the merge request does not include software defect information, sending a first prompt message for obtaining software defect information to the development terminal;

[0032] Receive software defect information sent by the development terminal.

[0033] In some embodiments, the target merged branch includes at least a trunk branch and a release branch. Correspondingly, when the target merged branch is a trunk branch, the first determining module is further configured to:

[0034] Based on the identification information, determining whether a code check result of the code to be merged can be obtained;

[0035] When the code checking result can be obtained, the code checking result is determined as the information to be verified for the code to be incorporated.

[0036] In some embodiments, the code incorporation device further comprises:

[0037] The fourth determining module is configured to determine, when the code check result is passed, whether the information to be verified meets the merging condition corresponding to the target merging branch.

[0038] In some embodiments, when the target merge branch is a release branch, the first determining module is further configured to:

[0039] Determine whether the software defect information includes the trunk branch verification result;

[0040] When the software defect information includes a trunk and branch verification result, the trunk and branch verification result is determined as the information to be verified.

[0041] In some embodiments, the code incorporation device further comprises:

[0042] The fifth determining module is configured to determine, when the trunk branch verification result is verification passed, whether the information to be verified meets the merging condition corresponding to the target merging branch.

[0043] In some embodiments, the code incorporation device further comprises:

[0044] The second sending module is configured to send a second prompt message for trunk and branch verification to the test terminal corresponding to the software defect information when the software defect information does not include the trunk and branch verification result.

[0045] In some embodiments, the code incorporation device further comprises:

[0046] The third sending module is used to send a third prompt message to the test terminal corresponding to the software defect information when the trunk branch verification result is verification failure, so as to prompt the test terminal to reopen the software defect information and notify the development terminal to repair the corresponding software defect.

[0047] The present invention provides a code integration device, including:

[0048] a memory for storing executable instructions;

[0049] The processor is used to implement the method provided in the embodiment of the present application when executing the executable instructions stored in the memory.

[0050] An embodiment of the present application provides a computer-readable storage medium storing executable instructions for causing a processor to execute the method provided in the embodiment of the present application.

[0051] The embodiments of the present application have the following beneficial effects:

[0052] In the code merging method provided in the embodiment of the present application, when the execution conditions for code merging are met, the identification information of the code to be merged is first obtained, and based on the identification information, the software defect information and the target merging branch corresponding to the code to be merged are obtained; further based on the identification information and the target merging branch, the information to be verified of the code to be merged is determined, and the information to be verified is verified; when it is determined that the information to be verified meets the merging conditions corresponding to the target merging branch, the code to be merged is merged into the target merging branch; and a verification notification message is sent to the test terminal corresponding to the software defect information to notify the test terminal to verify the code to be merged. In this way, when the developer needs to merge the code, the corresponding information to be verified can be automatically obtained, and after the information to be verified meets the corresponding conditions, the code can be automatically merged into the corresponding branch, and the tester can be notified to verify. This can not only improve the efficiency of code merging, but also avoid missing software defects, thereby improving the accuracy of the software. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] Figure 1A Schematic diagram of the code integration process in related technologies

[0054] Figure 1B A schematic diagram of a network architecture of the code incorporation method according to an embodiment of the present application;

[0055] Figure 2 1 is a schematic diagram of the structure of the code integration terminal 100 provided in an embodiment of the present application;

[0056] Figure 3 A schematic diagram of an implementation flow of the code merging method provided in an embodiment of the present application;

[0057] Figure 4 A schematic diagram of another implementation flow of the code merging method provided in an embodiment of the present application;

[0058] Figure 5Schematic diagram of various interfaces involved in the embodiments of this application;

[0059] Figure 6 A schematic diagram of the interface for configuring the QCI file provided in an embodiment of the present application;

[0060] Figure 7 A schematic diagram of another implementation flow of the code merging method provided in an embodiment of the present application;

[0061] Figure 8 A schematic diagram of an interface provided in an embodiment of the present application that prompts testers to perform trunk merging verification;

[0062] Figure 9 A schematic diagram of an interface provided in an embodiment of the present application that prompts testers to perform release branch verification. DETAILED DESCRIPTION

[0063] In order to make the purpose, technical solutions and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limiting this application. All other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0064] In the following description, reference is made to “some embodiments”, which describes a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0065] In the following description, the terms "first\second\third" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0066] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application pertains. The terms used herein are for the purpose of describing the embodiments of this application only and are not intended to limit this application.

[0067] 1) Bug Ticket: A ticket created by testers to follow up on app experience or functional issues. Through this ticket, we can know who discovered the problem, who solved it, and screenshots and log information to help locate the problem.

[0068] 2) Code review refers to the systematic manual review of computer source code, usually conducted in the form of software peer review. Its purpose is to find and correct errors that were not discovered in the early stages of software development.

[0069] 3) Release branches are used to support branches in the development trunk that contain features planned for a release version.

[0070] In order to better understand the embodiments of the present application, the code incorporation method and existence determination in the related art are first explained.

[0071] Figure 1A This is a schematic diagram of the code integration process in related technologies, such as Figure 1A As shown, the process includes:

[0072] Step S001: The developer submits a merge order.

[0073] Step S002: The test leader confirms the merge order.

[0074] When implementing step S002, at least the test leader needs to communicate as shown in Figure 1:

[0075] Communication 1: If a developer forgets to attach a bug ticket link when submitting a merge, the test leader should contact the developer to attach the bug ticket link. Without the bug ticket link, the test leader will not know who will verify the merged ticket later.

[0076] Communication 2: For merge tickets with a bug ticket link attached, the test leader should first open the bug ticket to confirm which tester submitted the ticket, and then proactively inform the tester that the bug fix has been merged into the trunk or release branch, and ask the tester to verify it on the corresponding branch;

[0077] Communication 3: For merge orders to be merged into the release branch, the tester must first be notified that the trunk verification is OK. After the trunk verification is OK, the tester must immediately feedback the verification results to the test leader. The test leader will agree or reject the corresponding merge order based on the feedback results.

[0078] The main disadvantages of the code merging solution in related technologies include: first, the test leader has to communicate back and forth frequently on the same merge order, which affects the efficiency of both parties; second, it is easy for notifications to be delayed, resulting in the merge order being missed; third, manual operation is required, and from creating a new merge order to completing the merge order process, it takes the test leader 15 minutes or even more.

[0079] Based on this, an embodiment of the present application provides a code merging method, which can automatically detect the key information in the merge list after the developer submits the merge list. After the key information in the merge list meets the corresponding conditions, the interface is called and the code can be automatically merged into the corresponding branch.

[0080] The following describes exemplary applications of the apparatus for implementing the embodiments of the present application. The apparatus provided in the embodiments of the present application can be implemented as a terminal device. The following describes exemplary applications of the apparatus when implemented as a terminal device.

[0081] Figure 1B A network architecture diagram of the code integration method according to an embodiment of the present application is shown as follows: Figure 1B As shown, the network architecture includes: a code merging terminal 100, a development terminal 200, a network 300, and a test terminal 400. To support an exemplary application, the code merging terminal 100, the development terminal 200, and the test terminal 400 are respectively connected to each other via the network 300. When the development terminal 200 needs to merge code, it can send a merge request (i.e., a merge order) to the code merging terminal 100. After receiving the merge request, the code merging terminal 100 determines the target merge branch and the information to be verified. When the information to be verified meets the merge conditions, the code is automatically merged and a verification message is sent to the test terminal 400. After receiving the verification message, the test terminal 400 verifies the software defects corresponding to the code to be merged.

[0082] The apparatus provided in the embodiments of the present application may be implemented as hardware or a combination of hardware and software. Various exemplary implementations of the apparatus provided in the embodiments of the present application are described below.

[0083] according to Figure 2 The exemplary structure of the code-integrated terminal 100 shown is foreseeable, and other exemplary structures of the code-integrated terminal 100 can therefore be considered as limiting. For example, some components described below can be omitted, or components not described below can be added to meet the special needs of certain applications.

[0084] Figure 2 The code integration terminal 100 shown includes: at least one processor 110, a memory 140, at least one network interface 120, and a user interface 130. Each component in the code integration terminal 100 is coupled together via a bus system 150. It is understood that the bus system 150 is used to achieve connection and communication between these components. In addition to including a data bus, the bus system 150 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, the bus system 150 is not described in detail. Figure 2 Various buses are labeled as bus system 150 .

[0085] The user interface 130 may include a display, a keyboard, a mouse, a touch pad, a touch screen, and the like.

[0086] The memory 140 may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. The non-volatile memory may be a read-only memory (ROM). The volatile memory may be a random access memory (RAM). The memory 140 described in the embodiments of the present application is intended to include any suitable type of memory.

[0087] The memory 140 in the embodiment of the present application can store data to support the operation of the code integration terminal 100. Examples of such data include any computer program used to operate on the code integration terminal 100, such as an operating system and application programs. The operating system includes various system programs, such as a framework layer, a core library layer, and a driver layer, which are used to implement various basic services and handle hardware-based tasks. The application program can include various application programs.

[0088] As an example of the method provided in the embodiment of the present application being implemented by software, the method provided in the embodiment of the present application can be directly embodied as a combination of software modules executed by the processor 110. The software module can be located in a storage medium, and the storage medium is located in the memory 140. The processor 110 reads the executable instructions included in the software module in the memory 140, and combines with the necessary hardware (for example, including the processor 110 and other components connected to the bus 150) to complete the method provided in the embodiment of the present application.

[0089] As an example, the processor 110 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc., where the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0090] The game playing method provided in the embodiment of the present application will be described in combination with the exemplary application and implementation of the terminal provided in the embodiment of the present application.

[0091] See also Figure 3 , Figure 3 A schematic diagram of an implementation flow of the code merging method provided in an embodiment of the present application is applied to the code merging terminal shown in FIG1 , combined with Figure 3 The steps shown are explained.

[0092] Step S101: When the execution condition for code merging is met, identification information of the code to be merged is obtained.

[0093] Here, the execution condition may be pre-set, for example, it may be that a preset execution code merge time has been reached, or it may be that a preset execution event has been triggered. In an embodiment of the present application, when the execution condition for code merging is reached, the code merging terminal may have received one or more code merging requests. In actual implementation, the code merging request may be a merge order submitted by a developer, and the code merging request may carry identification information of the code to be merged. Furthermore, the identification information may include a first identification and a second identification, wherein the first identification may be the ID of the merge order, and the second identification may be the interface identification (IID, Interface Identifier) ​​of the merge order. The first identification may be determined by the corresponding link address of the merge order.

[0094] Of course, in some embodiments, when the execution conditions for code merging are met, the code merging request may not be received. In this case, the code to be merged and the identification information of the code to be merged cannot be obtained, and the process ends.

[0095] Step S102: Based on the identification information, obtain software defect information and a target merging branch corresponding to the code to be merged.

[0096] Here, when implementing step S102, the description information corresponding to the code to be merged can be obtained based on the IID of the merge order, and the description information may include software defect information (that is, the bug order link or bug order in other embodiments). Based on the ID of the merge order, the target merge branch can be determined, where the target merge branch can be a trunk branch or a release branch.

[0097] When the description information includes software defect information, the software defect information can be directly obtained. If the description information does not include software defect information, a first prompt message for obtaining software defect information can be sent to the development terminal to prompt the developer to upload the software defect information, or prompt the developer to upload a code merge request (i.e., a merge order) including the software defect information, and then obtain the software defect information based on the response returned by the developer.

[0098] Step S103: determining the information to be verified of the code to be merged based on the identification information and the target merge branch.

[0099] Here, for different merged branches, the information to be verified is different. For example, when the target merged branch is the trunk branch, the information to be verified is the code inspection result, where the code inspection result can also be in the description information of the merge order; when the target merged branch is the release branch, the information to be verified is the trunk verification result, where the trunk verification result can be in the comment information of the merge order.

[0100] Step S104: When it is determined that the information to be verified meets the merging condition corresponding to the target merging branch, the code to be merged is merged into the target merging branch.

[0101] Here, when the target merge branch is the trunk branch, the code inspection result is passed, and it is considered that the information to be verified meets the merging conditions. At this time, the code to be merged is merged into the target merge branch; when the target merge branch is the release branch, the trunk verification result is passed, and it is considered that the information to be verified meets the merging conditions. At this time, the code to be merged is merged into the target merge branch.

[0102] Step S105: Send a verification notification message to the test terminal corresponding to the software defect information to notify the test terminal to verify the code to be merged.

[0103] Here, based on the software defect information, it can be determined which tester tested the software defect information, and then a verification notification message is sent to the test terminal corresponding to the tester to prompt the tester to verify the code to be merged according to the software defect information to determine whether the code to be merged has overcome the corresponding software defect.

[0104] In the code merging method provided in the embodiment of the present application, when the execution conditions for code merging are met, the identification information of the code to be merged is first obtained, and based on the identification information, the software defect information and the target merging branch corresponding to the code to be merged are obtained; further based on the identification information and the target merging branch, the information to be verified of the code to be merged is determined, and the information to be verified is verified; when it is determined that the information to be verified meets the merging conditions corresponding to the target merging branch, the code to be merged is merged into the target merging branch; and a verification notification message is sent to the test terminal corresponding to the software defect information to notify the test terminal to verify the code to be merged. In this way, the code can be automatically merged into the corresponding branch, and the tester can be notified to perform verification, which not only improves the efficiency of code merging, but also avoids missing software defects, thereby improving the accuracy of the software.

[0105] In some embodiments, before step S101, it is necessary to determine whether the execution conditions for code integration are met. In actual implementation, there are at least two implementation methods to implement this determination process:

[0106] The first implementation method can be achieved through the following steps:

[0107] Step S011, obtaining the current time;

[0108] Step S012: determine whether the current time reaches the preset code integration time.

[0109] When the current time reaches the preset code integration time, it is determined that the execution condition for code integration is met.

[0110] The determination of whether the execution condition of code merging is met implemented through the above steps S011 to S012 is actually to perform a code merging operation once every certain time interval (ie, timing).

[0111] The second implementation manner is to determine whether a code merge request is received, wherein when the code merge request is received, it is determined that an execution condition for code merge is met.

[0112] In the second implementation, whenever a code merge request is received, it is considered that the execution condition for code merge is met, which can ensure that the code merge request can be responded to in a timely manner, further improving the efficiency of code merge.

[0113] In some embodiments, Figure 3 Step S102 shown can be implemented by the following steps:

[0114] Step S1021: Based on the identification information, determine whether the merge request corresponding to the code to be merged includes software defect information.

[0115] Here, the software defect information can be a bug ticket link or a bug ticket. When the merge request includes the software defect information, the process proceeds to step S1022; when the merge request does not include the software defect information, the process proceeds to step S1023.

[0116] Step S1022: Obtain software defect information carried in the merge request.

[0117] Step S1023: Send a first prompt message for obtaining software defect information to the development terminal.

[0118] Here, when implementing step S1023, the first prompt message may be a prompt message prompting the development terminal to resubmit the merge request including the software defect information. In this case, it is indicated that the developer cannot successfully submit the merge request without the software defect information, and can only successfully submit the merge request if the software defect information is included in the merge request. In some embodiments, the first prompt message may also be a prompt message prompting the development terminal to add the software defect information to the submitted merge request. Furthermore, the first prompt message is used to prompt the developer to add the software defect information to the comment information in the merge request.

[0119] Step S1024: Acquire software defect information sent by the development terminal.

[0120] Here, when implementing step S1024, the software defect information may be obtained through a merge request resubmitted by the development terminal, or the software defect information added by the development terminal in the comment information may be obtained.

[0121] In the embodiment of steps S1021 to S1024, when the merge request submitted by the development terminal does not include software defect information, the software defect information can be obtained by prompting the development terminal to resubmit the merge request or prompting the development terminal to add software defect information in the comment information. In this way, after the code is merged, the corresponding test terminal can be determined based on the software defect information, and a verification notification message can be sent to the test terminal without the need for human communication, thereby reducing communication time and improving work efficiency.

[0122] In some embodiments, the target merged branch includes at least a trunk branch and a release branch. Correspondingly, when the target merged branch is a trunk branch, Figure 3 The step S103 shown can be implemented by the following steps S1031a to S1032a:

[0123] Step S1031a: Based on the identification information, determine whether the code check result of the code to be merged can be obtained.

[0124] Here, when implementing step S1031a, the code check result can be obtained based on the second identifier, that is, the IID of the merge order. If the field corresponding to the code check result is not empty, it is considered that the code check result of the code to be merged can be obtained; if the field corresponding to the code check result is empty, it is considered that the code check result of the code to be merged cannot be obtained.

[0125] Step S1032a: When the code check result can be obtained, the code check result is determined as the information to be verified for the code to be incorporated.

[0126] Here, when implementing step S1032a, the field corresponding to the code detection result may be determined as the information to be verified for the code to be incorporated, wherein the field may indicate that the check has passed or failed.

[0127] Correspondingly, when the code check result is passed, it is determined that the information to be verified meets the merging conditions corresponding to the main branch, and step S104 is executed at this time; when the code check result is failed, it is determined that the information to be verified meets the merging conditions corresponding to the main branch, and the code merging terminal will return a response message of refusing merging to the development terminal, and the response message will carry the reason for refusing merging.

[0128] In some embodiments, when the code check result of the code to be merged cannot be obtained, it is considered that no code check has been performed on the code to be merged. At this time, it is considered that the information to be verified cannot be obtained, and the subsequent merging condition judgment process cannot be carried out. At this time, a response message of refusing merging can be returned to the development terminal, and the reason for refusing merging can be carried in the response message so that the development terminal can timely understand the merging progress and the reason for refusing merging.

[0129] In some embodiments, when the target merge branch is a release branch, Figure 3 The step S103 shown can be implemented by the following steps S1031b to S1032b:

[0130] Step S1031b: Determine whether the software defect information includes the trunk and branch verification results.

[0131] Step S1032b: When the software defect information includes a trunk and branch verification result, the trunk and branch verification result is determined as the information to be verified.

[0132] Correspondingly, when the trunk branch verification result is verification passed, it is determined that the information to be verified meets the merging conditions corresponding to the release branch, and step S104 is executed at this time; when the trunk branch verification result is verification failed, it is determined that the information to be verified meets the merging conditions corresponding to the non-release branch, and at this time the code merging terminal sends a third prompt message to the test terminal corresponding to the software defect information, prompting the test terminal to reopen the software defect information and notify the development terminal to fix the corresponding software defect. In some embodiments, the code merging terminal will return a response message to the development terminal rejecting the merging, and the response message carries the reason for rejecting the merging.

[0133] In some embodiments, when the software defect information does not include the trunk branch verification result, a second prompt message for trunk branch verification is sent to the test terminal corresponding to the software defect information. After receiving the second prompt message, the test terminal verifies the trunk branch and adds the trunk branch verification result to the software defect information so that the code can be merged again.

[0134] Based on the above embodiments, the present invention further provides a code merging method, which is applied to Figure 1B The network architecture shown, Figure 4 This is another implementation flow diagram of the code merging method of the embodiment of the present application, as shown in FIG. Figure 4 As shown, the process includes at least:

[0135] Step S401: After completing code development or update, the development terminal sends a code integration request to the code integration terminal.

[0136] Step S402: The code integration terminal determines whether the execution condition for code integration is met.

[0137] Here, when the execution condition for code merging is met, the process proceeds to step S403; when the execution condition for code merging is not met, the process ends.

[0138] In step S403, the code merging terminal obtains identification information of the code to be merged, and based on the identification information, obtains software defect information and a target merging branch corresponding to the code to be merged.

[0139] Step S404: The code merging terminal determines whether the target merging branch is a main branch.

[0140] Here, when the target merged branch is the trunk branch, proceed to step S405; when the target merged branch is the release branch, proceed to step S409.

[0141] Step S405: The code-integrating terminal determines whether the code check result of the code to be incorporated can be obtained based on the identification information.

[0142] Here, when the code check result can be obtained, step S406 is entered; when the code check result cannot be obtained, the code check terminal is notified to perform code check on the code to be merged (this step is in Figure 4 not shown).

[0143] Step S406: The code-integrating terminal determines the code checking result as the to-be-integrated code's to-be-integrated information.

[0144] Step S407: The code integration terminal determines whether the code check result is passed.

[0145] Here, when the code check result is passed, it is determined that the information to be verified meets the merging conditions corresponding to the main branch, and step S412 is entered; when the code check result is failed, it is determined that the information to be verified does not meet the merging conditions corresponding to the main branch, and step S408 is entered.

[0146] Step S408: The code merging terminal sends a response message rejecting the merging to the development terminal.

[0147] Step S409: The code merging terminal determines whether the software defect information includes a trunk branch verification result;

[0148] Here, when the software defect information includes the trunk and branch verification results, the process proceeds to step S410; when the software defect information does not include the trunk and branch verification results, the process proceeds to step S417.

[0149] Step S410: The code-integrating terminal determines the trunk and branch verification results as the information to be verified.

[0150] Step S411: The code merging terminal determines whether the trunk and branch verification results are verified to be passed.

[0151] Here, when the trunk branch verification result is verification passed, it is determined that the information to be verified meets the corresponding merging conditions of the trunk branch, and step S412 is entered; when the trunk branch verification result is verification failed, it is determined that the information to be verified meets the corresponding merging conditions of the trunk branch, and step S414 is entered.

[0152] Step S412: The code merging terminal merges the code to be merged into the target merging branch.

[0153] Step S413: The code merging terminal sends a verification notification message to the test terminal corresponding to the software defect information, so as to notify the test terminal to verify the code to be merged.

[0154] Step S414: the code merging terminal sends a third prompt message to the test terminal corresponding to the software defect information, prompting the test terminal to reopen the software defect information and notify the development terminal to repair the corresponding software defect.

[0155] Step S415: The test terminal changes the status of the software defect information to open based on the third prompt message.

[0156] Step S416: The test terminal sends the software defect information to the development terminal.

[0157] Here, after receiving the software defect information sent by the test terminal, the development terminal updates the code based on the software defect information to overcome the corresponding software defect.

[0158] Step S417: The code merging terminal sends a second prompt message for trunk and branch verification to the test terminal corresponding to the software defect information.

[0159] Step S418: The test terminal performs trunk and branch verification based on the second prompt message.

[0160] Here, after verifying the trunk branch, the test terminal adds the trunk branch verification result to the comment information in the merge list and notifies the code merging terminal. At this time, the code merging terminal enters step S411 again and performs subsequent steps to complete the code merging.

[0161] In the code merging method provided in the embodiment of the present application, after the development terminal submits a merging request, when the execution condition of the code merging is met, the code merging terminal first obtains the identification information of the code to be merged, and based on the identification information, obtains the software defect information and the target merging branch corresponding to the code to be merged; further determines the to-be-merged verification information of the code to be merged based on the identification information and the target merging branch, and verifies the to-be-merged verification information; when it is determined that the to-be-merged verification information meets the merging condition corresponding to the target merging branch, merges the code to be merged into the target merging branch; and sends a report to the test terminal corresponding to the software defect information. The terminal sends a verification notification message to notify the test terminal to verify the code to be merged. In this way, the code can be automatically merged into the corresponding branch and the tester can be notified to verify it. This not only improves the efficiency of code merging, but also avoids missing software defects, thereby improving the accuracy of the software; and when the information to be verified does not meet the merging conditions, it can automatically send a corresponding prompt message to the test terminal or development terminal to notify the tester or developer to verify or update the code based on the prompt information. This can reduce the cost of manual communication, realize the automatic transmission of messages, and avoid omissions and delays in code merging progress.

[0162] The following describes an exemplary application of the embodiments of the present application in a practical application scenario.

[0163] First, combine Figure 5 The various interfaces involved in the embodiments of this application are described as follows: Figure 5 As shown, the interfaces involved in the embodiment of the present application include: A interface 501, B interface 502, C interface 503, D interface 504, E interface 505, and F interface 506, wherein:

[0164] Interface A 501 is used to check whether there is a merge order under the corresponding business. If there is a merge order, a list of each merge order information is returned. The list elements are composed of dictionaries, through which the ID and IID of the corresponding merge order can be queried. If there is no merge order, an empty list is returned.

[0165] Interface B 502 is used to query whether the corresponding merge order code review has been completed based on the IID obtained from interface A. If the code review is completed, the value of "review_state" is "approved". In addition, the description field shows whether the developer has filed a bug ticket.

[0166] C interface 503 is used to check whether there are any subsequent comments on the merge order. If the developer does not attach a bug ticket when submitting the merge order, there will be no bug ticket information in the description field. You can then request the developer to add a bug ticket link in the comment. In this case, the bug ticket link can only be obtained through the C interface;

[0167] D interface 504 is a merge order page access link that can be used to view specific merge order information. Simply put, the content displayed by accessing D interface is a comprehensive display of the content returned by B interface and C interface.

[0168] E interface 505 is used to merge the merge order, which can successfully merge the code modification into the corresponding branch;

[0169] Interface F 506 is used to obtain the information of the biller corresponding to the bug ticket after obtaining the bug ticket link through interface B or interface C.

[0170] After obtaining the above interface information, analyze the overall process, generate a script tool, configure the script tool on the company's QCI integration platform, and then run it regularly without manual operation. Figure 6 As shown, put the execution code of the script tool into the code library, then fill in the code library link and configure the QCI File. In the QCI file, you can Figure 6 The code shown in 601 specifies the installation of the corresponding library file, and then the code shown in 602 executes the corresponding script, so that the entire project task runs regularly every hour. In this way, all operations rely on the platform, truly realizing the automation of code integration and message reminders.

[0171] Figure 7 A schematic diagram of another implementation flow of the code merging method provided in the embodiment of the present application is shown as follows: Figure 7 As shown, the implementation process includes:

[0172] Step S701: The developer submits a merge order.

[0173] Here, when the developer submits the merge order, interface A can detect it, and then interface A will return a list of IDs and IIDs of all merge orders.

[0174] Step S702: Determine whether a bug ticket is attached to the merge ticket.

[0175] Here, when implementing step S702, the ID and IID lists are traversed in a loop, and whether the corresponding merge order contains bug ticket information is determined based on interfaces B and C. If there is no bug ticket information in the merge order, step S703 is entered, and a message is sent to notify the person who submitted the merge order to comment and add a bug ticket link; if there is a bug ticket information message in the merge order, step S705 is entered to determine whether the merge order is merged into the trunk or the release branch.

[0176] Step S703: A message is sent to remind the developer that the bug ticket needs to be attached to the merge ticket.

[0177] Here, when implementing step S703, a D interface link can be attached to the content of the reminder message. In actual implementation, the message reminder can be achieved by calling the enterprise WeChat interface, and the information of the person who submitted the merge order can be obtained through the B interface.

[0178] Step S704: After receiving the reminder message, the developer clicks the merge application link in the reminder message and attaches a bug ticket.

[0179] Here, after step S704, the process proceeds to step S702.

[0180] Step S705: determine whether the merge order is to be merged into the trunk or the release branch.

[0181] Here, if the merge order is to merge into the trunk, go to step S706 and determine whether the code review is completed through the codereview field obtained through interface B; if the merge order is to release the branch, go to step S709.

[0182] Step S706: Determine whether the code check is passed.

[0183] Here, if the code check has been passed, proceed to step S707.

[0184] Step S707: Call the platform interface to directly merge and notify the bug ticket’s order person to perform trunk verification.

[0185] Here, when step S707 is implemented, the E interface is directly called to merge and the tester is notified to verify the merge order based on the tester information obtained by the F interface. Figure 8 A schematic diagram of an interface for prompting testers to perform trunk integration verification provided in an embodiment of the present application, such as Figure 8As shown in 801, the prompt interface includes questions to be verified and a bug single link.

[0186] In actual implementation, the platform here can be a worker bee platform, that is, a code hosting platform. Developers submit code changes by submitting merge orders on the code hosting platform. The merge order contains some modification information of the merge, such as a bug ticket link, to facilitate verification by testers.

[0187] Step S708: After the backbone verification is completed, the process ends.

[0188] Step S709: Determine whether there is a "Verification OK" field in the bug ticket comment.

[0189] Here, if there is a "Verification OK" field in the bug ticket comment, go to step S710. In the embodiment of the present application, there is no "Verification OK" field in the bug ticket comment in the following two cases: the first is that the merge order has not yet been verified as a trunk, then go to step S712, and the message notifies the tester to return the trunk to the merge order; and the tester performs trunk verification, and the verification passes, and then adds "Verification OK" to the bug ticket comment and then returns to step S709; the second is that the trunk verification of the merge order fails, then the tester needs to reopen the bug ticket, and then the developer re-modifies the code, solves the bug, and finally resubmits a new merge order, and the test leader refuses to merge the abnormal merge order this time.

[0190] Step S710: Call the platform interface to merge directly, and notify the person who filed the bug ticket to verify the release branch.

[0191] Here, during implementation, you can directly merge by calling the E interface and notify the bill of lading holder to verify the merge order based on the bill of lading holder information obtained from the F interface. Figure 9 A schematic diagram of an interface for prompting testers to perform release branch verification provided in an embodiment of the present application, such as Figure 9 As shown in 901, the prompt interface includes questions to be verified and a bug single link.

[0192] Step S711: Release branch verification is completed and the process ends.

[0193] Step S712: The message reminds the person who filed the bug ticket to perform trunk verification.

[0194] Here, after step S712, the process proceeds to step S709.

[0195] In some embodiments, to improve code merging efficiency, a mandatory binding constraint to a bug ticket can be added when submitting a merge ticket. This means that if a developer doesn't attach a bug ticket, the merge ticket cannot be submitted for merging. Furthermore, upon detecting a new merge ticket submission, the automatic code merge process can be triggered immediately, further improving code merging efficiency.

[0196] In the code merging method provided in the embodiment of the present application, the test leader does not need to repeatedly communicate with the developer who submitted the merge order and the tester who verified the merge order, which can improve efficiency and reduce the manpower of the test leader; after the developer submits the correct merge order, there is no need to pay attention to the status of the merge order at all times, and there is no need to worry about no one verifying the merge order, thereby avoiding missed tests. In addition, as long as there is a submission that does not comply with the specifications and a code merging conflict, there will be an immediate message reminder, thereby realizing the convenience of message notification.

[0197] The following continues to describe the exemplary structure of the code integration device 80 provided in the embodiment of the present application as a software module. In some embodiments, such as Figure 2 As shown, the software modules stored in the code incorporating device 80 in the memory 140 may include:

[0198] A first acquisition module 81 is configured to acquire identification information of the code to be merged when the execution condition for code merging is met;

[0199] A second acquisition module 82 is configured to acquire software defect information and a target merge branch corresponding to the code to be merged based on the identification information;

[0200] A first determining module 83 is configured to determine information to be verified of the code to be merged based on the identification information and the target merge branch;

[0201] A code merging module 84 is configured to merge the code to be merged into the target merging branch when it is determined that the information to be verified meets the merging condition corresponding to the target merging branch;

[0202] The first sending module 85 is configured to send a verification notification message to the test terminal corresponding to the software defect information, so as to notify the test terminal to verify the code to be merged.

[0203] In some embodiments, the code incorporation device further comprises:

[0204] The third acquisition module is used to obtain the current time;

[0205] The second determining module is configured to determine that the execution condition for code integration is met when the current moment reaches a preset code integration moment; or

[0206] The third determining module is configured to determine, when receiving a code merging request, whether or not a code merging execution condition has been met.

[0207] In some embodiments, the second acquisition module is further configured to:

[0208] Based on the identification information, determining whether the merge request corresponding to the code to be merged includes software defect information;

[0209] When the merge request includes software defect information, the software defect information in the merge request is obtained.

[0210] In some embodiments, the second acquisition module is further configured to:

[0211] When the merge request does not include software defect information, sending a first prompt message for obtaining software defect information to the development terminal;

[0212] Receive software defect information sent by the development terminal.

[0213] In some embodiments, the target merged branch includes at least a trunk branch and a release branch. Correspondingly, when the target merged branch is a trunk branch, the first determining module is further configured to:

[0214] Based on the identification information, determining whether a code check result of the code to be merged can be obtained;

[0215] When the code checking result can be obtained, the code checking result is determined as the information to be verified for the code to be incorporated.

[0216] In some embodiments, the code incorporation device further comprises:

[0217] The fourth determining module is configured to determine, when the code check result is passed, whether the information to be verified meets the merging condition corresponding to the target merging branch.

[0218] In some embodiments, when the target merge branch is a release branch, the first determining module is further configured to:

[0219] Determine whether the software defect information includes the trunk branch verification result;

[0220] When the software defect information includes a trunk and branch verification result, the trunk and branch verification result is determined as the information to be verified.

[0221] In some embodiments, the code incorporation device further comprises:

[0222] The fifth determining module is configured to determine, when the trunk branch verification result is verification passed, whether the information to be verified meets the merging condition corresponding to the target merging branch.

[0223] In some embodiments, the code incorporation device further comprises:

[0224] The second sending module is configured to send a second prompt message for trunk and branch verification to the test terminal corresponding to the software defect information when the software defect information does not include the trunk and branch verification result.

[0225] In some embodiments, the code incorporation device further comprises:

[0226] The third sending module is used to send a third prompt message to the test terminal corresponding to the software defect information when the trunk branch verification result is verification failure, so as to prompt the test terminal to reopen the software defect information and notify the development terminal to repair the corresponding software defect.

[0227] The embodiment of the present application provides a storage medium storing executable instructions, wherein the executable instructions are stored. When the executable instructions are executed by a processor, the processor will execute the method provided by the embodiment of the present application, for example, Figure 3 、 Figure 4 and Figure 5 The method shown.

[0228] In some embodiments, the storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or various devices including one or any combination of the above memories.

[0229] In some embodiments, executable instructions may be in the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0230] As an example, executable instructions may, but need not, correspond to a file in a file system, may be stored as part of a file that stores other programs or data, such as in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple coordinating files (e.g., files storing one or more modules, subroutines, or code portions).

[0231] By way of example, executable instructions may be deployed to be executed on one computing device, or on multiple computing devices at one site, or on multiple computing devices distributed across multiple sites and interconnected by a communication network.

[0232] The above description is merely an embodiment of the present application and is not intended to limit the scope of protection of the present application. Any modifications, equivalent replacements, and improvements made within the spirit and scope of the present application are included in the scope of protection of the present application.

Claims

1. A code incorporation method, characterized in that: include: When the execution condition for code merging is met, the identification information of the code to be merged is obtained; Based on the identification information, obtaining software defect information and a target merge branch corresponding to the code to be merged; When the target merge branch is a main branch, determining whether a code check result of the code to be merged can be obtained based on the identification information; when the code check result can be obtained, if the code check result is a pass, determining that the code check result meets the merging condition corresponding to the main branch, and merging the code to be merged into the main branch; When the code check result is a check failure, determining that the code check result does not meet the merging condition corresponding to the trunk branch, returning a response message of refusing the merging to the development terminal, the response message carrying the reason for refusing the merging; When the target merged branch is a release branch, determining whether the software defect information includes a trunk branch verification result; when the software defect information includes the trunk branch verification result, if the trunk branch verification result is verified passed, determining that the trunk branch verification result meets the merge condition corresponding to the release branch, and merging the code to be merged into the release branch; When the trunk branch verification result is verification failure, determining that the trunk branch verification result does not meet the merging condition corresponding to the release branch, sending a third prompt message to the test terminal corresponding to the software defect information to prompt the test terminal to reopen the software defect information and notify the development terminal to repair the corresponding software defect; A verification notification message is sent to a test terminal corresponding to the software defect information to notify the test terminal to verify the code to be merged.

2. The method according to claim 1, wherein The method further comprises: Get the current time; When the current time reaches the preset code integration time, it is determined that the execution condition of code integration is met; or, When a code merge request is received, it is determined that an execution condition for the code merge is met.

3. The method according to claim 1, wherein The acquiring, based on the identification information, software defect information corresponding to the code to be merged includes: Based on the identification information, determining whether the merge request corresponding to the code to be merged includes software defect information; When the merge request includes software defect information, the software defect information in the merge request is obtained.

4. The method according to claim 3, wherein The acquiring, based on the identification information, software defect information corresponding to the code to be merged includes: When the merge request does not include software defect information, sending a first prompt message for obtaining software defect information to the development terminal; Receive software defect information sent by the development terminal.

5. A code incorporation device, characterized in that: The device comprises: A first acquisition module is used to acquire identification information of the code to be merged when the execution condition of code merging is met; A second acquisition module is configured to acquire software defect information and a target merge branch corresponding to the code to be merged based on the identification information; A first determining module is configured to determine, when the target merged branch is a trunk branch, whether a code check result of the code to be merged can be obtained based on the identification information; A code merging module is configured to, when the code check result is obtained, determine that the code check result satisfies the merging condition corresponding to the main branch if the code check result is a pass, and merge the code to be merged into the main branch; and when the code check result is a fail, determine that the code check result does not satisfy the merging condition corresponding to the main branch, and return a response message of refusing merging to the development terminal, wherein the response message carries the reason for refusing merging; The first determining module is further configured to determine whether the software defect information includes a trunk branch verification result when the target merged branch is a release branch; The code merging module is further configured to, when the software defect information includes the main branch verification result, determine that the main branch verification result meets the merging condition corresponding to the release branch if the main branch verification result is a passed verification, and merge the to-be-merged code into the release branch; when the main branch verification result is a failed verification, determine that the main branch verification result does not meet the merging condition corresponding to the release branch, send a third prompt message to the test terminal corresponding to the software defect information, so as to prompt the test terminal to reopen the software defect information, and notify the development terminal to repair the corresponding software defect; The first sending module is configured to send a verification notification message to the tested terminal, so as to notify the tested terminal to verify the code to be incorporated.

6. The device according to claim 5, characterized in that The device further comprises: The third acquisition module is used to obtain the current time; The second determining module is configured to determine that the execution condition for code integration is met when the current moment reaches a preset code integration moment; or The third determining module is configured to determine, when receiving a code merging request, whether or not a code merging execution condition has been met.

7. The device according to claim 5, characterized in that The second acquisition module is further configured to: Based on the identification information, determining whether the merge request corresponding to the code to be merged includes software defect information; When the merge request includes software defect information, the software defect information in the merge request is obtained.

8. The device according to claim 7, characterized in that The second acquisition module is further configured to: When the merge request does not include software defect information, sending a first prompt message for obtaining software defect information to the development terminal; Receive software defect information sent by the development terminal.

9. A code incorporation device, characterized in that: include: a memory for storing executable instructions; A processor, configured to implement the method according to any one of claims 1 to 4 when executing the executable instructions stored in the memory.

10. A computer-readable storage medium, characterized in that Executable instructions are stored, which are used to cause a processor to execute and implement the method according to any one of claims 1 to 4.

Images