Mechanism for automatically merging software code changes into the appropriate channels

Abstract

A method and system for merging source code changes made in a first branch of a source code configuration into a second branch of the source code configuration, performed by the steps of: detecting changes made to the first branch, identifying the second branch as a branch in the source code configuration that does not include the changes; automatically merging the changes into the second branch; determining whether the automatic merging of the changes was successful; and notifying an individual if the automatic merging was unsuccessful so that a manual merging can be performed.

Description

Technical Field

[0001] The present disclosure relates generally to merging software code changes into appropriate code branches, and more particularly to improved methods and systems for determining whether a software code change should be merged into a code branch and automatically initiating the change if so. Background Art

[0002] Complex software code often goes through a validation and deployment process before final release. During this process, there may be situations where last-minute changes need to be made to a version of the software code at or just before it is released. Because there may be multiple groups and developers working on the code, these changes may be made in different versions of the software code. For example, a developer may change the version of the code being deployed. However, unless the change is merged back into the main version, future versions of the code may not include the change. In addition, any version of the code that was branched from the trunk before the change was merged may also not include the change. This can cause problems and inconsistencies between different versions of the code.

[0003] Traditionally, keeping track of changes that need to be merged into various branches of software code is done manually by one or more administrators or project managers. Alternatively, the developer who makes the change may have been assigned the responsibility of ensuring that the change is merged into all relevant branches. This is a cumbersome and inefficient process because last minute changes may have been made to various versions of the software's code. Furthermore, the process is prone to errors because it relies on one or more individuals to keep track of all required changes.

[0004] Therefore, there is a need for an improved method and system for incorporating software code changes into appropriate software branches. Summary of the invention

[0005] In one general aspect, the present application describes a device having: one or more processors; and a memory in communication with the processor, wherein the memory includes executable instructions that, when executed by the processor, cause the device to perform multiple functions. The functions may include: receiving a notification from an event tracking application via a network, the notification indicating that a change was made to a first branch of a source code configuration, and the notification is sent by the event tracking application after receiving information from a source repository server; identifying a second branch of the source code configuration that does not include the change; automatically merging the change into the second branch; determining whether the automatic merging of the change is successful; and depending on the result of determining whether the automatic merging of the change is successful, sending the first indication to a work tracking application to update a task entry.

[0006] In another general aspect, the functions performed by the processor may also include: upon receiving the notification, sending a second indication to the work tracking application to create a task entry for the change; or if it is determined that the automatic merge is unsuccessful, sending a third indication to the work tracking application to update the task entry to initiate notification to the individual. In another general aspect, the functions performed by the processor may also include: identifying one or more main branches of the source code configuration; checking the identified main branches to identify active branches among the identified main branches; checking the identified active branches to detect branches created in the source code configuration after the first branch; comparing the source code of the detected branch with the source code of the merge root of the first branch of the source code and the main branch to determine whether there is a difference between the detected branch and the merge root; and designating any branch identified as having a difference as a second branch.

[0007] In another general aspect, the present application describes a method for merging source code changes made in a first branch of a source code configuration into a second branch of the source code, wherein the method includes the following steps: receiving a notification from an event tracking application via a network, the notification indicating that a change was made to the first branch, and the notification is sent by the event tracking application after receiving information from a source repository server; identifying the second branch as a branch of the source code configuration that does not include the change; automatically merging the change into the second branch; determining whether the automatic merging of the change is successful; and depending on the result of determining whether the automatic merging of the change is successful, sending the first indication to a work tracking application to update a task entry.

[0008] In another general aspect, the method may include the steps of: upon receiving the notification, sending a second indication to the work tracking application to create a task entry for the change; or if it is determined that the automatic merge is unsuccessful, sending a third indication to the work tracking application to update the task entry to initiate notification to the individual. The method may also include the steps of: identifying one or more main branches of the source code configuration; examining the identified main branches to identify active branches among the identified main branches; examining the identified active branches to detect branches created in the source code configuration after the first branch; comparing the source code of the detected branch with the source code of the merge root of the first branch of the source code and the main branch to determine whether there is a difference between the detected branch and the merge root; and designating any branch identified as having a difference as a second branch.

[0009] In one general aspect, the present invention describes a device having: one or more processors; and a memory in communication with the processor, wherein the memory includes executable instructions that, when executed by the processor, cause the device to perform multiple functions. The functions may include: receiving a notification from an event tracking application via a network, the notification indicating that a first branch has been created in a source code configuration, and the notification is sent by the event tracking application after receiving information from a source repository server; identifying a second branch created in the source code configuration before the first branch; determining whether a change has been made to the second branch after the first branch has been created; after determining that a change has been made to the second branch, determining whether the change exists in the first branch; after determining that the change does not exist in the first branch, automatically merging the change into the first branch.

[0010] In another general aspect, the functionality may include: identifying one or more main branches of a source code configuration; examining the identified main branches to identify active branches among the identified main branches; and examining the identified active branches to detect branches created in the source code configuration before the first branch.

[0011] This summary is provided to introduce some concepts in a simplified form, which will be further described in the detailed description below. This summary is neither intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to implementations that solve any or all of the disadvantages noted in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The accompanying drawings depict one or more implementations according to the present teachings by way of example only and not limitation. In the accompanying drawings, like reference numerals refer to the same or similar elements. In addition, it should be understood that the accompanying drawings are not necessarily drawn to scale.

[0013] Figure 1 An exemplary system is shown upon which aspects of the present disclosure may be implemented.

[0014] Figure 2 Depicted are exemplary source code configurations with various branching and change events upon which aspects of the present disclosure may be implemented.

[0015] Figure 3A-3B is a flow chart illustrating an exemplary method for automatically ensuring that software code changes are incorporated into appropriate software branch channels.

[0016] Figure 4 is a flow chart illustrating an exemplary method for ensuring that software code changes are incorporated into all appropriate software branch channels.

[0017] Figure 5 is a block diagram illustrating an exemplary software architecture, portions of which may be used in conjunction with the various hardware architectures described herein.

[0018] Figure 6 is a block diagram illustrating components of an exemplary machine configured to read instructions from a machine-readable medium and perform any of the features described herein. DETAILED DESCRIPTION

[0019] In the following detailed description, numerous specific details are set forth by way of example in order to provide a thorough understanding of the relevant teachings. It will be apparent to those of ordinary skill after reading this specification that various aspects may be practiced without these details. In other cases, in order to avoid unnecessarily obscuring various aspects of the present teachings, well-known methods, processes, components and / or circuits have been described at a relatively high level without detail.

[0020] Source codes that are produced by a group of developers and then released for use usually go through a verification and deployment process to ensure that they work properly and are ready for widespread use. When problems are discovered during the verification and deployment process, different developers may make various changes until the last minute before the code is deployed. To make things more complicated, there are usually different active release channels for the software code (e.g., different versions of the code that go through verification and deployment). Since different developers may make multiple changes to each different release channel, it is important to track all changes to ensure that the changes are incorporated into all future versions of the code. This is usually done manually by one or more developers or individuals responsible for the process. However, in a fast-paced environment where many changes may be taking effect, it may be easy to lose track of some changes. In addition, the process can be time-consuming and labor-intensive.

[0021] To address these issues and more, in an example, the present specification provides a technique implemented for an improved method and system for incorporating software code changes into an appropriate software branch. To improve the current method of incorporating such changes, the technical solution is capable of automatically detecting changes made to related software channels, automatically identifying the software channels into which the changes should be incorporated, and automatically initiating the incorporation process. Automatically detecting changes may involve setting up a service to understand when changes are made to a specific software channel. On the other hand, automatically identifying the software channel to which the changes should be applied may involve performing a change comparison for a common ancestor between the channel of the initial change and all upcoming releases. Initiating the incorporation process may involve initiating automatic migration of changes to any identified software channel, and tracking the migration process to create work items and assigning them to specific people when problems are identified. For example, if a problem is detected during the migration process, the work item artifact can be opened and assigned to the original change owner to track where the changes need to be migrated. As a result, the solution provides an efficient, accurate and simple method for tracking changes made to various software code versions, determining when changes should be applied to other versions, and automatically initiating changes as needed.

[0022] As will be understood by those skilled in the art after reading this disclosure, the benefits and advantages provided by such implementations may include, but are not limited to, solutions to the technical problems of inefficient, labor-intensive, and unreliable incorporation of changes to software code versions into various other versions. The technical solutions and implementations provided herein optimize and improve the process of incorporating software code changes into appropriate software branches. The benefits provided by these solutions include: providing increased accuracy, reliability, and efficiency of incorporating software code changes into appropriate software branches, and reducing the amount of labor and supervision required for such processes.

[0023] Figure 1 An exemplary system 100 is shown on which aspects of the present disclosure may be implemented. System 100 may be implemented in a single site, or distributed across many buildings or geographically separated locations. System 100 may include a source repository 110, an event handling service 120, an event tracking application 140, and a work tracking application 150, all connected to a network 130. Network 130 may be a wired or wireless network, or a combination of wired and wireless networks connecting one or more elements of system 100.

[0024] Source repository 110 can be a version control system for tracking changes in computer files (e.g., software code files) and coordinating work on these files among multiple individuals. Source repository 110 can be used to store and / or manage source code in software development, for example, by storing and tracking various versions of source code and any changes made to each of these versions. In one implementation, source repository 110 can be an external source repository, such as a Git repository or Azure DevOps known in the industry, which can be used by multiple organizations to manage their source code development. Alternatively, source repository 110 can be an internal repository for each organization.

[0025] The source repository 110 may identify each change to one or more versions of the source code in the source repository 110 as an event. For tracking and processing purposes, each identified event may be sent to the event tracking application 140 by the source repository 110. In one implementation, the event tracking application 140 may be used as a tracker that tracks the status of events. For example, the event tracking application 140 may run in a manner similar to the Azure server bus. Upon receiving notification of an event, before forwarding information about the event to the event processing service 120 for further processing, the event tracking application may create a record (e.g., an entry or log in a database) for the event, which may identify the event type, the code version to which the change was made, the time of generation, the status of the change, and / or any other available relevant information about the change. In this way, the event tracking application 140 may be used as an intermediary between the source repository 110 and the event processing service 120.

[0026] The event handling service 120 can be used as an application for handling events (e.g., changes to source code). In order to effectively handle events, the event handling service 120 can access information on different branches (e.g., versions) of the source code and how they are constructed in the source repository 110, so that when the change event is applied to the branch associated with the release in the source repository 110, the event handling service 120 can determine which branch (e.g., other versions) the change should be applied to. This can be done by first identifying the candidate branches to which the change may need to be applied, and then by using, for example, a control system to determine whether the change is already included in each candidate branch. The control system can be related to the source repository 110, which uses local difference logic for candidate branches to identify the target branch. Once the event handling system 120 identifies the target branch that does not contain the change, continuous integration testing can be performed to ensure that there is no logical conflict by applying the change to the target branch. Then, the event handling service 120 can automatically apply the changes that have successfully passed the continuous integration test to the target branch. For any target branch that fails to pass the continuous integration test or encounters any other problems during the merging process, a notification can be sent to the work tracking application 150.

[0027] The work tracking application 150 can be used as an external work tracking program that tracks the status of work items, enables work items to be assigned to one or more individuals and / or provides notifications about work items. In one implementation, after receiving a notification from the event handling service 120, the work tracking application 150 can create a work log for the work item and automatically assign one or more individuals to the work item. For example, an individual can be a developer who generates the original changes in the source repository 110, or one or more other personnel responsible for the project. The work tracking application 150 can be configured to set automatic reminders and escalation mechanisms to ensure that work items are executed in a timely manner. Once a work item in the work tracking application 150 is indicated as closed, the information can be transmitted back to the event handling service 120, which can then notify the event tracking application 140 to update its event status accordingly.

[0028] In one implementation, one or more servers may be configured to perform the functions of each of the source repository 110, the event processing service 120, the event tracking application 140, and the work tracking application as disclosed herein. Alternatively, one or more functions may be performed by one or more user devices connected locally or remotely to the network 130.

[0029] Figure 2An exemplary source code configuration 200 with various branches and change events on which aspects of the present disclosure may be implemented is depicted. The exemplary source code configuration 200 includes a master (e.g., trunk) version 210 and four release branches R220, R230, R240, and R250. The master branch 210 may include multiple changes, such as CH1, CH2, CH3, CH4, and CH5, each of which is shown by a point in a tree branch. CH1 may occur at time T1, while CH2 may occur at time T2. After the change CH2 is made to the master branch 210, for example, for verification / deployment purposes, the release branch R220 may be forked. As described above, the verification / deployment process may be long in time. During the process, one or more changes, such as CH222, CH224, and CH226, may be made directly to the release branch R220. These changes may be made to the release branch R220 when the release branch is subjected to verification. For example, it may be discovered during the verification process that the change CH2 causes a configuration problem in the code. This may be first discovered during the verification process of release branch R220, because CH2 was already applied to the source code before release branch R220 was forked. In response, the developer may be assigned the task of creating a fix to address the problem. The fix may be established in change CH226 applied to release branch R220 at time T4. Release branch R220 may then proceed with deployment without any other changes.

[0030] While release branch R220 is undergoing verification and deployment, other changes can be made to main branch 210. For example, changes CH3, CH4, and CH5 can be made to main branch 210 after release branch R220 is forked to address one or more issues discovered separately from the issues identified during verification of release branch 210. As a result, there are now changes made to release branch R220 that are not available in main branch 210, as well as changes in main branch 210 that have not been applied to release branch R220. However, because main branch 210 is the trunk for all future releases, it is important to merge the changes made to release branch R220 back into main branch 210. To achieve this goal, the changes must be applied back to main branch 210. The process of applying changes to different branches can be called porting changes, and is done in Figure 2, shown by an arrow pointing from T4 to T5. Therefore, at time T5, a process of transplanting change CH226 to main branch 210 can be initiated. It should be noted that CH226 is only for illustration / example purposes. Any changes shown or applied to release branch R220 can be transplanted back to main branch 210 at different times. The process of transplanting changes to different branches may take some time. For example, it may take some time to ensure that the changes do not cause any conflicts with any other changes made to main branch 210 after release branch R220 bifurcates (CH3, CH4, CH5). This may involve performing integration testing to ensure that the changes can be safely integrated into main branch 210. Therefore, although the transplant process is initiated at T5, it may not be completed until time T7 (when point CH226' appears in main branch 210).

[0031] While release branch 210 is being verified, changed, and / or deployed, other branches may have been forked from main branch 210. For example, release branch R230 may be forked at time T3 to ensure that a release branch that includes changes CH3, CH4, and CH5 is available for deployment. During the verification and deployment process of release branch R230, other issues may be identified that require changes CH232 and CH234. While these changes may address some of the issues identified in release branch R230, they may still not address the issues addressed by CH226. Additionally, for consistency, it may be important to ensure that release branch R230 includes change CH226. However, because release branch R230 forked after release branch R220 forked and before change CH226' was ported back to main branch 210, change CH226 is not included in release branch R230. Therefore, a process may be required to ensure that branches such as release branch R230 include changes such as CH226. Figure 2 In the example shown, change CH226 is ported to release branch R230 at time T8. This can be accomplished via an improved method and system for incorporating software code changes into an appropriate software channel, as disclosed herein.

[0032] Once the change CH226' is merged into the release branch R230, the process of porting the changes made to the release branch R230 back to the main branch 210 can be initiated at time T9. The process can be completed at time T10, at which time the main branch 210 may include the change CH234' (and / or the change CH232'). Then, at a later time T11 (which may also be a later point in the tree configuration), the branch release R240 can be forked from the main branch 210 for verification and / or deployment. Because the branch release R240 is forked after the changes from the release branches R220 and R230 are merged into the main branch 210, it may already include those changes, as well as all the changes made to the main branch (e.g., CH1, CH2, CH3, CH4, CH5, CH226', and CH234'). As a result, at this point, the release branch R240 may not need to incorporate any changes. However, changes made to release branch R240 (including CH242, CH244, and CH246) may need to be merged back into the main branch and release branches R220, R230, and R250 (if not already deployed).

[0033] Source code configuration 200 also includes a release branch R250 that diverges from master branch 210 at time T6. As depicted on master branch 210, time T6 occurs between time T5, at which time the process of porting change CH226 to master branch 210 is initiated, and time T6, at which the change takes effect. As a result, while it appears that release branch R250 includes change CH226' because it diverges after time T5, it actually does not include change CH226'. As described below, this is a special case that may require additional mechanisms to ensure that such a release branch incorporates all required changes.

[0034] It should be noted that the exemplary source code configuration 200 and its various branches and events are for illustrative purposes. Many different variations of source code tree configurations are possible. Furthermore, while source code configuration 200 shows only a master branch and four release branches, it should be noted that most source code configurations include many other types of branches. For example, many developers may fork channels from any active branch to perform their own development and / or testing.

[0035] Figure 3A-3B 300 for automatically ensuring that software code changes are incorporated into the appropriate software branch channel. At 305, method 300 begins by detecting changes made to a release branch in a source code configuration. For example, this may occur when a developer makes a change to a release branch of source code while the release branch is in the process of verification and / or deployment. Changes to the release branch may be detected by one or more event tracking tools (e.g., webhooks) that monitor updates in a repository such as Figure 1 An event that occurs in a source repository (e.g., a source code management application that manages source code files) such as source repository 110 of Figure 1 One or more services or event tracking tools such as the event tracking application 140 of the source repository can be used to subscribe to (e.g., detect) events in the source repository. These events can be filtered through one or more filters to identify events that change the release branch in the source code. When an event (e.g., a change) is identified as a change to a release branch in the source repository, it can be reported to the event processing application and marked for further processing. Alternatively, the change can be detected by other mechanisms. For example, a developer can manually send a notification of a change to a release branch.

[0036] Once a change (also referred to as an event) is detected, at 310, method 300 can create a task entry (e.g., a work item) corresponding to the detected event. The task entry can be created to ensure that the event is recorded, and its status relative to various branches can be checked and updated. In one implementation, in a process such as Figure 1 A task entry is created in a work tracking application such as work tracking application 150 of , and assigned to one or more individuals. Assigning tasks (e.g., work items) to one or more people can ensure accountability and establish a review process where people can review the status of an event to ensure that the event is correctly ported to the applicable branch of the code.

[0037] After creating a task entry for the change, branches of source code that may need to be merged with the new change may be identified at 315. To identify applicable branches, Figure 3B One or more of the steps depicted in can be performed. For example, first, at 350, a release branch of the source code can be identified. This can be accomplished by utilizing the naming convention of the source code configuration. This is because most source code configurations use unique identifiers for default branches and scopes. For example, a release branch can begin with the letter R, while all other branches can have other naming conventions. As described above, there may be many out-of-scope branches in the source code configuration. Branches are filtered by naming convention to identify release branches and main branches, which can eliminate irrelevant branches that are not important enough to check for each change. In one implementation, only release branches and main branches are identified because they may be branches that will be deployed for use and / or used as the trunk for future release branches.

[0038] At 355, once the branches are filtered to identify release branches and master branches, active branches can be identified among the identified branches. This is because there may be one or more inactive release branches in the source code configuration. For example, a release branch that has already been deployed may have an inactive status. In addition, there may be release branches that have been pulled back from deployment for various reasons. These branches may also have an inactive status. By identifying active release branches, unnecessary processing of irrelevant branches can be eliminated.

[0039] After identifying the active release branch at step 355, the process can continue at 360 to identify branches from the active release branch that were created after the branch of the change was forked (e.g., forked from the source code tree). Figure 2 , assuming that the changed branch is release branch R220 and the change event in question is change 226, at this stage, all active release branches that branched from the main branch 210 after point CH2 can be identified. These can include release branches R230, R240, and R250. If there are release branches in the source code configuration 200 that branched from the tree before point CH2, these branches will be eliminated at this stage. It should be noted that when searching for active release branches created after the changed branch, the term "after" refers to the point in the source code configuration tree, not just in chronological order. This means that when searching for relevant branches, the process will examine the source code configuration tree and select those branches in the source code configuration that were created after point CH2. Through these filtering processes, relevant branches that may not include necessary changes but to which changes should be applied can be identified.

[0040] Reference back Figure 3B At 365, after the relevant branches are identified, the source code in each of those branches can be compared with the source code at the point of the merge root of the changed branch to determine whether each branch includes the necessary changes. The point of the merge root of the changed branch can be the point in the source code configuration when the changed branch is merged with the root (e.g., the main branch) to initiate the transplant of the changes in the changed branch back to the root (e.g., the main branch). Figure 2And in the example of release branch R220, this can be point T5 in master branch 210. This may be because this is the point in the source code configuration where the roots of all branches can begin to include the necessary changes. In one implementation, instead of checking the entire source code in each branch and comparing it to the source code in the merge root, only the changes in each branch are compared to the changes in the merge root. Doing so can improve efficiency and reduce the amount of time and resources required to perform searches and comparisons. At 370, by comparing the identified branches to the code at the point of the merge root, those branches that are missing and require necessary changes can be identified. In one implementation, if the identified branch is a master branch, then when changes are made to the release branch, the method can automatically assume that the changes should be ported back to the master branch.

[0041] After identifying the branch that needs to be modified, the process can proceed to step 320 of method 300 at 375 ( Figure 3A ) to create a task entry for each identified branch. This can ensure that the application or user keeps track of all necessary changes. Once the task entry is created for each identified branch, the method 300 can merge the changes into the first identified branch at 325. This can be done, for example, by Figure 1 This can be done automatically by an event handling service that can automatically insert the changes into the appropriate location in the source code of each identified branch. This will save the time, resources, and costs associated with having one or more individuals manually perform the process. In addition, potential human errors and / or the chance of people ignoring branches or forgetting to complete tasks can be eliminated. However, there may be instances where the process of incorporating changes cannot be completed automatically due to configuration or compatibility issues. In order to ensure that such instances do not result in incomplete migration of changes, method 300 can continue at 330 to determine whether the changes were successfully made to the first identified branch.

[0042] When it is determined at 330 that the changes were successfully made, the method 300 can proceed to update the task entry created for the branch at 380. This can be done automatically so that people do not have to be involved in the process unless desired or required due to a problem. For example, when it is determined that the changes were successfully merged into the branch, the method 300 can change the status of the task entry to closed to indicate that the task entry is no longer active.

[0043] However, when it is determined at 330 that the change has not been successfully incorporated into all identified branches, method 300 can proceed to notify the developer and / or any other individual responsible for the task entry created for the change at 335. Doing so can ensure that the appropriate individuals are aware of the problem and can review the process to ensure that the change is properly incorporated into the relevant branches. In one implementation, the notification can also include information about the problem that prevented the change from being successfully incorporated into all identified branches, information about which branches successfully received the change and which branches did not successfully receive the change, and / or any other available information that can be helpful to the personnel responsible for ensuring that the change is incorporated into all relevant branches. In addition, the notification can include a mechanism for reminding the developer of the need to complete the task and / or a mechanism for enabling one or more other individuals to oversee the completion of the task, for example, through the features of a work tracking application.

[0044] After receiving the notification, the changes can be manually merged into the identified branch at 340. Once the changes are manually made, the method can automatically determine or the developer can notify the method that the changes were successfully made, at which point the method 300 can proceed to step 380 to update the task entry for the branch.

[0045] After updating the task entry for the first identified branch (e.g., closing), method 300 can continue at 385 to determine whether there are any more branches identified that need to be changed. When there are more branches, method 300 can return to step 325 to incorporate the changes into the next identified branch and repeat steps 325-385 for the identified branch. If it is determined that no other identified branches still need to be changed, method 300 can continue at 390 to update the task entry for the event to indicate that all required changes for the event have been made.

[0046] It should be noted that in one implementation, one or more steps of method 300 are performed by an event processing service, which may be responsible for managing events related to source code.

[0047] Because the process of method 300 compares identified branches to the merge root when merging, branches created between the time when the migration changes are initiated (e.g., the merge point) and the time when the changes are successfully merged into the root may be erroneously eliminated. This is because some time typically passes between when the migration changes are initiated and when the changes are successfully completed. This amount of time may vary and may not be easy to determine and / or calculate. As a result, the point selected as the comparison point is often the time when the migration is initiated. However, since the root may still not contain the changes when the migration is initiated, branches created between that time and when the changes actually take effect may not include the changes, but may still not be identified in the search and comparison steps of method 300. In order to ensure that such branches also receive all required changes, additional mechanisms may be employed.

[0048] Figure 4 4 is a flow chart depicting an exemplary method 400 for ensuring that software code changes are incorporated into all appropriate software branch channels. At 405, method 400 can begin by detecting a new release branch in a source code configuration. For example, this can occur when a new release branch is created for deployment. The new release branch can be detected by one or more event tracking tools (e.g., webhooks) that monitor events in a source code configuration such as Figure 1 Events that occur in a source repository such as source repository 110 (e.g., a source code management application that manages source code files). For example, one or more services or event tracking tools can be used to subscribe to (e.g., detect) events in the source repository. These events can be filtered by one or more filters to identify events that create new release branches in the source code. When an event (e.g., a work item) is identified in the source repository as the creation of a new release branch, it can be reported to the event processing application and marked for further processing. Alternatively, new branches can be detected by other mechanisms. For example, one or more developers can manually send a notification that a new release branch has been created.

[0049] Once a new branch is detected, method 400 can identify, at 410, an active release branch created before the new release branch. This can be done in a similar manner to that described with respect to Figure 3B The multiple steps discussed are completed, where first, the main branch and the release branch are identified via a naming convention before being identified from those active release branches, and finally the branch created before the new branch is identified from the active release branches. It should be noted that in this step, the main branch is also included in the list of identified branches. Next, for each branch identified in step 410, the method 415 can identify at 415 the changes made to each branch after the branch time of the current new branch.

[0050] Once all changes made to the identified branch after the branch time are found, method 400 can continue to determine whether each found change exists in the new release branch at 410. When it is determined that all found changes exist in the new release branch, method 400 can continue at 450 to complete the process.

[0051] However, when it is determined that one or more of the discovered changes are not present in the new release branch, method 400 can continue at 425 to create a task entry for each change that is not available in the new release branch, and then merge each of those changes into the new release branch at 430. Task entries can be created to ensure that there is a record of the event, and their status with respect to various branches can be checked and updated. In one implementation, in a branch such as Figure 1 A task entry is created in a work tracking application such as work tracking application 150 of , and assigned to one or more individuals. Assigning tasks to one or more individuals can ensure accountability and establish a review process where people have the ability to review the status of an event to ensure that the event is correctly ported to the new release branch. In one implementation, only one task entry is created for all changes that are incorporated. Alternatively, a separate task entry can be created for each unincorporated change.

[0052] For example, Figure 1 The event handling service of the method 400 automatically performs the process of merging the changes into the new release branch, and the event handling service can automatically insert the changes into the appropriate location in the source code of the new release branch. However, there may be such instances that due to some problems, the process of merging the changes may not be completed automatically. In order to ensure that such instances do not result in incomplete migration of the changes, the method 400 can continue at 435 to determine whether each change is successfully merged into the new release branch.

[0053] When it is determined that all changes were successfully made at 435, method 400 can continue at 445 to update the task entry created for the changes. This can be done automatically so that people do not have to participate in the process unless desired or required due to problems. For example, when it is determined that the changes were successfully merged into the branch, method 400 can change the status of the task entry to closed to indicate that the task entry is no longer active.

[0054] However, when determining that one of the changes is not successfully incorporated into the new release branch at 435, method 400 can continue at 425 to notify the developer and / or any other individual responsible for the task entry created for the change. Doing so can ensure that the appropriate individual knows the problem, and can review the process to ensure that the change is properly incorporated into the new release branch. In one implementation, the notification can also include information about preventing the change from being successfully incorporated into the branch, and / or any other available information that can be helpful to the personnel responsible for ensuring that the change is properly incorporated. In addition, the notification can include a mechanism for reminding the developer about the need to complete the task and / or a mechanism for making one or more other individuals supervise the completion of the task, for example, by the characteristics of the work tracking application. At 455, after receiving the notification, the change can be manually incorporated into the branch. Once manually changed, the method can automatically determine or the developer can notify the method that the change has been successfully changed, at which point, method 400 can proceed to step 445 to update the task entry for the branch before moving to 450 to end the process.

[0055] Thus, in various implementations, an improved method and system may be provided for automatically determining whether one or more changes made in one branch of a source code configuration should be merged into other branches of the source code, and for supporting automatic migration of the changes when it is determined that a merge is required. In some implementations, the method may provide a mechanism for tracking all required changes and notifying personnel when changes cannot be made automatically.

[0056] Figure 5 is a block diagram 500 illustrating an exemplary software architecture 502, portions of which may be used in conjunction with the various hardware architectures described herein that may implement any of the features described above. Figure 5 504 are non-limiting examples of software architectures, and it will be appreciated that many other architectures may be implemented to facilitate the functionality described herein. Software architecture 502 may be executed on hardware, such as client devices, native application providers, web servers, server clusters, external services, and other servers. Representative hardware layers 504 include processing units 506 and associated executable instructions 508. Executable instructions 508 represent executable instructions of software architecture 502, including implementations of methods, modules, etc. described herein.

[0057] The hardware layer 504 also includes a memory / storage device 510, which also includes executable instructions 508 and accompanying data. The hardware layer 504 may also include other hardware modules 512. The instructions 508 held by the processing unit 508 may be a portion of the instructions 508 held by the memory / storage device 510.

[0058] Exemplary software architecture 502 can be conceptualized as layers, each providing various functions. For example, software architecture 502 may include layers and components, such as operating system (OS) 514, library 516, framework 518, application 520, and presentation layer 524. In operation, applications 520 and / or other components within this layer may call API calls 524 to other layers and receive corresponding results 526. The layers shown are representative in nature, and other software architectures may include additional or different layers. For example, some mobile or dedicated operating systems may not provide framework / middleware 518.

[0059] OS 514 can manage hardware resources and provide public services. OS 514 may include, for example, kernel 528, service 530 and driver 532. Kernel 528 may be used as an abstraction layer between hardware layer 504 and other software layers. For example, kernel 528 may be responsible for memory management, processor management (e.g., scheduling), component management, networking, security settings, etc. Service 530 may provide other public services for other software layers. Driver 532 may be responsible for controlling underlying hardware layer 504 or interfacing with it. For example, driver 532 may include display driver, camera driver, memory / storage device driver, peripheral device driver (e.g., via universal serial bus (USB)), network and / or wireless communication driver, audio driver, etc., depending on hardware and / or software configuration.

[0060] The library 516 can provide a common infrastructure that can be used by the application 520 and / or other components and / or layers. The library 516 generally provides functions for other software modules to perform tasks, rather than directly interacting with the OS 514. The library 516 may include a system library 534 (e.g., a C standard library), which may provide functions such as memory allocation, string manipulation, file operations, etc. In addition, the library 516 may include an API library 536, such as a media library (e.g., supporting the presentation and manipulation of image, sound and / or video data formats), a graphics library (e.g., an OpenGL library for rendering 2D and 3D graphics on a display), a database (e.g., SQLite or other relational database functions), and a web library (e.g., WebKit, which may provide web browsing functions). The library 516 may also include various other libraries 538 to provide many functions for the application 520 and other software modules.

[0061] Framework 518 (sometimes also referred to as middleware) provides a higher level common infrastructure that can be used by applications 520 and / or other software modules. For example, framework 518 can provide various graphical user interface (GUI) functions, advanced resource management, or advanced location services. Framework 518 can provide a wide range of other APIs for applications 520 and / or other software modules.

[0062] Applications 520 include built-in applications 520 and / or third-party applications 522. Examples of built-in applications 520 may include, but are not limited to, contact applications, browser applications, location applications, media applications, messaging applications, and / or game applications. Third-party applications 522 may include any application developed by an entity other than the vendor of a particular system. Applications 520 may use the functionality available via OS 514, library 516, framework 518, and presentation layer 524 to create a user interface to interact with a user.

[0063] Some software architectures use virtual machines, such as virtual machine 528. Virtual machine 528 provides an execution environment in which applications / modules can run as if they were on a hardware machine (e.g., Figure 6 500). The virtual machine 528 may be hosted by a host OS (e.g., OS 514) or a hypervisor and may have a virtual machine monitor 526 that manages the operation of the virtual machine 528 and interoperation with the host operating system. A software architecture that may be different from the software architecture 502 external to the virtual machine is executed within the virtual machine 528, such as the OS 550, libraries 552, frameworks 554, applications 556, and / or presentation layer 558.

[0064] Figure 6 6 is a block diagram showing components of an exemplary machine 600 that is configured to read instructions from a machine-readable medium (e.g., a machine-readable storage medium) and perform any of the features described herein. The exemplary machine 600 is in the form of a computer system in which instructions 616 can be executed to cause the machine 600 to perform any of the features described herein (e.g., in the form of software components). In this way, the instructions 616 can be used to implement the methods or components described herein. The instructions 616 cause the unprogrammed and / or unconfigured machine 600 to operate as a specific machine that is configured to perform the described features. The machine 600 can be configured to operate as a standalone device, or can be coupled (e.g., networked) to other machines. In a networked deployment, the machine 600 can operate in the capacity of a server machine or a client machine in a server-client network environment, or as a node in a peer-to-peer or distributed network environment. The machine 600 may be embodied as, for example, a server computer, a client computer, a personal computer (PC), a tablet computer, a laptop computer, a netbook, a set-top box (STB), a gaming and / or entertainment system, a smart phone, a mobile device, a wearable device (e.g., a smart watch), and an Internet of Things (IoT) device. Furthermore, while only a single machine 600 is shown, the term "machine" includes a collection of machines that individually or collectively execute instructions 616.

[0065] The machine 600 may include a processor 610, a memory 630, and I / O components 650, which may be communicatively coupled via, for example, a bus 602. The bus 602 may include multiple buses that couple various elements of the machine 600 via various bus technologies and protocols. In an example, the processor 610 (including, for example, a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), an ASIC, or a suitable combination thereof) may include one or more processors 612a to 612n, which may execute instructions 616 and process data. In some examples, one or more processors 610 may execute instructions provided or identified by one or more other processors 610. The term "processor" includes a multi-core processor that includes cores that can execute instructions simultaneously. Although Figure 6 Multiple processors are shown, but machine 600 may include a single processor with a single core, a single processor with multiple cores (e.g., a multi-core processor), multiple processors each with a single core, multiple processors each with multiple cores, or any combination thereof. In some examples, machine 600 may include multiple processors distributed among multiple machines.

[0066] The memory / storage device 630 may include a main memory 632, a static memory 634 or other memory, and a storage unit 636, both of which may be accessible to the processor 602, for example, via the bus 602. The storage unit 636 and the memories 632, 634 store instructions 616, which embody any one or more of the functions described herein. The memory / storage device 630 may also store temporary, intermediate and / or long-term data for the processor 610. The instructions 616 may also reside in whole or in part in the memories 632, 634, in the storage unit 636, in at least one processor 610 (e.g., in a command buffer or cache), in a memory of at least one I / O component 650, or any suitable combination thereof during execution. Therefore, the memories 632, 634, the storage unit 636, the memory in the processor 610, and the memory in the I / O component 650 are examples of machine-readable media.

[0067] As used herein, a "machine-readable medium" refers to a device that is capable of temporarily or permanently storing instructions and data that cause the machine 600 to operate in a specific manner. As used herein, the term "machine-readable medium" does not include transient electrical or electromagnetic signals per se (e.g., on a carrier wave propagating through the medium); therefore, the term "machine-readable medium" may be considered to be tangible and non-transitory. Non-limiting examples of non-transitory, tangible machine-readable media may include, but are not limited to: non-volatile memory (e.g., flash memory or read-only memory (ROM)), volatile memory (e.g., static random access memory (RAM) or dynamic RAM), buffer memory, cache memory, optical storage media, magnetic storage media and devices, network accessible or cloud storage, other types of storage, and / or any suitable combination thereof. The term "machine-readable medium" applies to a single medium or a combination of multiple media for storing instructions (e.g., instructions 616) for execution by the machine 600, such that the instructions, when executed by one or more processors 610 of the machine 600, cause the machine 600 to perform one or more features described herein. Thus, a “machine-readable medium” may refer to a single storage device, as well as a “cloud-based” storage system or storage network that includes multiple storage devices or devices.

[0068] I / O components 650 may include various hardware components suitable for receiving input, providing output, generating output, sending information, exchanging information, capturing measurements, etc. The specific I / O components 650 included in a particular machine will depend on the type and / or function of the machine. For example, a mobile device such as a mobile phone may include a touch input device, while a headless server or IoT device may not include such a touch input device. Figure 6 The specific examples of I / O components shown in are by no means limiting, and other types of components may be included in the machine 600. The grouping of I / O components 650 is only to simplify the discussion, and the grouping is by no means limiting. In various examples, the I / O components 650 may include a user output component 652 and a user input component 654. The user output component 652 may include, for example, a display component (e.g., a liquid crystal display (LCD) or a projector) for displaying information, an acoustic component (e.g., a speaker), a tactile component (e.g., a vibration motor or a force feedback device) and / or other signal generators. The user input component 654 may include, for example, an alphanumeric input component (e.g., a keyboard or a touch screen), a pointing component (e.g., a mouse device, a touchpad or another pointing instrument), and / or a tactile input component (e.g., a physical button or touch screen that provides the location and / or force of a touch or touch gesture) configured to receive various user inputs (e.g., user commands and / or selections).

[0069] In some examples, I / O components 650 may include biometric components 656 and / or position components 662, as well as a variety of other environmental sensor components. Biometric components 656 may include, for example, components for detecting body expressions (e.g., facial expressions, vocal expressions, hand or body gestures, or eye tracking), measuring biosignals (e.g., heart rate or brain waves), and identifying people (e.g., via voice-based, retinal, and / or face-based recognition). Position components 662 may include, for example, position sensors (e.g., global positioning system (GPS) receivers), altitude sensors (e.g., barometric pressure sensors from which altitude can be derived), and / or orientation sensors (e.g., magnetometers).

[0070] I / O components 650 may include communication components 664 that implement various techniques operable to couple machine 600 to network 670 and / or device 680 via respective communication couplings 672 and 682. Communication components 664 may include one or more network interface components or other suitable devices that interface with network 670. Communication components 664 may include, for example, components suitable for providing wired communication, wireless communication, cellular communication, near field communication (NFC), Bluetooth communication, Wi-Fi, and / or communication via other modalities. Device 680 may include other machines or various peripherals (e.g., via USB coupling).

[0071] In some examples, communication component 664 can detect an identifier or include a component suitable for detecting an identifier. For example, communication component 664 can include a radio frequency identification (RFID) tag reader, an NFC detector, an optical sensor (e.g., a one-dimensional or multi-dimensional barcode or other optical code), and / or an acoustic detector (e.g., a microphone for identifying an audio signal of a tag). In some examples, location information can be determined based on information from communication component 662, such as, but not limited to, geographic location via an Internet Protocol (IP) address, location via Wi-Fi, cellular, NFC, Bluetooth, or other wireless station identification, and / or signal triangulation.

[0072] Although various embodiments have been described, this description is intended to be exemplary rather than restrictive, and it should be understood that more embodiments and implementations within the scope of the embodiments are possible. Although many possible combinations of features are shown in the drawings and discussed in this detailed description, many other combinations of disclosed features are also possible. Unless specifically limited, any feature of any embodiment may be combined or substituted with any other feature or element in any other embodiment. Therefore, it will be understood that any feature shown and / or discussed in this disclosure may be implemented together in any suitable combination. Therefore, the embodiments are not limited except according to the attached claims and their equivalents. Similarly, various modifications and changes may be made within the scope of the attached claims.

[0073] Generally, the functions described herein (e.g., the functions described herein) may be implemented using software, firmware, hardware (e.g., fixed logic, finite state machines, and / or other circuits), or a combination of these implementations. Figure 1-4 ). In the case of a software implementation, the program code performs the specified tasks when executed on a processor (e.g., one or more CPUs). The program code can be stored in one or more machine-readable storage devices. The features of the technology described herein are system-independent, which means that these technologies can be implemented on various computing systems with multiple processors. For example, an implementation may include an entity (e.g., software) that causes hardware to perform an operation, such as a processor function block, etc. For example, a hardware device may include a machine-readable medium that may be configured to maintain instructions that cause the hardware device (including an operating system and associated hardware executed thereon) to perform an operation. Therefore, the instructions can be used to configure the operating system and associated hardware to perform the operation, and thereby configure or otherwise adapt the hardware device to perform the above-mentioned functions. The instructions can be provided to the hardware element that executes the instructions by the machine-readable medium through a variety of different configurations.

[0074] Although what is considered to be the best mode and / or other examples have been described above, it should be understood that various modifications may be made therein, and the subject matter disclosed herein may be implemented in various forms and examples, and the teachings may be applied to many applications, only some of which are described herein. The appended claims are intended to claim any and all applications, modifications, and variations that fall within the true scope of the present teachings.

[0075] Unless otherwise indicated, all measurements, values, ratings, positions, amplitudes, dimensions and other specifications listed in this specification (including the appended claims) are approximate and not exact. They are intended to have a reasonable range consistent with the functions to which they are related and the customary practices in the fields to which they are related.

[0076] The scope of protection is limited only by the appended claims. The scope is and should be interpreted to be as broad as the ordinary meaning of the language used in the claims when interpreted in light of this specification and the attached prosecution history, and to encompass all structural and functional equivalents. Notwithstanding the foregoing, none of the claims is intended to include subject matter that does not satisfy the requirements of Sections 101, 102, or 103 of the Patent Act, nor should such subject matter be interpreted in such a manner. Any unintended inclusion of such subject matter is hereby disclaimed.

[0077] Except as stated above, nothing described above or illustrated is intended or should be construed as causing any component, step, feature, object, benefit, advantage or equivalent to be contributed to the public, whether or not recited in the claims.

[0078] It will be understood that the terms and expressions used herein have the ordinary meanings consistent with such terms and expressions with respect to their corresponding respective areas of inquiry and study unless specific meanings are otherwise set forth herein.

[0079] Relational terms such as first and second etc. can be used only to distinguish one entity or action from another entity or action, without requiring or implying any actual such relationship or order between such entities or actions. The terms "include", "comprise" and any other variations thereof are intended to cover non-exclusive inclusions, so that the process, method, article or device including a list of elements not only includes those elements, but also includes other elements that may include those that are not explicitly listed or inherent to such processes, methods, articles or devices. In the absence of other restrictions, an element beginning with "a" or "an" does not exclude the presence of other identical elements in the process, method, article or device including the element.

[0080] The Abstract of the present disclosure is provided to allow the reader to quickly identify the essence of the technical disclosure. When submitted, it should be understood that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing detailed description, it can be seen that various features are grouped together in various examples in order to simplify the present disclosure. The method of the present disclosure should not be interpreted as reflecting the intention that any claim requires more features than the features explicitly recited in the claim. On the contrary, as reflected in the attached claims, the inventive subject matter lies in less than all the features of a single disclosed example. Therefore, the following claims are hereby incorporated into the detailed description, with each claim independently serving as a separately claimed subject matter.

Claims

1. An apparatus for merging source code changes made in a first branch of a source code configuration into a second branch of the source code configuration, comprising: processor; as well as A memory in communication with the processor, the memory comprising executable instructions that, when executed by the processor, cause the device to perform the following functions: receiving a notification from an issue tracking application via a network, the notification indicating that a change was made to a first branch of a source code configuration, and the notification was sent by the issue tracking application after receiving information from a source repository server; identifying a second branch in the source code configuration that does not include the change; automatically merging the changes into the second branch; determining whether automatic incorporation of the changes was successful; as well as Depending on the result of determining whether the automatic incorporation of the change was successful, a first indication is sent to the work tracking application to update the task entry.

2. The device according to claim 1, wherein: The executable instructions, when executed by the processor, further cause the device to perform the following functions: upon receiving the notification, sending a second instruction to the work tracking application to create a task entry for the change; as well as If it is determined that the automatic incorporation was unsuccessful, a third indication is sent to the work tracking application to initiate notification to the individual.

3. The device according to claim 2, wherein: The task item is assigned to the individual.

4. The device according to claim 2, wherein: The executable instructions, when executed by the processor, further cause the device to perform the following functions: When it is determined that the automatic incorporation is unsuccessful, enabling the individual to incorporate the changes; and After determining that the manual merge is complete, the work tracking application is notified to automatically update the task entry.

5. The device according to claim 1, wherein: The executable instructions, when executed by the processor, further cause the device to perform the following functions: if it is determined that the automatic incorporation is successful, send a second indication to the work tracking application to update the task entry to an inactive state.

6. The device according to claim 1, wherein: Identifying the second branch includes: identifying one or more main branches of the source code configuration; examining the identified main branches to identify an active branch among the identified main branches; checking the identified active branches to detect branches created in the source code configuration after the first branch; comparing the source code of the detected branch with the source code of a merge root of the first branch of the source code and the main branch to determine whether there is a difference between the detected branch and the merge root; and Any branch identified as having a difference is designated as the second branch.

7. The device according to claim 6, wherein: The executable instructions, when executed by the processor, further cause the device to perform the following functions: send a second notification to create a task entry for each branch identified as the second branch.

8. A method for merging source code changes made in a first branch of a source code configuration into a second branch of the source code configuration, comprising: receiving a notification from an issue tracking application via a network, the notification indicating that a change was made to the first branch, and the notification being sent by the issue tracking application after receiving information from a source repository server; identifying the second branch as a branch in the source code configuration that does not include the change; automatically merging the changes into the second branch; determining whether automatic incorporation of the changes was successful; as well as Depending on the result of determining whether the automatic incorporation of the change was successful, a first indication is sent to the work tracking application to update the task entry.

9. The method according to claim 8, further comprising: upon receiving the notification, sending a second instruction to the work tracking application to create a task entry for the change; as well as If it is determined that the automatic incorporation was unsuccessful, a third indication is sent to the work tracking application to initiate notification to the individual.

10. The method according to claim 9, further comprising: enabling said individual to incorporate said changes when it is determined that said automatic incorporation is unsuccessful; as well as After determining that the manual incorporation is complete, the work tracking application is notified to automatically update the task entry.

11. The method according to claim 8, wherein: Identifying the second branch includes: identifying one or more main branches of the source code configuration; examining the identified main branches to identify an active branch among the identified main branches; checking the identified active branches to detect branches created in the source code configuration after the first branch; comparing the source code of the detected branch with the source code of a merge root of the first branch of the source code and the main branch to determine whether there is a difference between the detected branch and the merge root; and Any branch identified as having a difference is designated as the second branch.

12. An apparatus for merging source code changes made in a second branch of a source code configuration into a first branch of the source code configuration, comprising: processor; as well as A memory in communication with the processor, the memory comprising executable instructions, which when executed by the processor, cause the device to perform the following functions: receiving a notification from an issue tracking application via a network, the notification indicating that a first branch was created in a source code configuration, and the notification being sent by the issue tracking application after receiving information from a source repository server; identifying a second branch created in the source code configuration before the first branch; determining whether changes have been made to the second branch after the first branch was created; After determining that the change is made to the second branch, determining whether the change exists in the first branch; After determining that the change does not exist in the first branch, the change is automatically merged into the first branch.

13. The device according to claim 12, wherein: The instructions further cause the programmable device to perform the following functions: after determining that the change does not exist in the first branch, send a first indication to a work tracking application to create a task entry for the change, and assign the task entry to an individual.

14. The device according to claim 13, wherein: The instructions further cause the programmable device to perform the following functions: if it is determined that automatically incorporating the change into the first branch is unsuccessful, send a second indication to the work tracking application to notify the individual.

15. The apparatus according to claim 12, wherein: Identifying the second branch includes: identifying one or more main branches of the source code configuration; examining the identified main branches to identify an active branch among the identified main branches; The identified active branches are examined to detect branches created in the source code configuration prior to the first branch.

Images