Systems and methods for software build file analytics

The present approach relates generally to systems and methods for generating a hierarchical model of a plurality of software development streams, identifying points of interest on the plurality of software development streams having a status indication, and determining descendant development streams corresponding to the points of interest. The present approach also relates to systems and methods for traversing the descendant development streams sequentially in descending order of creation date of the points of interest corresponding to the descendant development streams, determining a software build file status indication for software build files associated with the descendant development streams based at least on the status indication of the points of interest, and evaluating the software build file status indication for the software build files to generate an indication of a first subset of build files having an unfixed status indication and a second subset of build files having a fixed status indication.

BACKGROUND

The present disclosure relates generally to the analysis of software development branches.

Enterprises and other organizations may develop various applications (e.g., software) that may be licensed or sold to other entities and implemented on various types of computational systems. Such applications may be implemented using executable computer code (e.g., a script) that may be changed or further developed (e.g., updated, modified) over time. In this manner, developers are able to modify a version of the application to meet additional needs or purposes identified by the organization or entity using the application. The modified computer code (e.g., a subsequent version of the application) may therefore include augmentations to the original computer code of the application.

In many cases, the computer code of the application may be developed on one or more software development streams that enable developers to modify a version or multiple versions of the computer code without disrupting operation of a previously released version of the application. As a result, developers may support various software builds or patches in parallel, each corresponding to different versions of the application that may include, for example, certain feature releases, hotfix releases, and/or patch releases. In some cases, certain of the released versions may contain software bugs discovered subsequent to the release of the versions. Such software bugs may cause certain versions of the application affected with the software bug to run suboptimally or execute instructions in a manner other than intended. Unfortunately, in the diverse array of software build files created for an application, it may be difficult to determine which of the created software build files are affected with a particular software bug and which remain unaffected.

SUMMARY

The present approach relates generally to systems and methods for identifying versions of an application that may include a particular software bug and distinguishing these versions from other versions of the application where the software bug is resolved or presumed resolved. More specifically, embodiments of the present disclosure are directed to a processor-executable algorithm for predicting an unknown status indication of certain software build files based on a known status indication of chronologically preceding software build files and/or code commits present on a software development stream of the software build files. As discussed herein, the processor-executable algorithm may inspect ancestral software build files or code commits of an application to generate an indication of whether descendant software build files of the application are affected with a particular software bug. In particular, based on an evaluation of points of interest included on the software development stream(s) of the application, the algorithm may assign an “affected” status indication to software build files having the software bug or software build files presumed to have the software bug. Conversely, the algorithm may assign an “unaffected” status indication to software build files in which a detected software bug has been previously resolved (e.g., a developer has manually committed code to the software build file to resolve the software bug) or software build files where the software bug is presumed to be resolved. As such, the processor-executable algorithm may identify a subset of software build files of the application where the software bug is present, or presumed present, and a subset of software build files of the application where the software bug is resolved, or presumed resolved. Accordingly, when an entity encounters a software bug in particular version (e.g., a particular released software build file) of the application, the processor-executable algorithm may be used to facilitate an identification of compatible versions of the application in which the software bug is resolved or presumed resolved. The processor-executable algorithm may therefore significantly reduce a time period that is typically involved for a service agent to locate versions of an application that do not contain a particular software bug or software abnormality identified by an entity. These and other features will be described below with reference to the drawings.

DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS

As used herein, the term “computing system” refers to an electronic computing device such as, but not limited to, a single computer, virtual machine, virtual container, host, server, laptop, and/or mobile device, or to a plurality of electronic computing devices working together to perform the function described as being performed on or by the computing system. In some embodiments, the computing system may employ any suitable circuitry, such as a processor-based device, memory devices, storage devices, and the like. As used herein, the term “medium” refers to one or more non-transitory, computer-readable physical media that together store the contents described as being stored thereon. Embodiments may include non-volatile secondary storage, read-only memory (ROM), and/or random-access memory (RAM). As used herein, the term “application” refers to one or more computing modules, programs, processes, workloads, threads and/or a set of computing instructions executed by a computing system. Example embodiments of an application include software modules, software objects, software instances and/or other types of executable code.

Furthermore, as used herein, the term “branch” refers to a discrete stream of software development corresponding to developer efforts to modify or augment computer code (e.g., a script) of an application. That is, a branch may enable developers to release feature releases, patch releases, and/or hotfix releases of an application without interrupting operation of previous versions of the application that may reside on separate development branches. As used herein, a “master branch” refers to a stream of software development originating from an original (e.g., unmodified) software build file containing initial source code of an application. As used herein, a “branchpoint” refers to a divergence of a software development stream (e.g., a descendant software development stream) from a parent software development stream (e.g., the master branch). As used herein, “datetime” refers to an index of creation date information of a particular software build file or software development (e.g., a branchpoint) on a software development stream. As an example, the datetime of a particular branchpoint may include the calendar date and time at which a particular development stream branches (e.g., diverges) from a parent development stream.

As used herein, a “code commit” refers to a set of changes in source code applied to a particular software development stream. In some cases, a code commit on a software development stream may not be released to an entity until after creation of a software build file (e.g., a build file) on the software development stream having the code commit. For clarity, as used herein, a “build file” refers to a software build or executable file created using the source code of an application on a particular software development stream and at a particular datetime. For example, a build file on a software development stream (e.g., a software development branch) may contain some or all chronologically preceding code commits made on that software development stream before release of the build file. Accordingly, a build file may be indicative of a version of the application that corresponds to a particular state of the computer code released at the datetime of the build file.

In addition, as used herein, a “point of interest” refers to a branchpoint, a code commit, and/or a build file present on a software development stream. In some cases, each of the points of interest may be associated with an affected or unfixed status indication (e.g., the point of interest includes or presumably includes a particular software bug) or an unaffected or fixed status indication (e.g., the point of interest is void or presumably void of a particular software bug), or the points of interest may be void of a status indication (e.g., it is unknown where the point of interest includes or does not include a particular software bug). As an example, the points of interest may have a “build file affected” status (e.g., a build file having an affected status indication), which refers to a build file of a version of an application where a particular issue (e.g., a software bug) is identified as being present. The points of interest may additionally include “fix targets” (e.g., build files having an unaffected status indication), which refer to build files where a developer has specified intent to fix a particular software bug and/or the developer has fixed the software bug.

With the preceding in mind, and by way of context, the following figures relate to various types of generalized system architectures or configurations that may be employed to provide services to an organization in a multi-instance framework and on which the present approaches may be employed. Correspondingly, these system and platform examples may also relate to systems and platforms on which the techniques discussed herein may be implemented or otherwise utilized. It should be understood, however, that the present approach may be performed on other computer-based platforms or frameworks, including non-cloud and/or non-instance based platforms.

Turning now toFIG. 1, a block diagram of an embodiment of a cloud computing system10where embodiments of the present disclosure may operate, is illustrated. Cloud computing system10may include a client network12, network18(e.g., the Internet), and a cloud-based platform20. In some implementations, the cloud-based platform may be a configuration management database (CMDB) platform. In one embodiment, the client network12may be a local private network, such as local area network (LAN) having a variety of network devices that include, but are not limited to, switches, servers, and routers. In another embodiment, the client network12represents an enterprise network that could include one or more LANs, virtual networks, data centers22, and/or other remote networks. As shown inFIG. 1, the client network12is able to connect to one or more client devices14A,14B, and14C so that the client devices are able to communicate with each other and/or with the network hosting the platform20. The client devices14A-C may be computing systems and/or other types of computing devices generally referred to as Internet of Things (IoT) devices that access cloud computing services, for example, via a web browser application or via an edge device16that may act as a gateway between the client devices and the platform20.FIG. 1also illustrates that the client network12includes a bridge device or server, such as a management, instrumentation, and discovery (MID) server17that facilitates communication of data between the network hosting the platform20, other external applications, data sources, and services, and the client network12. Although not specifically illustrated inFIG. 1, the client network12may also include a connecting network device (e.g., a gateway or router) or a combination of devices that implement a customer firewall or intrusion protection system.

For the illustrated embodiment,FIG. 1illustrates that client network12is coupled to a network18. The network18may include one or more computing networks, such as other LANs, wide area networks (WAN), the Internet, and/or other remote networks, to transfer data between the client devices14A-C and the network hosting the platform20. Each of the computing networks within network18may contain wired and/or wireless programmable devices that operate in the electrical and/or optical domain. For example, network18may include wireless networks, such as cellular networks (e.g., Global System for Mobile Communications (GSM) based cellular network), IEEE 802.11 networks, and/or other suitable radio-based networks. The network18may also employ any number of network communication protocols, such as Transmission Control Protocol (TCP) and Internet Protocol (IP). Although not explicitly shown inFIG. 1, network18may include a variety of network devices, such as servers, routers, network switches, and/or other network hardware devices configured to transport data over the network18.

InFIG. 1, the network hosting the platform20may be a remote network (e.g., a cloud network) that is able to communicate with the client devices14A-C via the client network12and network18. The network hosting the platform20provides additional computing resources to the client devices14A-C and/or client network12. For example, by utilizing the network hosting the platform20, users of client devices14A-C are able to build and execute applications for various enterprise, IT, and/or other organization-related functions. In one embodiment, the network hosting the platform20is implemented on one or more data centers22, where each data center could correspond to a different geographic location. Each of the data centers22includes a plurality of virtual servers24(which may be referenced herein as application nodes, application servers, virtual server instances, application instances, or application server instances), where each virtual server can be implemented on a physical computing system, such as a single electronic computing device (e.g., a single physical hardware server) or across multiple-computing devices (e.g., multiple physical hardware servers). Examples of virtual servers24include, but are not limited to a web server (e.g., a unitary web server installation), an application server (e.g., unitary JAVA Virtual Machine), and/or a database server, e.g., a unitary relational database management system (RDBMS) catalog.

To utilize computing resources within the platform20, network operators may choose to configure the data centers22using a variety of computing infrastructures. In one embodiment, one or more of the data centers22are configured using a multi-tenant cloud architecture, such that one of the server instances24handles requests from and serves multiple customers. Data centers with multi-tenant cloud architecture commingle and store data from multiple customers, where multiple customer instances are assigned to one of the virtual servers24. In a multi-tenant cloud architecture, the particular virtual server24distinguishes between and segregates data and other information of the various customers. For example, a multi-tenant cloud architecture could assign a particular identifier for each customer in order to identify and segregate the data from each customer. Generally, implementing a multi-tenant cloud architecture may suffer from certain drawbacks, such as a failure of a particular one of the server instances24causing outages for all customers allocated to the particular server instance.

In another embodiment, one or more of the data centers22are configured using a multi-instance cloud architecture to provide every customer its own unique customer instance or instances. For example, a multi-instance cloud architecture could provide each customer instance with its own dedicated application server(s) and dedicated database server(s). In other examples, the multi-instance cloud architecture could deploy a single physical or virtual server and/or other combinations of physical and/or virtual servers24, such as one or more dedicated web servers, one or more dedicated application servers, and one or more database servers, for each customer instance. In a multi-instance cloud architecture, multiple customer instances could be installed on one or more respective hardware servers, where each customer instance is allocated certain portions of the physical server resources, such as computing memory, storage, and processing power. By doing so, each customer instance has its own unique software stack that provides the benefit of data isolation, relatively less downtime for customers to access the platform20, and customer-driven upgrade schedules. An example of implementing a customer instance within a multi-instance cloud architecture will be discussed in more detail below with reference toFIG. 2.

FIG. 2is a schematic diagram of an embodiment of a multi-instance cloud architecture40where embodiments of the present disclosure may operate.FIG. 2illustrates that the multi-instance cloud architecture40includes the client network12and the network18that connect to two (e.g., paired) data centers22A and22B that may be geographically separated from one another. UsingFIG. 2as an example, network environment and service provider cloud infrastructure client instance42(also referred to herein as a client instance42) is associated with (e.g., supported and enabled by) dedicated virtual servers (e.g., virtual servers24A,24B,24C, and24D) and dedicated database servers (e.g., virtual database servers44A and44B). Stated another way, the virtual servers24A-24D and virtual database servers44A and44B are not shared with other client instances and are specific to the respective client instance42. In the depicted example, to facilitate availability of the client instance42, the virtual servers24A-24D and virtual database servers44A and44B are allocated to two different data centers22A and22B so that one of the data centers22acts as a backup data center. Other embodiments of the multi-instance cloud architecture40could include other types of dedicated virtual servers, such as a web server. For example, the client instance42could be associated with (e.g., supported and enabled by) the dedicated virtual servers24A-24D, dedicated virtual database servers44A and44B, and additional dedicated virtual web servers (not shown inFIG. 2).

AlthoughFIGS. 1 and 2illustrate specific embodiments of a cloud computing system10and a multi-instance cloud architecture40, respectively, the disclosure is not limited to the specific embodiments illustrated inFIGS. 1 and 2. For instance, althoughFIG. 1illustrates that the platform20is implemented using data centers, other embodiments of the platform20are not limited to data centers and can utilize other types of remote network infrastructures. Moreover, other embodiments of the present disclosure may combine one or more different virtual servers into a single virtual server or, conversely, perform operations attributed to a single virtual server using multiple virtual servers. For example, usingFIG. 2as an example, the virtual servers24A-D and virtual database servers44A and44B may be combined into a single virtual server. Moreover, the present approaches may be implemented in other architectures or configurations, including, but not limited to, multi-tenant architectures, generalized client/server implementations, and/or even on a single physical processor-based device configured to perform some or all of the operations discussed herein. Similarly, though virtual servers or machines may be referenced to facilitate discussion of an implementation, physical servers may instead be employed as appropriate. The use and discussion ofFIGS. 1 and 2are only examples to facilitate ease of description and explanation and are not intended to limit the disclosure to the specific examples illustrated therein.

As may be appreciated, the respective architectures and frameworks discussed with respect toFIGS. 1 and 2incorporate computing systems of various types (e.g., servers, workstations, client devices, laptops, tablet computers, cellular telephones, and so forth) throughout. For the sake of completeness, a brief, high level overview of components typically found in such systems is provided. As may be appreciated, the present overview is intended to merely provide a high-level, generalized view of components typical in such computing systems and should not be viewed as limiting in terms of components discussed or omitted from discussion.

With this in mind, and by way of background, it may be appreciated that the present approach may be implemented using one or more processor-based systems such as shown inFIG. 3. Likewise, applications and/or databases utilized in the present approach may be stored, employed, and/or maintained on such processor-based systems. As may be appreciated, such systems as shown inFIG. 3may be present in a distributed computing environment, a networked environment, or other multi-computer platform or architecture. Likewise, systems such as that shown inFIG. 3, may be used in supporting or communicating with one or more virtual environments or computational instances on which the present approach may be implemented.

With this in mind, an example computer system may include some or all of the computer components depicted inFIG. 3and may be present in the embodiments ofFIGS. 1 and 2.FIG. 3generally illustrates a block diagram of example components of a computing system80and their potential interconnections or communication paths, such as along one or more busses84. As illustrated, the computing system80may include various hardware components such as, but not limited to, one or more processors82, one or more busses84, memory86, input devices88, a power source90, a network interface92, a user interface94, and/or other computer components useful in performing the functions described herein. The one or more processors82may include one or more microprocessors capable of performing instructions stored in the memory86. Additionally or alternatively, the one or more processors82may include application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and/or other devices designed to perform some or all of the functions discussed herein without calling instructions from the memory86.

With respect to other components, the one or more busses84includes suitable electrical channels to provide data and/or power between the various components of the computing system80. The memory86may include any tangible, non-transitory, and computer-readable storage media. Although shown as a single block inFIG. 1, the memory86can be implemented using multiple physical units of the same or different types in one or more physical locations. The input devices88correspond to structures to input data and/or commands to the one or more processor82. For example, the input devices88may include a mouse, touchpad, touchscreen, keyboard and the like. The power source90can be any suitable source for power of the various components of the computing system80, such as line power and/or a battery source. The network interface92includes one or more transceivers capable of communicating with other devices over one or more networks (e.g., a communication channel). The network interface92may provide a wired network interface or a wireless network interface. A user interface94may include a display that is configured to display text or images transferred to it from the one or more processors82. In addition and/or alternative to the display, the user interface94may include other devices for interfacing with a user, such as lights (e.g., LEDs), speakers, and the like.

As noted above, an enterprise or other organization may develop and release various versions of an application for use on any of the aforementioned computing systems. In some cases, an enterprise may modify previous versions of an application to add or modify functionality, to resolve bugs or other error conditions, to optimize performance and/or resource utilization, and so forth. As described in detail below, several versions of an application may be developed in parallel on different software developments streams that branch from an initial, master software build file containing original (e.g., unmodified) source code of the application. Accordingly, the alteration of the source code on these individual software development streams may enable developers to generate various versions of an application while operation of previous versions of the application remains unaffected. That is, operation of a previous version of an application may still be supported even though developers make code commits or other code augmentations to the source code of subsequent versions of the application.

With the foregoing in mind,FIG. 4is a graphical illustration of an example of a branch-build timeline100(e.g., a multi-branched code development timeline) depicting an interrelationship between a plurality of software development streams102(e.g., software development branches) that illustrate development of an application over time. For example, a master software development stream, also referred to herein as a master branch104, may originate from a master software build file106that contains original source code (e.g., unmodified source code) of an application. That is, in some embodiments, the master software build file106may be indicative of an initial version (e.g., a first version) of an application made available to an entity as part of a sale, licensing arrangement, or other distribution scheme. A plurality of descendant development streams108(e.g., descendant software development streams, descendant branches) may diverge from the master branch104to indicate parallel development and modification of the application source code. In other words, code in the descendant development streams108may be modified independently of the source code in the master branch104and of other development branches. In this manner, modifications to the source code on the descendant development streams108may not affect a state of the source code on the master branch104or other development branches.

The descendant development streams108may diverge from the master branch104at respective branchpoints110. Each of the branchpoints110may have corresponding datetime information that is indicative of a creation date of a particular descendant development stream108. For sake of example, the illustrated embodiment of the branch-build timeline100includes three descendant development streams108that descend from the master branch104. In particular, the descendant development streams108include a first descendant development stream112(e.g., development branch “J”), a second descendant development stream114(e.g., development branch “K”), and a third descendant development stream116(e.g., development branch “L”), which diverge from the master branch104at a first branchpoint118, a second branchpoint120, and a third branchpoint122, respectively. The first, the second, and the third branchpoints118,120,122are situated on the master branch104based on their respective datetime information, with the passage of time indicated in a left to right direction. That is, a location of the branchpoints110along the branch-build timeline100may be indicative of a creation date of the branchpoints110, where branchpoints110near an initiating end130of the branch-build timeline100have a creation date preceding a creating date of branchpoints110near a terminal end132of the branch-build timeline100. Therefore, in the present example, the first descendant development stream112antedates the second descendant development stream114, and the second descendant development stream114antedates the third descendant development stream116. For clarity, a development stream or branch from which a descendant development stream diverges is referred to herein as the “parent branch” of that particular descendant development stream. Accordingly, in the aforementioned example, the master branch104is a parent branch of the first, the second, and the third descendant development streams112,114,116.

Each of the descendant development streams108may also include one or more development streams descending therefrom (e.g., secondary descendent development streams). Accordingly, the descendant development streams108may be parent branches to these secondary descendant development streams. For example, in the illustrated embodiment, the second descendant development stream114includes three secondary descendant development streams134(e.g., development branch “KP1”, development branch “KP2”, and development branch “KP3”) extending from the second descendant development stream114at respective secondary branchpoints135. In addition, a tertiary development stream136(e.g., development branch “KP1 HF1”) extends from a first of the three secondary descendant development streams134at a corresponding tertiary branchpoint137. It should be noted that the branch-build timeline100is shown by way of example only, and may include any suitable quantity and arrangement of branch points110.

As shown in the illustrated embodiment, a plurality of build files140(e.g., build file “Master B1”, build file “Master B2”, build file “LP1 B1”, build file “KP1 B1”, build file “KP1 HF1 B1”, build file “KP2 B2”, build file “K B1”, build file “JP1 B1”) and code commits142(e.g., code commit “c1”, code commit “c2”) are represented on the branch-build timeline100and situated on certain of the software development streams102. Build files140and the code commits142are associated with respective datetime information that is indicative of a creation date of the build files140and a creation date of the code commits142. Similar to the branchpoints110discussed above, build files140and code commits142situated near the initiating end130of the branch-build timeline100have a creation date that precedes a creation date of build files140and code commits142situated near the terminal end132of the branch-build timeline100. Accordingly, a position of the build files140and the code commits142along the branch-build timeline100may be indicative of a creation date of the build files140and the code commits142. The branchpoints110, the build files140, and the code commits142are collectively referred to herein as “points of interest” of the branch-build timeline100.

As noted above, the build files140may define software code builds (e.g., upgrades, product releases, hotfix patches) that are created on a particular software development stream or branch, which may be released to an entity as a version of an application. Specifically, the build files140may include all of the original source code of an application and any alterations to the source code included in an ancestral lineage of the build files140. As used herein, an “ancestral lineage” of a build file refers to the source code and code commits included in a development stream associated with the build file that precede a creation date of the build file. As an example, an ancestral lineage of a first master build file144(e.g., build file “Master B1”) created on the master branch104may include all of the code commits142(e.g., additions, deletions, and/or modifications to the source code) made to the master branch104prior to the creation date of the first master build file144. As such, the first master build file144defines a software code build (e.g., an individual version) of the application that contains the source code, as well as certain of the code commits142made to the source code on the master branch104prior to the creation of the first master build file144.

As an additional clarifying example, on the master branch104, a code commit146(e.g., code commit “c2”) made to the source code after creation of the first master build file144(e.g., build file “Master B1”) is not included in the first master build file144because the first master build file144antedates the code commit146(e.g., a datetime of the first master build file144precedes a datetime of the code commit142). However, because the code commit142was made prior to the creation of a second master build file148on the master branch104, the code commit142may be included in the second master build file148because the code commit146is present on an ancestral lineage of the second master build file148(e.g., a datetime of the code commit146precedes a datetime of the second master build file148).

In certain cases, entities using the application may discover errors or other problems (e.g., software bugs) occurring during operation of certain versions of the application (e.g., certain released build files140of the application). In some embodiments, a service agent may be notified of a software bug within a particular build file140and may thus impart a status indication to that particular build file140indicating a presence of the software bug. Specifically, the service agent may associate the build file140with an “affected” status indication, thereby identifying the build file140as a build file that is affected by a particular software bug. Accordingly, certain of the build files140affected with a software bug, referred to herein as “build files affected,” may be differentiated from other build files140(e.g., other versions of the application) in which the software bug has not been reported.

For sake of example, in the illustrated embodiment ofFIG. 4, of the eight build files140(e.g., build file “Master B1”, build file “Master B2”, build file “LP1 B1”, build file “KP1 B1”, build file “KP1 HF1 B1”, build file “KP2 B2”, build file “K B1”, build file “JP1 B1”) included in the branch-build timeline100, a first build file affected150(e.g., build file “K B1”) and a second build file affected152(e.g., build file “KP1 B1) are shown as having a status indication of “affected.” In other words, entities have reported a particular software bug as being present in these version (e.g., build files140) of the application. The remaining build files140will be referred to herein as neutral build files154, which are void of a status indication. It should be noted that in some circumstances the neutral build files154may actually be void of a software bug. However, in other circumstances the neutral build files154may include the respective software bug but it has not yet been discovered or confirmed by an entity and/or a service agent. That is, upon discovery of a software bug within a neutral build file154, the neutral build file154status may be changed to indicate that the build file is affected and, therefore, associated with an affected status indication (e.g., an unfixed status indication).

In some embodiments, after receiving an indication of a software bug in a particular build file140, developers and/or service agents may resolve the identified software bug by, for example, entering code commits to the affected build file along a given software development stream102. That is, a developer may fix an error (e.g., a software bug) in a build file affected, or preemptively fix a known error in a build file that has not yet been released. In such embodiments, the build files140in which a software bug has been resolved will receive an “unaffected” status indication. For clarity, a build file for which the developer has an intent to present a fix to a known issue is referred to herein as a “fix target.” Subsequent to the release of that build file, it may be assumed that the issue is fixed or resolved within that development stream. In the present example, a build file of the second descendant development stream114is indicated as a fix target156(e.g., build file “KP2 B2”), indicating that a developer or service agent has fixed a software bug identified in this build file or preemptively fixed a known software bug. A fix target made to a particular development branch may be presumed to resolve the software bug in all build files created on that development branch after the datetime of the fix target, as well as any build files created on branches descending from the development branch after the datetime of the fix target unless otherwise indicated, as discussed in detail below.

In some embodiments, developers may also attempt to fix a known issue or software bug in a build file by way of a code commit that is made to a software development stream, rather than directly to a particular one of the build files140. As discussed in greater detail below, code commits made to a particular software development stream may be presumed to resolve a software bug in build files of all branches downstream from the code commit. In other words, build files within an ancestral lineage having a code commit may be presumed as having an “unaffected” status indication. However, in some cases, the code commits142may not resolve the software bug, or may introduce another software bug in descendant build files, as discussed in detail below.

Unfortunately, with the existence of multiple, parallel software development streams102and versions of the application, it may be difficult and time consuming to determine which of the build files140may include a particular software bug (e.g., which of the build files140have an affected status or an unfixed status) and which of the build files140do not include the software bug (e.g., which of the build files140have an unaffected status or a fixed status). For example, an entity may identify a software bug in a particular version of the application, and indicate interest to upgrade to an alternate version of the application where the software bug has been resolved. However, in some case, certain alternate versions of the application may include the same software bug identified by the entity in the version currently being used by the entity. Accordingly, it may be difficult for a service agent to recommend a suitable version of an application to which an entity may upgrade to resolve the issue (e.g., software bug) identified in a current version of the application purchased or licensed by the entity.

Accordingly, embodiments of the present disclosure are directed toward a processor-executable algorithm that may be implemented by any of the aforementioned computing systems and used to identify and/or predict which version(s) of an application may have a specific software bug based on an analysis of the points of interest on the branch-build timeline100. More specifically, as discussed in detail herein, the algorithm may extrapolate status indication information of the points of interest to predict which versions of an application are likely to have a particular software bug present, and on which versions the software bug is resolved or likely to be resolved. In this manner, the algorithm may facilitate determining which version of an application an entity should upgrade to in order to resolve a particular software bug currently experienced by the entity.

With the preceding in mind, to initiate the analysis of the branch-build timeline100, the algorithm may generate a hierarchical nodal model of all points of interest included in the branch-build timeline100. In particular, the algorithm may sequentially traverse each of the software development streams102to identify datetime information of the points of interest, generate nodes on the hierarchical nodal model corresponding to the points of interest, and catalogue the generated nodes based on the ancestral relationships of the points of interest. In this manner, the algorithm may generate a hierarchical nodal model where nodes corresponding to points of interest created on descendant software development streams (e.g., the descendant development streams108) descend from nodes corresponding to points of interest created on parent software development streams (e.g., the master branch104).

For example, in some embodiments, the algorithm may initiate construction of the hierarchical nodal model by traversing the points of interest on the master branch104in ascending chronological order. In this manner, the algorithm may catalogue and organize the points of interest along the master branch104in a hierarchical relationship based on a creation date of the points of interest. Specifically, the algorithm may assign indices to each of the nodes generated for particular points of interest, which may be used to organize the nodes based on the respective creation dates of the corresponding points of interest. To help illustrate,FIG. 5is an embodiment of a portion158of a hierarchical nodal model160(as shown completed inFIG. 6) of the branch-build timeline100, which may be generated as the algorithm traverses the master branch104. To facilitate the following discussion, it should be noted thatFIGS. 4 and 5will be referenced interchangeably.

As shown in the illustrated embodiment ofFIG. 5, to generate the hierarchical nodal model160, the algorithm may first generate a master node164that corresponds to the master software build file106of the master branch104. The algorithm assigns a left index value166to the master node164, which may include a predetermined integer value (e.g., “100”). The algorithm may also associate the master node164with the datetime information of the master software build file106, such that the datetime information of the master software build file106is stored in the master node164(e.g., within a table entry associated with the master node164). The algorithm continues traversing the points of interest on the master branch104in ascending order of creation date until a termination167(e.g., an end point) of the master branch104is reached. While traversing the master branch104, the algorithm creates sequentially descending nodes on the hierarchical nodal model160corresponding to each of the points of interest traversed along the master branch104. Specifically, the algorithm creates a first branch node168, a second branch node170, a first build node172, a third branch node174, and a second build node176, which are associated with the first branchpoint118, the second branchpoint120, the first master build file144, the third branchpoint122, and the second master build file148, respectively. As shown in the illustrated embodiment ofFIG. 5, an ancestral relationship of the nodes is determined based on a creation date of the respective points of interest, such that ancestor nodes (e.g., parent nodes) correspond to points of interest having a creation date that precedes a creation date of points of interest corresponding to descendant nodes (e.g., child nodes).

A left index value178is assigned to each of the generated nodes of the hierarchical nodal model160. The left index value178of a child node may be indicative of a left index value (e.g., “n”) of a parent node increased by a predetermined integer value (e.g., “n+100”). Accordingly, a left index value of child nodes (e.g., descendant nodes) is greater than a left index value of parent nodes (e.g., ancestor nodes) by a predetermined amount (e.g., an integer interval of “100”). As an example, the algorithm may assign the left index value166of the master node164, and the left index values178the first branch node168, the second branch node170, the first build node172, the third branch node174, and the second build node176, with integer values of “100”, “200”, “300”, “400”, “500”, and “600”, respectively.

Upon reaching the termination167of the master branch104, the algorithm begins traversing the points of interest on the master branch104in descending order of creation date until a branchpoint on the master branch104is reached. The algorithm assigns a right index value to nodes of the hierarchical nodal model160that correspond to points of interest traversed in descending order of creation date. For example, in the exemplary embodiment of the branch-build timeline100discussed herein, the algorithm assigns a right index value182(e.g., “700”) to the second build node176, which is the only point of interest traversed in descending order of creation date along the master branch104before a branchpoint (e.g., the third branchpoint122) is reached.

Upon reaching the third branchpoint122, the algorithm traverses all descendant development streams descending from the third descendant development stream116and generates nodes on the hierarchical nodal model160corresponding to any identified points of interest. The generated nodes will each descend from the third branch node174of the hierarchical nodal model160. The algorithm traverses the third descendant development116stream in the same manner as the traversal of the master branch104. That is, the algorithm traverses the points of interest on the third descendant development stream116in ascending order of creation date until a terminal end183of the third descendant development stream116is reached and generates sequentially descending nodes corresponding to the traversed points of interest on the hierarchical nodal model160. For example, in the illustrated embodiment, the algorithm generates a branch node (e.g., a fourth branch node188) corresponding to a branchpoint190of the third descendant development stream116. The fourth branch node188descends from the third branch node174and is assigned a left index value199(e.g., “800”) that is increased by the predetermined integer amount (e.g., “100”) from a previously assigned index value (e.g., the right index value182) of the previously generated node (e.g., the second build node176) on the hierarchical nodal model160.

Upon reaching the terminal end183of the third descending development stream116, the algorithm traverses the points of interest on the third descendant development stream116in descending chronological order until reaching a branchpoint (e.g., the branchpoint190). The algorithm traverses all points of interest created along the development stream descending from the branchpoint190until reaching a terminal end of this descendant development stream. The algorithm generates nodes corresponding to the traversed points of interest and assigns corresponding left index values194and right index values196to the generated nodes in accordance with the techniques discussed above. Upon returning to the third branchpoint122on the branch-build timeline100, the algorithm assigns a right index value198to the third branch node174, and continues traversing the points of interest along the master branch104in descending chronological order in accordance with the aforementioned techniques.

The algorithm iteratively repeats this process for each descendant development stream (e.g., the second descendant development stream114, the first descendant development stream112) of the master branch104. Accordingly, the algorithm may generate the hierarchical nodal model160in which each of the points of interest of the branch-build timeline100are catalogued in a hierarchical manner based on an ancestral lineage of the points of interest on the software development streams102. Accordingly, the hierarchical nodal model160may facilitate the identification of ancestral nodes and/or descendant nodes corresponding to a particular point of interest.FIG. 6is an embodiment of the hierarchical nodal model160generated after the algorithm traverses all development streams of the branch-build timeline100.

Upon generating the hierarchical nodal model160, the algorithm iteratively traverses the points of interest on the branch-build timeline100in descending order of creation date to determine a status indication for certain nodes of the hierarchical nodal model160based on a status indication of the traversed points of interest. As described in greater detail below, in this manner, the algorithm may predict and identify versions (e.g., build files140corresponding to software build files) of the application in which a software bug is likely present, or presumed to be present, as well as identify versions of the application that are likely void of the software bug, or presumed to be void of the software bug.

FIG. 7is a flow diagram of an embodiment of a process200that may be performed by a suitable computing system implementing the present algorithm to identify versions of an application having particular software bugs. It should be noted that the steps illustrated in the process200are meant to facilitate discussion and are not intended to limit the scope of this disclosure, since additional steps may be performed, certain steps may be omitted, and the illustrated steps may be performed in any order. Moreover, to help illustrate the iterative approach of the present algorithm, the following discussion will referenceFIGS. 4 and 8-11interchangeably.

With the preceding in mind, the process200may begin with identifying which of the points of interest on the branch-build timeline100having a status indication is associated with a most recent datetime, as indicated by step202. This point of interest with a status indication and having an earliest relative creation date will be referred to herein as a “commencement point of interest (POI).” Accordingly, a commencement POI may include a build file affected, a fix target, or a code commit made on any of the software development streams102, as each of these points of interest are associated with a respective status indication. It is important to note the algorithm may not select points of interest without an associated status indication, such as the neutral build files154, which are void of a status indication, as the commencement POI. Accordingly, it should be appreciated that the algorithm may disregard certain points of interest absent of a status indication (e.g., neutral build files154), even if these points of interest have a datetime preceding to a datetime of commencement POI.

Upon identification of the commencement POI, the algorithm assigns the status indication of the commencement POI to a previously generated node of the hierarchical nodal model160that corresponds to the commencement POI, as indicated by process block204. That is, if the commencement POI is a build file affected, the algorithm will assign the node corresponding to this commencement POI with an affected status indication. Conversely, if the commencement POI is a fix target, the algorithm will assign the node corresponding to this commencement POI with an unaffected status indication. Regardless, the algorithm also assigns the status indication of the commencement POI to any nodes of the hierarchical nodal model160descending from the node corresponding to the commencement POI.

For example, as shown in the illustrated embodiment ofFIG. 4, the commencement POI of the exemplary branch-build timeline100is the first build file affected150(e.g., build file “K B1”). Accordingly, upon identification of this commencement POI, the algorithm assigns an affected status indication to a previously generated node of the hierarchical nodal model160that corresponds to the commencement POI. That is, in the present example, the algorithm assigns an affected status indication to a node208corresponding to the first build file affected150, as shown in the illustrated embodiment of the hierarchical nodal model160ofFIG. 8. For clarity, the node208will be referred to herein as a first status node208.

As discussed above, it should be noted that code commits created on the branch-build timeline100are not represented as nodes on the hierarchical nodal model160. Accordingly, for a particular code commit, the algorithm assumes that a point of interest on the same branch as the code commit with a datetime immediately consecutive to a datetime of the code commit has an unaffected status indication, if this point of interest has no previously assigned status indication. That is, if the point of interest immediately consecutive to the code commit has no previously assigned status indication, the algorithm propagates an unaffected status indication to this point of interest.

As an example, if a point of interest on the same branch as a particular code commit, with a datetime immediately consecutive to a datetime of the code commit, is a branchpoint or a neutral build file, the algorithm will assume that this branchpoint or neutral build file has an unaffected status indication, because a status indication of these points of interest is determined based on a status indication of a preceding point of interest on the branch-build timeline100having a status indication (e.g., a build file affected, a fix target, or a code commit). However, as discussed in detail below, if a point of interest on the same branch as the code commit, with a datetime immediately consecutive to a datetime of the code commit, already has an assigned status indication, the algorithm will not propagate an unaffected status indication to this point of interest. For example, if a point of interest on the same branch as a particular code commit with a datetime immediately consecutive to a datetime of the code commit is a build file affected, the algorithm will not adjust the affected status indication associated with the build file affected to an unaffected status indication.

As such, if a code commit is identified as the commencement POI (e.g., meaning that any point of interest chronologically consecutive to the code commit is void of a status indication), the algorithm will assign an unaffected status indication to all points of interest created on branches of the branch-build timeline100descending from the code commit. In addition, the algorithm will assign an unaffected status indication to all nodes of the hierarchical nodal model160corresponding to the point of interests chronologically consecutive to the code commit.

Therefore, in any case, upon assigning a status indication to a node of the hierarchical nodal model160associated with the commencement POI, the algorithm assigns all nodes that may be descending from this node with the same status indication of the commencement POI. As shown in the illustrated embodiment ofFIG. 8, because the first status node208(e.g., the node corresponding to the commencement POI, the node corresponding to the first build file affected150) does not have any nodes descending therefore, the algorithm only assigns an affected status indication (e.g., the status indication of the first build file affected150) to the first status node208.

The algorithm generates and maintains a memory table or a list indicative of the nodes of the hierarchical nodal model160the algorithm has visited, as indicated by step205. That is, upon assigning a status indication to a particular node (e.g., the first status node208) of the hierarchical nodal model160, the algorithm may store this node as a “visited” node in such a memory table. In some embodiments, the algorithm may index the node(s) stored in the memory table based on the left or right index values of the node(s). Further, in embodiments where the algorithm assigns a status indication to one or more nodes descending from, for example, the commencement POI, the algorithm may respectively store and index these nodes in the memory table as having a “visited” status indication. For example, in embodiments where the first status node208includes one or more descendant nodes, the algorithm stores the first status node208, as well as any descendant node receiving a status indication, in the memory table as having a “visited” status indication. As discussed in detail below, the algorithm may reference the memory table during subsequent inspection iterations of the branch-build timeline100to determine which nodes of the hierarchical nodal model160have been previously traversed and assigned with a status indication.

Upon assigning an appropriate status indication to the node corresponding to the commencement POI, as well as any node(s) descending therefrom, the algorithm determines which point of interest on the branch-build timeline100having a status indication has a datetime immediately preceding the datetime of the commencement POI, as indicated by step206. For clarity, a point of interest examined after examination of a previous point of interest (e.g., the commencement POI) will be referred to herein as a “current point of interest (POI).” Accordingly, in the present case, a point of interest having a status indication and a datetime immediately preceding the date time of the commencement POI will be referred to herein as the current POI.

As indicated by decision block210, the algorithm determines whether any point of interest having a status indication and a datetime immediately preceding the datetime of the commencement POI exists on the branch-build timeline100. If the algorithm is unable to determine a point of interest on the branch-build timeline100that includes a status indication and has a datetime immediately preceding the datetime of the commencement POI, the algorithm proceeds to step211and terminates inspection of the branch-build timeline100. If the algorithm is able to determine a point of interest (e.g., a current POI) on the branch-build timeline100that includes a status indication and has a datetime immediately preceding the datetime of the commencement POI, the algorithm references the aforementioned memory table to determine whether a node on the hierarchical nodal model160corresponding to this current POI is listed as having a “visited” status indication, as indicated by decision block212. Accordingly, the algorithm can determine whether the node corresponding to the current POI is void of a status indication (e.g., an affected status indication or an unaffected status indication).

If the node corresponding to the current POI is indicated as a previously visited node upon reference of the memory table, and thus is already assigned a status indication, the algorithm does not update a status indication of this node and proceeds to traverse all descendant nodes corresponding to the node of the current POI based on the left index value and/or the right index value of these nodes, as indicated by step213. As an example, the algorithm may traverse all descendant nodes of the node corresponding to the current POI in increasing order of the left index value of these nodes. That is, the algorithm may determine whether a subsequent descendant node (e.g., a node having a greater left index value than the current node under examination) is found, as indicated by decision block214. As shown in the illustrated embodiment of the process200, upon identification of a subsequent descendant node, the algorithm returns to the step212, thereby enabling the algorithm to iteratively inspect the descendant nodes of the node corresponding to the current POI.

If the algorithm is unable to identify a subsequent descendant node in the step214, the algorithm returns to the step205. In this manner, the algorithm iteratively identifies a new POI (e.g., a new current POI) for examination, as indicated by the step206. That is, the algorithm determines a new point of interest having a datetime immediately preceding the datetime of the current POI, and continues through the steps of the process200. As an example, if the current POI is a code commit, the commencement POI is a build file affected, the current POI and the commencement POI are situated on the same branch of the branch-build timeline100, and no points of interest are positioned chronologically between the commencement POI and the current POI, then the algorithm does not assign a status indication to any node(s) of the hierarchical nodal model160and reverts to the step205. Accordingly, at the step206, the algorithm identifies a point of interest immediately preceding the current POI and having a status indication, and updates this point of interest as the current POI (e.g., a new current POI). Additionally, in the step205, the algorithm stores the node corresponding to the new current POI as a node having a “visited” status indication.

If, upon referencing the aforementioned memory table at the step212, the algorithm determines that the node on the hierarchical nodal model160corresponding to the current POI is not listed as previously visited within the memory table, the algorithm proceeds to step216. Particularly, at the step216, the algorithm assigns the status indication of the current POI to the node corresponding to the current POI. To clarify, in the example above, if the current POI is a code commit, the commencement POI is a build file affected, the current POI and the commencement POI are situated on the same branch of the branch-build timeline100, and a branchpoint (or a neutral build file154) is positioned chronologically between the commencement POI and the current POI, then the algorithm will assign a status indication (e.g., an unaffected status indication) to a node of the hierarchical nodal model160corresponding to the branchpoint (or the neutral build file154).

Continuing through the illustrated embodiment of the branch-build timeline100ofFIG. 4, as shown, the current POI under examination after the commencement POI (e.g., the first build file affected150) is the fix target156(e.g., build file “KP2 B2”). As noted above, the fix target156is associated with an unaffected status indication. Accordingly, at the step216, the algorithm assigns an unaffected status indication to a node of the hierarchical nodal model160corresponding to the fix target156. Specifically, as shown in the illustrated embodiment ofFIG. 9, the algorithm assigns an unaffected status indication to a node220, which corresponds to the fix target156. The node220will be referred to herein as the second status node220.

The algorithm subsequently traverses any descendant node(s) of the second status node220(e.g., nodes that include a left index value that is greater than the left index value of the second status node220), as indicated by step218. That is, the algorithm determines whether the second status node220has a descendant node (e.g., a descendant lineage), as indicated by the decision block214. In other words, the algorithm determines whether any point(s) of interest descend from the fix target156. When traversing node(s) (e.g., in increasing order of left index value) that may descend from the second status node220, the algorithm references the memory table to determine whether the particular node under current examination is indicated as previously visited in the memory table, as indicated by the decision block212. If the memory table does not indicate the node under current examination as having a “visited” status, the algorithm proceeds to the step216and assigns this node with the status indication of the second status node220. The algorithm then proceeds to iterate through the steps of the process200. Conversely, if the memory table indicates that the node under current examination includes a “visited” status (e.g., the node is already assigned with a status indication), the algorithm proceeds to the step213and does not adjust a status indication of this node.

As shown in the illustrated embodiment ofFIG. 9, because the second status node220does not have any nodes descending therefrom, the algorithm only assigns a status indication (e.g., the unaffected status indication) to the second status node220, and subsequently returns to the step205. Accordingly, the algorithm may iteratively determine another point of interest for examination that has a datetime preceding a datetime of the current POI (e.g., the fix target156) and includes a status indication. For clarity, this newly identified point of interest will again be referred to in the succeeding discussion as the “current POI.” As such, it should be noted that the “current POI” referenced in the succeeding discussion is associated with a different point of interest on the branch-build timeline100than the “current POI” referenced in the preceding discussion.

With the foregoing in mind, as shown in the illustrated embodiment ofFIG. 4, the code commit146is the current POI examined by the algorithm subsequently to the fix target156. As noted above, code commits are not separately represented as nodes on the hierarchical nodal model160. Accordingly, the algorithm propagates an unaffected status indication to a point of interest on the same branch as the code commit146and having a datetime immediately consecutive to the datetime of the code commit146, if this point of interest has no previously assigned status indication. Indeed, as discussed above, it should be noted that if the point of interest immediately chronologically consecutive to the code commit146is, for example, a build file affected or a fix target (e.g., a point of interest already having a status indication), the algorithm reverts to the step205without assignment of a status indication to any point(s) of interest.

As an example, in the illustrated embodiment ofFIG. 4, the third branchpoint122is on the same branch as the code commit146(e.g., the current POI) and has a datetime immediately chronologically consecutive to the datetime of the code commit146. Therefore, because the third branchpoint122has no previously assigned status indication (e.g., the node corresponding to the third branchpoint122is not indicated as having a “visited” status indication in the memory table), the algorithm associates the third branchpoint122with an unaffected status indication. As such, the algorithm also assigns an unaffected status indication to a node of the hierarchical nodal model160corresponding to the third branchpoint122, as indicated by the step216. In particular, as shown in the illustrated embodiment ofFIG. 10, the algorithm assigns an unaffected status indication to a node230(e.g., a node associated with the third branchpoint122, the third branch node174). For clarity, the node230will be referred to herein as the third status node230.

As indicated by the decision block218, the algorithm subsequently iterates to a descendant node of the third status node230that includes a left index value that is greater than the left index value of the third status node230(e.g. the algorithm determines whether the third status node230has descendant node(s)). That is, the algorithm determines whether any points of interest on the branch-build timeline100are descendants of the code commit142. If the node corresponding to the third status node230has one or more descendant lineages, the algorithm traverses each node in the descendent lineage(s) in increasing order of left index value of the node(s) and attempts to assign the traversed node(s) with the same status indication as the status indication of the current POI. That is, if the traversed nodes are not indicated as having a “visited” status in the memory table, as determined in the decision block212, the algorithm assigns these traversed node(s) with the same status indication as the status indication of the current POI.

For example, as shown in the illustrated embodiment of the hierarchical nodal model160ofFIG. 10, the third status node230includes three descendant nodes238(e.g., child nodes), which are divided among a first descendant lineage240and a second descendant lineage242. As shown in the illustrated embodiment, the second build node176is indicative of a leading node of the first descendant lineage240, while the fourth branch node188is indicative of a leading node of the second descendant lineage242. In some embodiments, the algorithm traverses descendant lineages in order of increasing left index value of the leading nodes. Accordingly, as the left index value192of the second build node176is less than the left index value192of the fourth branch node188, the algorithm traverses the first descendant lineage240prior to traversing the second descendant lineage242.

For each descendant lineage traversed, the algorithm sequentially assigns the node(s) within the descendant lineage with the same status indication as the ancestor node of the descendant lineage (e.g., the third status node230) until reaching a terminal end of the descendant lineage or a node that is indicated as a previously visited in the memory table (e.g., a node already assigned with a particular status indication). For example, because the first descendant lineage240includes a single node (e.g., the second build node176) that was not previously traversed by the algorithm (e.g., is without a previously assigned status indication), the algorithm assigns this node with an unaffected status (e.g., the status of the third status node230, the status of the ancestor node), and subsequently initiates traversal of the second descendant lineage242. As all nodes within the second descendant lineage242have not yet been traversed by the algorithm (e.g., are also void of a previously assigned status indication), the algorithm assigns each of these nodes with an unaffected status, and returns to step205of the process200.

As a clarifying example, if the fourth branch node188was already traversed by the algorithm and assigned with a status indication (e.g., an affected status indication), the algorithm would cease traversing the remaining nodes of the second descendant lineage242and return to step205of the process200.

The algorithm iteratively repeats the aforementioned steps of the process200for each point of interest on the branch-build timeline100. That is, the algorithm examines all points of interest on the branch-build timeline100having a status indication, and uses the examined points of interest to assign an appropriate status indication to the nodes of the hierarchical nodal model160. In this manner, the algorithm may generate a completed hierarchical nodal model250, as shown inFIG. 11. The completed hierarchical nodal model250catalogues nodes associated with points of interest having a software bug or nodes presumed to have a software bug (e.g., points of interest having an affected status), and nodes associated with points of interest void of a software bug or nodes presumed void of a software bug (e.g., points of interest having an unaffected status). As such, the algorithm may analyze the completed hierarchical nodal model250to generate an indication of a first subset of software build files (e.g. build files) associated with the software bug, or presumed to have the software bug, and a second subset of software build files void of the software bug, or presumed void of the software bug. For example, the algorithm may evaluate the nodes of the completed hierarchical nodal model250to predict a status indication of the neutral build files154of the branch-build timeline100, thereby enabling a service agent to determine whether a neutral build file154is likely to contain a particular software bug. The algorithm may index a status associated with each of the build files140in a suitable searchable table or database. In this manner, the algorithm may facilitate selection of versions of an application void of a software bug. For example, in some embodiments, the algorithm may identify a compatible version of an application to which an entity may upgrade to resolve a software bug that is present in a version of the application currently used by the entity.

It should be noted that the algorithm does not assign a status indication to nodes corresponding to points of interest having a datetime preceding a datetime of the chronologically earliest point of interest having a status indication. That is, in the present example, the algorithm does not assign a status indication to nodes of the hierarchical nodal model160corresponding to points of interest having a datetime that precedes a datetime of the initial code commit252(e.g., as shown inFIG. 4). Advantageously, in this manner, the algorithm does not evaluate points of interest that are not associated with an identified software bug (e.g., points of interest chronologically preceding build files affected, fix targets, or code commits related to a particular software bug), which may reduce a computational time involved in iterating the algorithm over a particular branch-build timeline100.