US2010050156A1PendingUtilityA1
Using build history information to optimize a software build process
Est. expiryAug 20, 2028(~2.1 yrs left)· nominal 20-yr term from priority
G06F 8/71G06F 8/433G06F 8/443
52
PatentIndex Score
0
Cited by
0
References
0
Claims
Abstract
Methods and systems for optimizing a build order of component source modules comprises creating a dependency graph based on dependency information. Historical build information associated with previous build failures is then used to calculate relative failure factors for paths of the dependency graph; and the relative failure factors are used to determine an order of traversal of the dependency graph during a build process in which component binary modules are built from the component source modules.
Claims
exact text as granted — not AI-modified1 . A method for optimizing a build order of component source modules, comprising:
creating a dependency graph based on dependency information; using historical build information associated with previous build failures to calculate relative failure factors for paths of the dependency graph; and using the relative failure factors to determine an order of traversal of the dependency graph during a build process in which component binary modules are built from the component source modules.
2 . The method of claim 1 wherein the historical build information includes at least one of:
a history of which respective component source modules have failed most often as a percentage of total attempts to build the respective component source modules; a history of a developer's contributions to build failures as a percentage of a total contribution of the developer; a total number of file changes since a last successful build.
3 . The method of claim 1 further comprising:
polling a source code management repository for any changes in the dependency information in the component source modules; in response to detecting changes in the dependency information, creating the dependency graph based on the dependency information.
4 . The method of claim 1 wherein creating the dependency graph comprises creating a global reverse dependency graph.
5 . The method of claim 4 further comprising creating the global reverse dependency graph by reversing directions of edges of a merged global dependency graph.
6 . The method of claim 4 further comprising calculating the relative failure factors by determining for each of a plurality of path options in the global reverse dependency graph, a failure factor value.
7 . The method of claim 6 wherein the using the relative failure factors further comprises:
if a build is optimized for failure first, then traversing the global reverse dependency graph and performing the build based on the plurality of path options having a highest failure factor value.
8 . The method of claim 6 wherein the using the relative failure factors further comprises:
if the build is optimized for failure last, then traversing the global reverse dependency graph and performing the build based on the plurality of path options having a lowest failure factor value.
9 . The method of claim 6 wherein the failure factor value is designated as Q, where Q is defined as:
Q
=
P
c
*
(
∑
i
=
0
n
(
Pd
i
*
Fd
i
)
∑
i
=
0
n
Fd
i
)
where P c represents a percentage of past failures for a particular component source module;
Pd i represents the percentage of past failure for a particular developer (d i ) who committed code to the particular component source module; and
Fd i represents a number of files committed by the particular developer (d i ).
10 . A system comprising:
a server; and a build service executing on the server; the build service configured to:
create a dependency graph based on dependency information;
use historical build information associated with previous build failures to calculate relative failure factors for paths of the dependency graph; and
use the relative failure factors to determine an order of traversal of the dependency graph during a build process in which component binary modules are built from the component source modules.
11 . The system of claim 10 wherein the historical build information includes at least one of:
a history of which respective component source modules have failed most often as a percentage of total attempts to build the respective component source modules; a history of a developer's contributions to build failures as a percentage of a total contribution of the developer; a total number of file changes since a last successful build.
12 . The system of claim 9 wherein the build service is further configured to:
poll a source code management repository for any changes in the dependency information in component source modules; and in response to detecting changes in the dependency information, create the dependency graph based on the dependency information.
13 . The system of claim 10 wherein the dependency graph comprises a global reverse dependency graph.
14 . The system of claim 13 wherein the global reverse dependency graph is created by reversing directions of edges of a merged global dependency graph.
15 . The system of claim 13 wherein the relative failure factors are calculated by determining for each of a plurality of path options in the global reverse dependency graph, a failure factor value.
16 . The system of claim 15 wherein the using the relative failure factors further comprises:
if a build is optimized for failure first, then traversing the global reverse dependency graph and performing the build based on the plurality of path options having a highest failure factor value; and if the build is optimized for failure last, then traversing the global reverse dependency graph and performing the build based on the plurality of path options having a lowest failure factor value.
17 . The system of claim 15 wherein the failure factor value is designated as Q, where Q is defined as:
Q
=
P
c
*
(
∑
i
=
0
n
(
Pd
i
*
Fd
i
)
∑
i
=
0
n
Fd
i
)
where P c represents a percentage of past failures for a particular component source module;
Pd i represents the percentage of past failure for a particular developer (d i ) who committed code to the particular component source module; and
Fd i represents a number of files committed by the particular developer (d i ).
18 . An executable software product stored on a computer-readable medium containing program instructions for optimizing a build order of component source modules, the program instructions for:
creating a dependency graph based on dependency information; using historical build information associated with previous build failures to calculate relative failure factors for paths of the dependency graph; and using the relative failure factors to determine an order of traversal of the dependency graph during a build process in which component binary modules are built from the component source modules.
19 . The executable software product of claim 18 wherein the historical build information includes at least one of:
a history of which respective component source modules have failed most often as a percentage of total attempts to build the respective component source modules; a history of a developer's contributions to build failures as a percentage of a total contribution of the developer; a total number of file changes since a last successful build.
20 . The executable software product of claim 18 further comprising:
polling a source code management repository for any changes in the dependency information in the component source modules; in response to detecting changes in the dependency information, creating the dependency graph based on the dependency information.
21 . The executable software product of claim 18 wherein creating the dependency graph comprises creating a global reverse dependency graph.
22 . The executable software product of claim 21 further comprising creating the global reverse dependency graph by reversing directions of edges of a merged global dependency graph.
23 . The executable software product of claim 21 further comprising calculating the relative failure factors by determining for each of a plurality of path options in the global reverse dependency graph, a failure factor value.
24 . The executable software product of claim 23 wherein the using the relative failure factors further comprises:
if a build is optimized for failure first, then traversing the global reverse dependency graph and performing the build based on the plurality of path options having a highest failure factor value; and if the build is optimized for failure last, then traversing the global reverse dependency graph and performing the build based on the plurality of path options having a lowest failure factor value.
25 . The executable software product of claim 23 wherein the failure factor value is designated as Q, where Q is defined as:
Q
=
P
c
*
(
∑
i
=
0
n
(
Pd
i
*
Fd
i
)
∑
i
=
0
n
Fd
i
)
where P c represents a percentage of past failures for a particular component source module;
Pd i represents the percentage of past failure for a particular developer (d i ) who committed code to the particular component source module; and
Fd i represents a number of files committed by the particular developer (d i ).Cited by (0)
No later patents cite this yet.
References (0)
No backward citations on record.