Apparatus and method for automating pull request merging

Abstract

This invention discloses an apparatus and method for automating pull request merging. One embodiment of the automated pull request merging method may include the following steps: receiving a first pull request corresponding to code changes in a first branch; verifying whether the first pull request meets preset state conditions based on information included in the first pull request; and, if the first pull request meets the state conditions, merging the code changes corresponding to the first pull request into a base branch according to a preset merging method.

Description

[Technical Field]

[0001] This invention relates to an electronic device and method for automating the process of merging pull requests to reflect code changes. [Previous Technology]

[0002] Continuous Integration (CI) and Continuous Deployment (CD) are concepts required to improve development efficiency, maintain code quality, and provide users with faster and more stable services. In particular, in large-scale projects, developers can frequently integrate their respective workpieces to identify and resolve code conflicts or errors early on. Under a well-built CI / CD pipeline, feedback on code changes can be obtained quickly, thereby improving productivity. Furthermore, new features or fixes can be released quickly and securely, shortening release cycles and enabling faster delivery of user experience to customers.

[0003] That is, if a proper CI / CD environment is available, it can not only improve the efficiency and stability of teamwork, but also improve the quality of products and quickly receive customer feedback, thereby promoting business growth.

[0004] However, CI / CD previously relied on manual operation, which resulted in inefficiency while consuming a large amount of labor. For example, there were inconveniences such as: in the CD workflow, when implementing the process to manage pull requests, people needed to personally manage the PR merging process, manually trigger and release builds, etc.

[0005] In this regard, see previous documents such as KR2016-0000761A. [Summary of the Invention]

[0006] [Problem to be solved by the invention] The present invention is proposed to solve the above-mentioned problem. Considering the status conditions of the pull request, it is intended to automatically determine whether to merge the code change items corresponding to the pull request into other branches.

[0007] Furthermore, the present invention was proposed to solve the above-mentioned problems, and aims to propose a solution to automatically merge code changes accumulated based on multiple pull requests into other branches.

[0008] The technical problem to be solved by this invention is not limited to the technical problem described above; other technical problems can be deduced from the following embodiments. [Technical Means for Solving the Problem]

[0009] According to the present invention, an automated pull request merging method implemented by an electronic device may include the following steps: receiving a first pull request corresponding to a code change item of a first branch; verifying whether the first pull request meets a preset state condition based on information included in the first pull request; and merging the code change item corresponding to the first pull request to the base branch according to a preset merging method when the first pull request meets the above state condition.

[0010] In one embodiment, the first pull request may include the name of the repository that generated the first branch, the identifier of the first pull request, the identifier of the base branch, the user requesting the merge, and at least a portion of the information of the merge method.

[0011] In one embodiment, the above-mentioned state conditions may include at least one of the following: whether the parity check passes or not, whether the unit test passes or not, whether a conflict occurs in the above-mentioned baseline branch, and whether the sign-off check passes or not.

[0012] In one embodiment, the above verification steps may include the following steps: using the API (Application Programming Interface) of the service platform to report the information included in the first pull request and the above status conditions to the service platform, the service platform being the custodian of the repository that supports the generation of the first branch; and receiving status attribute values ​​related to whether or not the above code change can be merged, the status attribute values ​​being returned from the service platform.

[0013] In one embodiment, the above merging method may be any of the following: fast-forward merging, recursive merging, squash merging, and rebase merging.

[0014] In one embodiment, the base branch and the main branch exist separately, and the above-mentioned automated pull request merging method may further include the following steps: confirming whether the release preparation of the code changes accumulated in the base branch is complete; when the release preparation of the accumulated code changes is complete, generating a release tag in the base branch; and before the release tag is marked, merging the code changes accumulated in the base branch into the main branch. Specifically, the step of confirming whether the release preparation is complete may include the following steps: pre-releasing the code changes accumulated in the base branch to a portion of the user terminals among the plurality of user terminals that use the main branch for operation; and if no problems arise in the portion of user terminals due to the code changes accumulated in the base branch within a preset period, it is determined that the release preparation is complete.

[0015] In one embodiment, the above-mentioned automated pull request merging method may further include the following steps: when the first pull request does not meet the above-mentioned state conditions, classify the first pull request as an unmergeable state and exclude it from the merge waiting list; based on the information included in the second pull request, verify whether the second pull request meets the above-mentioned state conditions, wherein the second pull request belongs to the merge waiting list in the order of the first pull request; and when the second pull request meets the above-mentioned state conditions, merge the code change items corresponding to the second pull request into the base branch according to a preset merging method.

[0016] In one embodiment, the above-described automated pull request merging method may further include the following steps: storing record data related to the merging of code change items in a database associated with the electronic device, wherein the code change item targets the aforementioned baseline branch. Relatedly, the record data may include at least a portion of whether the merging of the code change item was successful, the reason for failure when the merging of the code change item failed, and the name of the database that generated the aforementioned first branch.

[0017] On the other hand, related to the above embodiments, the above-described automated pull request merging method may further include the following step: transmitting a notification related to the above-described record data to a user terminal associated with the above-described electronic device. Alternatively, the above-described automated pull request merging method may further include the following step: based on the above-described record data, providing a dashboard including at least a portion of the analysis content, optimization scheme, and conflict resolution scheme of the above-described code change matters to the user terminal associated with the above-described electronic device.

[0018] According to the present invention, an electronic device for automating the merging of pull requests may include a memory storing commands and a processor, wherein the processor is connected to the memory to receive a first pull request corresponding to a code change item of a first branch; verifies whether the first pull request meets a preset state condition based on information included in the first pull request; and when the first pull request meets the state condition, merges the code change item corresponding to the first pull request into the base branch according to a preset merging method.

[0019] Specific details of other embodiments are included in the detailed description and drawings. [Effects of the Invention]

[0020] According to the present invention, when determining whether to merge the code change item corresponding to the pull request into the base branch, it is verified whether the pull request meets the preset state conditions. This can help reduce the labor required to manage the pull request and improve the accuracy and quality of the product during the continuous integration and release process.

[0021] Furthermore, according to the present invention, under fixed conditions, code changes accumulated in the base branch are automatically merged into the main branch by means of an electronic device, thereby reducing the resources required to process multiple pull requests in the CI / CD workflow.

[0022] The effects of the invention are not limited to those mentioned above. Those skilled in the art can clearly understand other effects not mentioned based on the description in the scope of the invention application.

Implementation Method

[0024] Hereinafter, specific embodiments will be described with reference to the drawings. The following detailed description is provided to aid in a comprehensive understanding of the methods, apparatus and / or systems described in this specification. However, it is merely an example, and the disclosed embodiments are not limited thereto.

[0025] When describing embodiments, detailed descriptions of relevant well-known descriptions are omitted if it is determined that such detailed descriptions may unnecessarily obscure the essence of the disclosed embodiments. Furthermore, the terminology used below is defined in consideration of the functionality in the disclosed embodiments, and such terminology may vary depending on the intentions or practices of users, operators, etc. Therefore, its definition should be based on the overall content of this specification. The terminology used in the detailed description is only for describing embodiments and should not be limited. Unless explicitly used otherwise, the singular form includes the meaning of the plural form. In this description, expressions such as "comprising" or "possessing" are used to refer to a portion or combination of certain features, numbers, steps, actions, elements, etc., and should not be construed as excluding the presence or possibility of one or more other features, numbers, steps, actions, elements, etc., besides those described.

[0026] The terminology used in the embodiments is selected with consideration for the functions of this invention, and generally widely used terms are chosen as much as possible. However, it may vary depending on the intentions or precedents of those skilled in the art, the emergence of new technologies, etc. Furthermore, in certain situations, there may be terms arbitrarily selected by the applicant. In such cases, their meanings will be described in detail in the corresponding description section. Therefore, the terminology used in this invention should be defined based on the meaning of the term and the entire content of this invention, and not simply based on the name of the term.

[0027] Throughout this specification, when a part is described as "including" a certain component, it means that other components may be included unless otherwise specified, and not that other components are excluded. Furthermore, terms such as "...part" and "...module" used in the specification refer to a unit that processes at least one function or action, which can be implemented by hardware or software, or by a combination of hardware and software. Unlike the examples shown, specific actions may not be explicitly distinguished.

[0028] The expression “at least one of a, b and c” as recorded throughout the specification may include “a alone”, “b alone”, “c alone”, “a and b”, “a and c”, “b and c”, or “a, b and c”.

[0029] The "terminal" mentioned below can be a computer or a portable terminal that can connect to a server or other terminal via a network. Here, a computer includes, for example, a laptop computer, a desktop computer, or a laptop computer equipped with a web browser. A portable terminal is a wireless communication device that ensures portability and mobility, and may include, for example, IMT (International Mobile Telecommunication), CDMA (Code Division Multiple Access), W-CDMA (W-Code Division Multiple Access), LTE (Long Term Evolution) and other communication terminals, as well as all types of handheld wireless communication devices such as smartphones and tablets.

[0030] In the following description, the terms “transmission”, “communication”, “send”, “receive” and other terms with similar meanings for signals or information include not only the direct transmission of signals or information from one component to another, but also the transmission of signals or information to another component through other components.

[0031] In particular, "transmitting" or "sending" a signal or information to a constituent element means indicating the final destination of the signal or information, and not the direct destination. The same applies when "receiving" a signal or information. Furthermore, in this specification, "related" two or more pieces of data or information means that if one piece of data (or information) is obtained, at least a portion of the other data (or information) can be obtained based on it.

[0032] Furthermore, terms such as 1 and 2 can be used to describe various constituent elements, but the constituent elements mentioned above should not be limited to the terms mentioned above. The terms mentioned above are used for the purpose of distinguishing one constituent element from other constituent elements.

[0033] For example, without departing from the scope of the present invention, the first constituent element may be named the second constituent element, and similarly, the second constituent element may be named the first constituent element.

[0034] In describing the embodiments, descriptions of technical content well-known in the technical field to which this invention pertains and not directly related to this invention are omitted. The reason for this is that by omitting redundant descriptions, the main idea of ​​this invention is clearly conveyed, thereby avoiding confusion regarding the main idea of ​​this invention.

[0035] For the same reason, some constituent elements are exaggerated, omitted, or approximated in the accompanying drawings. Furthermore, the dimensions of each constituent element do not fully reflect the actual dimensions. In each drawing, the same or corresponding constituent elements are assigned the same reference number.

[0036] The advantages and features of the present invention, as well as the methods for achieving such advantages and features, will become clear upon reference to the accompanying drawings and the embodiments described in detail below. However, the present invention is not limited to the embodiments disclosed below and can be implemented in various different forms. These embodiments are provided only to fully disclose the present invention and to enable those skilled in the art to fully understand the scope of the invention. The present invention is defined solely by technical solutions. Throughout this specification, the same reference numerals refer to the same constituent elements.

[0037] It is understood that the combination of blocks in a flowchart and the flowchart itself can be executed by computer program instructions. These computer program instructions can be loaded onto the processor of a general-purpose computer, a special-purpose computer, or other programmable data processing equipment. Therefore, these instructions, executed by the processor of the computer or other programmable data processing equipment, produce methods for performing the functions described in the blocks of the flowchart. To implement the functions in a specific manner, these computer program instructions can be stored in computer-usable or computer-readable memory that is oriented towards a computer or other programmable data processing equipment. Therefore, the instructions stored in the computer-usable or computer-readable memory can also produce an article of manufacture containing instruction methods that perform the functions described in the blocks of the flowchart. The computer program instructions can also be loaded onto a computer or other programmable data processing equipment. Therefore, a series of action steps are performed on the computer or other programmable data processing equipment to produce a flow executed by the computer. Thus, the instructions executed by the computer or other programmable data processing equipment can also provide steps for performing the functions described in the blocks of the flowchart.

[0038] Furthermore, each block may represent a module, segment, or portion of code comprising one or more executable instructions for performing a specific logical function. It should also be noted that in some alternative execution examples, the functions mentioned in the blocks may be executed out of order. For example, two blocks illustrated successively may be executed simultaneously, or occasionally in reverse order depending on their corresponding functions.

[0039] Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings so that those skilled in the art can easily implement the invention. However, the present invention can be implemented in many different forms and is not limited to the embodiments described herein. The methods shown in FIG2 and FIG3 can be implemented, for example, by means of the electronic device 110 described with reference to FIG9. In the present invention, the electronic device 110 serves as an exemplary device for managing platform data. This device may be a single device, but according to embodiments, it may also be a system comprising a plurality of detailed devices that communicate with each other via wired or wireless networks.

[0040] Figure 1 is a diagram illustrating an embodiment of a system for automating the merging of pull requests.

[0041] Referring to FIG1, the system may include an electronic device 110, a user terminal 120, and a network 130. The system shown in FIG1 only illustrates the components relevant to this embodiment. Therefore, those skilled in the art related to this embodiment will understand that, in addition to the components shown in FIG1, other general components may be included.

[0042] Electronic device 110 is an apparatus for providing a workflow environment for continuous integration and continuous deployment for user terminals 120 connected via network 130. More specifically, electronic device 110 may be an apparatus that receives requests related to application code (e.g., build requests, Kermit protocol requests, branch creation requests, etc.) from user terminals 120, determines whether to allow the requests from user terminals 120, and performs subsequent operations based on the determination result.

[0043] The repository corresponding to the account of electronic device 110 may refer to a separate repository associated with the repository corresponding to the account of user terminal 120. In this invention, "repository" refers to the space for storing files, folders, and change history (Kermit protocol) of a storage plan. For example, the repository corresponding to the account of user terminal 120 may refer to the local repository existing in user terminal 120, and the repository corresponding to the account of electronic device 110 may refer to a remote repository for pushing or pulling changes in the local repository for cooperation between user terminals. On the other hand, the repository account is an account assigned in the service platform that supports the hosting of the repository. It can access the repository or create or manage the repository through the corresponding account. Each account can set its own access permissions for the repository and manage the repository in a public or private state to third parties.

[0044] Electronic device 110 and user terminal 120 can be electronically connected via network 130 to achieve communication between them. Network 130 includes Local Area Network (LAN), Wide Area Network (WAN), Value Added Network (VAN), Mobile Radio Communication Network, Satellite Communication Network, and combinations thereof. This network is a comprehensive data communication network that enables the constituent entities of the systems shown in FIG1 to communicate smoothly with each other, and may include wired Internet, wireless Internet, and mobile wireless communication network. Furthermore, the network described here may be a separate network distinct from the blockchain network. Wireless communication used in the network may include, but is not limited to, Wi-Fi, Bluetooth, Bluetooth Low Energy, Wi-Fi Direct (WFD), UWB (ultra-wideband), IrDA (infrared data association), and NFC (near field communication).

[0045] On the other hand, in Figure 1, user terminal 120 is represented by an odd number, but this is only for ease of explanation and may also include additional user terminals participating in the workflow for continuous integration and continuous release. Furthermore, some of the communication implemented between the plurality of user terminals may also be implemented without going through network 130, via peer-to-peer (P2P) communication.

[0046] Figure 2 is a flowchart illustrating an embodiment of an automated method for merging pull requests.

[0047] In step S210, the electronic device 110 may receive a first pull request corresponding to the code change of the first branch.

[0048] In step S220, the electronic device 110 can verify whether the first pull request meets the preset state conditions based on the information included in the first pull request.

[0049] According to one embodiment, the first pull request may include information such as the name of the repository that generated the first branch, an identifier of the first pull request, an identifier of the base branch, the user requesting the merge, and at least a portion of the merge method. The electronic device 110 may utilize all or selectively utilize the information included in the first pull request to verify whether the state conditions are met. As an example, the electronic device 110 may identify at least one of the repository that generated the first branch, the first pull request itself, and the user requesting the merge. When the identified information meets the state conditions, the following step S230 is performed according to the merge method set for the first pull request. On the other hand, the merge method associated with the first pull request may include a fast-forward merge method, a recursive merge method, a squash merge method, and a rebase merge method. However, in this invention, the merge method associated with the pull request is not limited to these.

[0050] According to one embodiment, the state conditions used as a basis for determining whether to perform a merge related to the first pull request may include at least one of the following: whether the parity check passes, whether the unit test passes, whether a conflict occurs in the baseline branch, and whether the sign-off check passes.

[0051] According to one embodiment, electronic device 110 can determine that a state condition is met only when all of the multiple detailed conditions constituting the state condition are satisfied. According to another embodiment, the state condition may include necessary first-type detailed conditions and non-necessary second-type detailed conditions. In this case, electronic device 110 can determine that a state condition is met only when all of the first-type detailed conditions are satisfied. Furthermore, when different pull requests exist simultaneously, if the corresponding pull requests all satisfy the first-type detailed conditions, electronic device 110 may also prioritize the following step S230 for pull requests that satisfy more second-type detailed conditions. The first-type detailed conditions and the second-type detailed conditions may be fixed, but the administrator of electronic device 110 may change the settings of the electronic device 110's storage, thereby changing the first-type detailed conditions to second-type detailed conditions, or changing the second-type detailed conditions to first-type detailed conditions.

[0052] According to one embodiment, the electronic device 110 may utilize the API (Application Programming Interface) of a service platform that supports the hosting of a repository that generates the first branch to report information and status conditions included in the first pull request to the service platform, and receive status attribute values ​​related to whether code changes can be merged, which are returned from the service platform. An example of such a service platform is GitHub. Furthermore, the status attribute value may have one of the following exemplary values: true, false, or null. A null value may indicate that the service platform is calculating whether a merge is possible and is requesting service waiting before updating mergeability information.

[0053] In step S230, when the first pull request meets the preset state conditions, the electronic device 110 can merge the code change items corresponding to the first pull request into the base branch according to the preset merging method.

[0054] According to one embodiment, when the first pull request does not meet the status conditions, the electronic device 110 can classify the first pull request as unmergeable and exclude it from the merge wait list. Thereafter, the electronic device 110 can verify whether the second pull request meets the status conditions based on information included in the second pull request, which is the second pull request in the merge wait list after the first pull request. When the second pull request meets the status conditions, the code change corresponding to the second pull request is merged into the base branch according to a preset merging method. However, as an example of the priority of the electronic device 110 in considering and processing multiple pull requests, according to another embodiment, when the first pull request does not meet the status conditions, the electronic device 110 can also send a retransmission request for the pull request to the user terminal 120 that transmitted the first pull request before processing the second pull request.

[0055] On the other hand, in addition to the first pull request, multiple pull requests, such as the second and third pull requests, may accumulate code changes to the base branch. If the base branch is not the main branch where the code changes are ultimately to be integrated, it is necessary to automate the process of merging the code changes accumulated in the base branch to the main branch in order to ensure complete and continuous integration and release. In a related embodiment, the electronic device 110 can confirm whether the release preparation for the code changes accumulated in the base branch is complete; when the release preparation for the accumulated code changes is complete, a release tag is generated in the base branch; before the release tag is marked, the code changes accumulated in the base branch are merged into the main branch. Both the base branch and the main branch may be generated in a repository corresponding to the account of the electronic device 110, but according to the embodiment, the main branch may also be generated in a repository corresponding to a separate account, thereby granting push permissions to the branch of the electronic device 110.

[0056] Specifically, when confirming whether the release preparation for the code changes accumulated in the base branch is complete, the electronic device 110 may also pre-release the code changes accumulated in the base branch to a portion of the user terminals among the plurality of user terminals that use the main branch for operation; if no problems arise in a portion of the user terminals due to the code changes accumulated in the base branch within a preset period, it is determined that the release preparation is complete.

[0057] Figure 3 is a flowchart illustrating the automated pull request merging method of the additional embodiment.

[0058] In step S310, the electronic device 110 may receive a first pull request corresponding to the code change item of the first branch.

[0059] In step S320, the electronic device 110 can verify whether the first pull request meets the preset state conditions based on the information included in the first pull request.

[0060] In step S330, when the first pull request meets the preset state conditions, the electronic device 110 can merge the code change items corresponding to the first pull request into the base branch according to the preset merging method.

[0061] In step S340, the electronic device 110 may store the record data related to the merger of the code change item to the database associated with the electronic device 110, wherein the code change item is a base branch as the target.

[0062] According to one embodiment, the record data stored in the database may include at least a part of whether the code change was successfully merged, the reason for the failure when the code change was merged, and the name of the repository that generated the first branch.

[0063] According to one embodiment, after storing the recorded data in a database, the electronic device 110 can transmit notifications related to the recorded data to the user terminal 120 associated with the electronic device 110.

[0064] According to one embodiment, after storing the recorded data in a database, the electronic device 110 can provide a dashboard, including at least a portion of the analysis content of code change matters, optimization schemes, and conflict resolution schemes, to the user terminal 120 associated with the electronic device 110 based on the recorded data.

[0065] Figure 4 is an illustrative diagram illustrating the parameters for defining a pull request.

[0066] A pull request may include various information, which can be defined by parameters. Figure 4 illustrates, illustratively, the names of the multiple parameters included in a pull request, the requirement or non-requirement of each piece of information, the format (type) of each piece of information, and the description of the information.

[0067] First, "role" is a string parameter that describes the function associated with the repository that generates the branch, which corresponds to the pull request. The electronic device 110 can refer to this parameter to identify which function the corresponding local repository performs. "base" is a string parameter that specifies the base branch to which the code changes in the pull request will be merged. The electronic device 110 can refer to this parameter to identify the base branch. The initial value of "base" can be specified as a branch named Release Candidate (RC), but is not necessarily limited to this.

[0068] On the other hand, "pr_numbers" is a parameter of type array representing a list of pull request numbers for a merge request. The electronic device 110 can refer to this parameter to determine the processing order of the pull requests. "Owner" is a parameter of type string representing the owner (account) of the repository that generates the branch corresponding to the pull request. The electronic device 110 can refer to this parameter to identify whether the corresponding account has access permissions to the base branch or the main branch, and whether it is the true owner of the local repository, etc.

[0069] On the other hand, "merge_method" is a string parameter that specifies the method for merging code changes from a pull request into the base branch. "merge_method" may include a plurality of options, wherein a compressed merging method is specified as the initial value, but is not necessarily limited to this.

[0070] On the other hand, "pr_from" is a parameter of string type indicating whether the pull request needs to be obtained from the publishing service, and "deploy_window" is a parameter of string / array type indicating the publishing window used to pull the pull request. When no publishing window is provided, the current publishing window can be used.

[0071] Figure 5 is an illustrative diagram representing a pull request, illustrating an example of a pull request based on the parameters shown in Figure 4.

[0072] The attribute value of "task" is "sdp_front_api", which indicates that the repository and external interface functions that generate the branch corresponding to the pull request are related to the function. The external interface allows the user client to communicate with the backend server through the Single Detail Page (SDP) in the item sales service application.

[0073] Furthermore, the attribute value of "base number" is "rc", indicating that the code change items in the pull request will be designated as a branch named release candidate on the base branch to be merged. In addition, the attribute value of "pr_numbers" is [123, 456, 789], and the numbers of the three pull requests in the merge request are 123, 456, and 789 respectively.

[0074] Figure 6 is an illustrative diagram illustrating the status code corresponding to the pull request that merges with the base branch. In one embodiment, the status code may include an element of a status attribute value returned by the electronic device 110 from the service platform in response to information reported to the service platform. The value of the status code may indicate whether the code change corresponding to the pull request will be merged into the base branch, and if not, the reason for it.

[0075] Referring to Figure 6, status code "200" indicates that the code change has been successfully merged into the base branch. Status code "400" indicates that at least some of the parameters in the pull request are missing or invalid, and the pull request is judged as an erroneous request. Therefore, it indicates that the code change has not been merged into the base branch. On the other hand, status code "403" indicates that the account (referred to as "user" in Figure 6) of the user terminal 120 that transmitted the pull request does not have the permission to merge the code change request into the base branch. This indicates that the code change has not yet been merged into the base branch. On the other hand, status code "500" indicates that an error occurred in the service platform when processing the pull request, and therefore the code change has not yet been merged into the base branch.

[0076] According to one embodiment, the electronic device 110 can perform subsequent processes corresponding to the status code value, and can also transmit requests including information required for the performance of subsequent processes to the user terminal 120. For example, when the status code value is "200", the electronic device 110 can transmit a message notifying the successful merging to the user terminal 120; when the status code value is "400", the electronic device 110 can transmit a confirmation request for the parameters of the pull request to the user terminal 120. Furthermore, when the status code value is "403", the electronic device 110 can transmit a confirmation request for the permissions granted to the account on the user terminal 120 to the user terminal 120; when the status code value is "500", a retry request can also be transmitted to the user terminal 120, or after a period of time, the corresponding pull request can be requested again from the service platform without transmitting another request to the user terminal 120.

[0077] On the other hand, the status code and its corresponding status attribute can be set by the electronic device 110 or the service platform in various ways, and the content of the status code and its corresponding status attribute is not limited to the content shown in Figure 6.

[0078] Figure 7 is an illustrative diagram showing the response returned by the self-service platform in response to the pull request, and describes an example of the response returned based on the status code shown in Figure 6.

[0079] Referring to Figure 7, an exemplary response to a successful merge may include a status code value "200" indicating a successful merge, and a message notifying of a successful merge ("Pull requests merged successfully."). Conversely, an exemplary response to a failed merge may include a status code value "403" indicating a failed merge, and a message indicating that the user terminal 120's account does not have permission as the reason for the failure ("You do not have permission to merge branch protection!").

[0080] Figure 8 is an illustrative diagram illustrating the automated pull request merging process. As shown, Figure 8 illustrates an embodiment where a main branch exists, independent of the base branch.

[0081] Referring to Figure 8, the electronic device 110 can receive pull requests, which are requests to merge the code changes written in the first, second, and third branches into the base branch respectively. The three pull requests can be transmitted from a single user terminal, but according to the embodiment, they can also be transmitted from multiple user terminals respectively.

[0082] The electronic device 110 can verify whether each of the three pull requests meets preset state conditions based on the information of each pull request. For pull requests that meet the state conditions, the code change items corresponding to the pull requests are merged into the base branch. In the example shown in Figure 8, when merging code change items into the base branch according to state conditions, the electronic device 110 can verify whether conditions related to dependency and conditions related to quality are met.

[0083] By accumulating code changes to the base branch through three pull requests, the electronic device 110 can confirm whether the release preparation for the code changes accumulated in the base branch is complete. In an embodiment, if the electronic device 110 can execute a preset test process and receive a signal authorizing the release of its results, it is determined that the release preparation is complete. If the release preparation is complete, the electronic device 110 can generate a release tag in the base branch. For example, as shown in FIG8, if intermediate testing and artifact testing are performed and it is determined that the test results are authorized for full release, the electronic device 110 can determine that the release preparation is complete and generate a release tag in the base branch. At this time, the intermediate testing is only performed on a portion of the user accounts belonging to the preset user pool, and the application code changes are tested. The artifact testing can be performed on all user accounts. As an example, the user pool can be defined as the user terminal accounts that use the main branch to perform operations.

[0084] Before the point at which a release tag is generated and tagged to the base branch, the electronic device 110 can merge the code changes accumulated in the base branch into the main branch. That is, the electronic device 110 can use the release tag to clearly reflect the time range of the code changes and prevent the processing of pull requests generated before and after the point at which the release tag is tagged from being repeated.

[0085] Figure 9 is a block diagram showing an electronic device according to an embodiment.

[0086] According to one embodiment, the electronic device 110 may include a memory 111 and a processor 113. The electronic device 110 shown in FIG9 only illustrates the components relevant to this embodiment. Therefore, those skilled in the art related to this embodiment will understand that, in addition to the components shown in FIG9, other common components may be included. According to the embodiment, the electronic device 110, as a device for implementing wired / wireless communication, may further include a transceiver (not shown) capable of communicating with an external electronic device. The external electronic device may be a terminal or a server. Furthermore, the communication technologies utilized by the transceiver may include GSM (Global System for Mobile communication), CDMA (Code Division Multi Access), LTE (Long Term Evolution), 5G, WLAN (Wireless LAN), Wi-Fi (Wireless-Fidelity), Bluetooth™, RFID (Radio Frequency Identification), Infrared Data Association (IrDA), VPN, NFC (Near Field Communication), etc. In this embodiment, the transceiver may be included in the communication device.

[0087] The processor 113 can control the overall operation of the electronic device 110 and process data and signals. In an embodiment, the processor 113 may be included in a controller. The processor 113 may include at least one hardware unit. Furthermore, the processor 113 may operate by executing one or more software modules generated by executing program code stored in memory 111. The processor 113 may include memory, and the processor 113 can execute program code stored in memory to control the overall operation of the electronic device 110 and process data and signals.

[0088] In one embodiment, the processor 113 of the electronic device 110 may receive a first pull request corresponding to a code change item of the first branch; based on the information included in the first pull request, verify whether the first pull request meets a preset state condition; when the first pull request meets the state condition, merge the code change item corresponding to the first pull request into the base branch according to a preset merging method.

[0089] The electronic device of the above embodiments may include a processor, memory for storing and executing program data, permanent storage such as a disk drive, a communication port for communicating with external devices, and a user interface device such as a touch panel, key, or button. Computer-readable code or program commands that can be executed on the processor can be stored on a computer-readable recording medium by means of software modules or algorithms. Here, computer-readable recording media include magnetic storage media (e.g., ROM (read-only memory), RAM (random-access memory), floppy disks, hard disks, etc.) and optical reading media (e.g., CD-ROM, DVD). The computer-readable recording medium is distributed across a computer system connected to a network, thereby enabling the distributed storage and execution of computer-readable code. The medium can be read by a computer, stored in memory, and executed in a processor.

[0090] This embodiment can be represented by functional blocks and various processing steps. These functional blocks can be implemented by different numbers of hardware and / or software components performing specific functions. For example, the embodiment can employ integrated circuits capable of performing various functions via the control of one or more microprocessors or other control devices, such as memory, processing, logic, lookup tables, etc. The constituent elements can be executed by software programming or software components. Similarly, this embodiment includes algorithms implemented by combinations of data structures, programs, conventions, or other programming structures, and therefore can be implemented using programming or scripting languages ​​such as C, C++, Java, and assemblers. Functionally, it can be implemented by algorithms executed in one or more processors. Furthermore, this embodiment can employ prior art for electronic environment setup, signal processing, and / or data processing. Terms such as "mechanism," "element," "means," and "construction" are used broadly and are not limited to mechanical or physical structures. The above terms may be associated with processors and include the meaning of a series of software processes.

[0091] The above embodiments can be implemented as artificial intelligence (AI) using the processor and memory of an electronic device. The processor may include one or more processors, which may be general-purpose processors such as CPUs, APs, and DSPs (digital signal processors), graphics-specific processors such as GPUs and VPUs (vision processing units), or AI-specific processors such as NPUs. One or more processors can be controlled to process input data according to predefined action rules or AI models stored in memory. Alternatively, when one or more processors are AI-specific processors, the AI-specific processors may be designed with hardware structures specifically for processing specific AI models.

[0092] The predefined action rules or artificial intelligence models are characterized by being created through learning. Here, "created through learning" means using a learning algorithm to learn a basic artificial intelligence model from multiple learning materials, thereby creating predetermined action rules or artificial intelligence models set in a manner that implements the desired characteristics (or, purpose). This learning can be implemented within the electronic device implementing the artificial intelligence of the present invention, or it can be implemented by a separate server and / or system. Examples of learning algorithms include supervised learning, unsupervised learning, semi-supervised learning, or reinforcement learning, but are not limited to the examples mentioned above.

[0093] An artificial intelligence model can consist of a plurality of neural network layers. Each of the plurality of neural network layers has a plurality of weight values, and neural network operations can be performed by operations between the results of previous layers and the plurality of weight values. The plurality of weight values ​​of the plurality of neural network layers can be optimized by the learning results of the artificial intelligence model. For example, during the learning process, the plurality of weight values ​​can be updated in a way that reduces or minimizes the loss or cost values ​​obtained by the artificial intelligence model. Artificial neural networks may include deep neural networks (DNN), convolutional neural networks (CNN), recurrent neural networks (RNN), restricted Boltzmann machines (RBM), deep belief networks (DBN), bidirectional recurrent deep neural networks (BRDNN), or deep Q-networks, but are not limited to the examples mentioned above.

[0094] The above embodiment is only an example, and other embodiments can be implemented within the scope of the technical solutions described below. [Simplified Explanation of the Diagram]

[0023] Figure 1 is a diagram illustrating a system for automating pull request merging according to an embodiment. Figure 2 is a flowchart illustrating an automated pull request merging method according to an embodiment. Figure 3 is a flowchart illustrating an automated pull request merging method according to an additional embodiment. Figure 4 is an illustrative diagram illustrating the parameters for defining a pull request. Figure 5 is an illustrative diagram illustrating a pull request. Figure 6 is an illustrative diagram illustrating the status codes corresponding to the merged pull request with the request baseline branch. Figure 7 is an illustrative diagram illustrating the response returned from the service platform to the pull request. Figure 8 is an illustrative diagram illustrating the automated pull request merging process. Figure 9 is a block diagram illustrating an electronic device according to an embodiment.

Claims

1. A method for automating pull request merging, implemented via an electronic device, comprising the following steps: receiving a first pull request corresponding to code changes in a first branch; verifying, based on information included in the first pull request, whether the first pull request meets preset state conditions; and, when the first pull request meets the aforementioned state conditions, merging the code changes corresponding to the first pull request into a base branch according to a preset merging method; wherein the base branch and the main branch exist separately, and the method for automating pull request merging further comprises the following steps: confirming whether release preparation for accumulated code changes in the base branch has been completed; when release preparation for accumulated code changes has been completed, generating a release tag in the base branch; and merging the code changes accumulated in the base branch into the main branch before the release tag is marked.

2. The automated method for merging pull requests as described in Request 1, wherein the first pull request includes the name of the repository that generated the first branch, the identifier of the first pull request, the identifier of the base branch, the user requesting the merge, and at least some of the information in the merge method.

3. The automated method for merging pull requests as in Request Item 1, wherein the aforementioned status conditions include at least one of the following: whether the parity check passed, whether the unit test passed, whether a conflict occurred in the aforementioned baseline branch, and whether the reviewer accepted the request.

4. As in the automated method for merging pull requests in request item 1, the above verification steps include the following steps: using the API of the service platform to report the information included in the first pull request and the above status conditions to the service platform, which is the custodian of the repository that supports the generation of the first branch; and receiving status attribute values ​​related to whether the above code changes can be merged, the status attribute values ​​being returned from the service platform.

5. The automated method for merging pull requests as described in Request 1, wherein the merging method can be any of the following: fast-forward merging, recursive merging, compaction merging, and rebasic merging.

6. The automated method for merging pull requests as described in Request Item 1, wherein the steps for confirming whether the above-mentioned release preparation has been completed include the following steps: pre-publishing the code changes accumulated in the above-mentioned base branch to a portion of the user terminals among the plurality of user terminals that use the above-mentioned main branch to perform operations; and if no problems arise in the above-mentioned user terminals due to the code changes accumulated in the above-mentioned base branch within a preset period, then it is determined that the above-mentioned release preparation has been completed.

7. The automated method for merging pull requests as described in request item 1 further includes the following steps: When the first pull request does not meet the above-mentioned status conditions, classify the first pull request as unmergeable and exclude it from the merge waiting list; Based on the information included in the second pull request, verify whether the second pull request meets the above-mentioned status conditions, and whether the second pull request belongs to the merge waiting list in the order of the first pull request; and when the second pull request meets the above-mentioned status conditions, merge the code change items corresponding to the second pull request into the base branch according to a preset merging method.

8. The automated method for merging pull requests as described in Request 1 further includes the following steps: storing records related to the merging of code change items in a database associated with the aforementioned electronic device, wherein the code change item targets the aforementioned baseline branch.

9. The automated method for merging pull requests as described in request item 8, wherein the aforementioned record data includes at least a part of whether the merging of the aforementioned code change items was successful, the reason for failure when the merging of the aforementioned code change items failed, and the name of the repository that generated the aforementioned first branch.

10. The automated method for merging pull requests as described in request item 8 further includes the following steps: transmitting a notification related to the aforementioned record data to a user terminal associated with the aforementioned electronic device.

11. The automated method for merging pull requests as described in request item 8 further includes the following steps: Based on the above-mentioned recorded data, providing a dashboard containing at least a portion of the analysis content, optimization scheme, and conflict resolution scheme of the above-mentioned code change matters to the user terminal associated with the above-mentioned electronic device.

12. A non-transitory computer-readable recording medium recording a program for performing the method as described in claim 1 on a computer.

13. An electronic device that automates the merging of pull requests, comprising a memory storing commands and a processor, wherein the processor is connected to the memory to receive a first pull request corresponding to code changes in a first branch; verifies, based on information included in the first pull request, whether the first pull request satisfies the preset state conditions; and, when the first pull request satisfies the preset state conditions, merges the code changes corresponding to the first pull request into a base branch according to a preset merging method; wherein the base branch and the main branch exist separately, and the processor further confirms whether the release preparation for the code changes accumulated in the base branch has been completed; when the release preparation for the accumulated code changes has been completed, generates a release tag in the base branch; and before the release tag is marked, merges the code changes accumulated in the base branch into the main branch.

Images