US20100050156A1 - Using build history information to optimize a software build process - Google Patents

Using build history information to optimize a software build process Download PDF

Info

Publication number
US20100050156A1
US20100050156A1 US12/195,241 US19524108A US2010050156A1 US 20100050156 A1 US20100050156 A1 US 20100050156A1 US 19524108 A US19524108 A US 19524108A US 2010050156 A1 US2010050156 A1 US 2010050156A1
Authority
US
United States
Prior art keywords
build
dependency graph
failure
dependency
component source
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US12/195,241
Inventor
James M. Bonanno
Ronald P. Doyle
Michael L. Fraenkel
Aaron J. Tarter
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Priority to US12/195,241 priority Critical patent/US20100050156A1/en
Assigned to INTERNATIONAL BUSINESS MACHINES CORPORATION reassignment INTERNATIONAL BUSINESS MACHINES CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BONANNO, JAMES M., DOYLE, RONALD P., FRAENKEL, MICHAEL L., TARTER, AARON J.
Publication of US20100050156A1 publication Critical patent/US20100050156A1/en
Priority to US14/012,619 priority patent/US9626167B2/en
Priority to US15/478,183 priority patent/US10649748B2/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/40Transformation of program code
    • G06F8/41Compilation
    • G06F8/43Checking; Contextual analysis
    • G06F8/433Dependency analysis; Data or control flow analysis
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/40Transformation of program code
    • G06F8/41Compilation
    • G06F8/44Encoding
    • G06F8/443Optimisation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/70Software maintenance or management
    • G06F8/71Version control; Configuration management

Definitions

  • SCM source code management
  • SCM repositories include CVSTM and SubversionTM.
  • the SCM repository which contains source code modules, is used to build binary libraries and application modules.
  • the binary libraries and application modules can be stored in a binary repository. Examples of such binary repositories include Redhat NetworkTM, YumTM, MavenTM, and CPANTM for example.
  • the source code modules are compiled and linked into the binary modules during one or more build processes, and the source code modules have defined dependencies that may determine the possible orders in which the build processes can execute. There may be multiple independent build processes that need to run at any given time, and the build processes may need to decide among multiple possible paths of execution.
  • the dependency information becomes particularly important as the number of libraries/applications that are being built is very large, e.g. over 100 libraries, and where the libraries are rapidly changing. In this case, a great deal of processing power is necessary to keep up with the changes and for efficiency, only the source code modules that are changed should be the rebuilt.
  • 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.
  • FIG. 1 is a block diagram illustrating an exemplary network system environment in which one embodiment of the present invention may be implemented for optimizing a build order of component source modules.
  • FIG. 2 is a flow diagram illustrating a process for optimizing a build order of component source modules.
  • FIGS. 3A-3D are diagrams illustrating an example creation of a global reverse dependency graph.
  • FIG. 4 is a flow diagram illustrating a process for calculating relative failure factors for paths of the dependency graph.
  • the present invention relates to using build history information to optimize a software build process.
  • the following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements.
  • Various modifications to the preferred embodiments and the generic principles and features described herein will be readily apparent to those skilled in the art.
  • the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features described herein.
  • the exemplary embodiment provides for use of historical information associated with previous build failures to determine a build order of component source code modules for failure first or failure last when dependency information alone does not force the determination.
  • FIG. 1 is a block diagram illustrating an exemplary network system environment in which one embodiment of the present invention may be implemented for optimizing a build order of component source modules.
  • the network system environment 10 may include a hosting system 12 comprising one or more servers 14 coupled to a network 16 that provides a hosting service for a plurality of users of client computers 18 .
  • the hosting system 12 may include a build service 20 executing on the server 14 , a source code management repository 22 and a binary repository 24 .
  • the source code management repository 22 stores a library of component source modules 26 (i.e., source code), and the binary repository 24 stores a library of component binary and application modules 28 (i.e., executable code).
  • the build service 20 performs a build process on the source modules 26 that compiles and links the source modules 26 into the component binary and application modules 28 .
  • the build service 20 may store the submitted component source modules 26 in the source code management repository 22 within a directory structure. Once the component source modules 26 are stored in the source code management repository 22 , the developers may make changes to the component source modules 26 and re-run the build. At least a portion of the component source modules 26 are dependent upon other component source modules 26 and such dependency information may be stored in dependency files (not shown).
  • Each library in the source code management repository 22 may define its set of dependencies (e.g., using OSGI (Open Services Gateway initiative); a Java Archive (JAR) with an optional manifest file located in a path MANIFEST.MF; Ivy: ivy.xml; or maven: pom.xml).
  • OSGI Open Services Gateway initiative
  • JAR Java Archive
  • the order of the dependencies dictates the order of the build process.
  • the dependencies do not dictate the order of the build process.
  • the hosting system 12 may also include historical build information 30 , which is used to optimize the build order of the component source modules 26 when the dependency information alone is insufficient to determine the build order, as explained below.
  • the build service 20 is shown as one component, the build process may be implemented as multiple build processes, and the functionality of the build service 20 may be implemented with a greater number of components and run on the same or on multiple servers 14 .
  • FIG. 2 is a flow diagram illustrating a process for optimizing a build order of component source modules 26 .
  • the process is performed by the build service 20 , with or without the aid of additional applications.
  • the process may begin by creating a dependency graph (block 200 ).
  • a global reverse dependency graph is created by merging dependency files associated with the component source modules 26 and reversing the directions of the edges in the dependency graph.
  • the process may begin by polling the source code management repository 22 for any changes in dependency information in the component source modules 26 .
  • both the source code management repository 22 and/or the binary repository 24 may be polled for changes.
  • polling may be initiated manually whereby the polling is initiated by a developer via a client computer 18 .
  • polling may be initiated automatically. Automatic polling may be triggered by an expiration of a configured time interval. If no changes are detected, then the polling may be rescheduled for a later time.
  • a continuous integration build server such as Cruise ControlTM or AnthillTM can be used to poll the source code management repository 22 and/or the binary repository 24 for changes.
  • a time-based scheduling service such as “cron” of UNIX-like operating systems, could be used.
  • the dependency graph may be created based on the dependency information.
  • the historical build information 30 associated with previous build failures is used to calculate relative failure factors for paths of the dependency graph (block 202 ).
  • the relative failure factors of the paths are then used to determine an order of traversal of the dependency graph during a build process in which component binary and application modules 28 are built from the component source modules 26 (block 204 ).
  • the historical build information 30 may include the following:
  • historical build data is recorded for the source module and the developer of the source module in the historical build information 30 .
  • the list of historical build information may be readily changed and expanded. For example, information such as time of day may be stored to determine whether network access or other outside variables are affecting the build process. These pieces of information can be used to show a relative likelihood of failure.
  • FIGS. 3A-3D are diagrams illustrating an example creation of a global reverse dependency graph.
  • a global reverse dependency graph is created from a merging of the dependencies from two modules, employee.demo and zero.services.rating, and then a reversal of the directions of the edges of the merged graph.
  • FIG. 3A shows a dependency graph 300 of the dependencies for the employee.demo module.
  • An example xml version of the employee.demo module could be:
  • FIG. 3B shows a dependency graph 302 of the dependencies for the zero.services.rating model.
  • An example xml version of the employee.demo module could be:
  • FIG. 3C shows a merged global dependency graph 304 for the modules employee.demo and zero.services.rating; and FIG. 3D shows a global reverse dependency graph 306 , which is created by reversing directions of the edges of the merged global dependency graph 304 .
  • FIG. 4 is a flow diagram illustrating a process for calculating relative failure factors for paths of the dependency graph, described in block 204 of FIG. 2 , in further detail.
  • the process may begin by determining for each of the path options in the global reverse dependency graph 306 , a failure factor value Q (block 400 ).
  • Q may be defined as
  • 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
  • Fd i represents a number of files committed by the particular developer (d i ).
  • failure first refers to performing the build in such a way as to find failing component source modules 26 first
  • failure last refers to performing the build in such a way as to find a failing component source modules 26 last.
  • the determination of optimizing a build based on failure first or failure last may be based upon user input.
  • the build service 20 may check the source code management repository 22 to determine whether the component source modules 26 have changed (e.g., using a ‘svn info’ command in the case of a subversion repository), and, whether the changes require compilation or just runtime testing (i.e., skip the building phase).
  • the component source modules 26 may need recompiling if the compiled source file types for the component have changed, or if any direct compilation dependencies have changed. If any other changes have occurred within a component source module 26 , then the component source module 26 only needs to be republished (e.g., config files, scripts). Following the example described in FIGS.
  • the zero.services.rating, zero.data, zero.core, dojo, and derby modules are direct dependencies since they are referenced directly by the ivy.xml module.
  • zero.network and zero.network.support are transitive dependencies.
  • the build service 20 traverses the global reverse dependency graph 306 .
  • the build service 20 may build the node if there was a change that requires it, i.e., compiled source file types changed, or a compiled source file types of a directly connected node changed.
  • the build service 20 would need to build zero.network.support and zero.network since there could have been API changes in zero.network.support that could affect the compilation of zero.network.
  • the build service 20 may publish the build results to a temporary working repository that is used by the hosting system 12 until all changes have been fully verified by completing all of the above defined phases/steps which ends in publication.
  • Builds may resolve against a chain of binary repositories, where the temporary binary repository has greater precedence than the publicly available binary repository 24 . This may allow recently built libraries to be resolved against before the libraries are published.
  • the build service 20 may test the component binary and application modules 28 based on change information and the dependency graph.
  • the set of component binary and application modules 28 that will need to be tested will be equal to or greater than the set of component binary and application modules 28 that needed to be built during the build phase, since the set includes a full set of transitive dependencies and because the changes that require testing might not be included in those that require building.
  • any connected node either transitively or directly would need to be tested. This would include zero.network, zero.core, zero.data, employee.demo, and zero.services.rating.
  • the build service 20 may publish new libraries of component binary and application modules 28 from a temporary working repository to the binary repository 24 , and clean the temporary working repository.
  • a method and system for optimizing a build order of component source module for failure first or failure last has been disclosed.
  • the invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements.
  • the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.
  • the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system.
  • a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
  • the medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium.
  • Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk.
  • Current examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD.
  • a data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus.
  • the memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.
  • I/O devices including but not limited to keyboards, displays, pointing devices, etc.
  • I/O controllers can be coupled to the system either directly or through intervening I/O controllers.
  • Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks.
  • Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.

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.

Description

    BACKGROUND OF THE INVENTION
  • There are hosting systems in which developers may upload their source code modules for storage in a source code management (SCM) repository. Examples of such SCM repositories include CVS™ and Subversion™. The SCM repository, which contains source code modules, is used to build binary libraries and application modules. The binary libraries and application modules can be stored in a binary repository. Examples of such binary repositories include Redhat Network™, Yum™, Maven™, and CPAN™ for example.
  • The source code modules are compiled and linked into the binary modules during one or more build processes, and the source code modules have defined dependencies that may determine the possible orders in which the build processes can execute. There may be multiple independent build processes that need to run at any given time, and the build processes may need to decide among multiple possible paths of execution. The dependency information becomes particularly important as the number of libraries/applications that are being built is very large, e.g. over 100 libraries, and where the libraries are rapidly changing. In this case, a great deal of processing power is necessary to keep up with the changes and for efficiency, only the source code modules that are changed should be the rebuilt.
  • Depending on the nature of build components, such as the source code modules, and their usefulness as independent components, it might be more efficient to perform the build in such a way as to find failing source code modules first, which is referred to as “failure first”, or to find failing source code modules last, which is referred to as “failure last”. If the components only have usefulness as a whole, it is better to find failures as soon as possible so they can be fixed and the process can restart. If the components have usefulness independently, or the build process can start at a node in a dependency graph where the process failed last, then it is more efficient to find failure last, because more components will be published before a failure occurs. Unfortunately, it may not be apparent how to optimize the build order of the component source modules for failure first or failure last based on the dependency information alone.
  • BRIEF SUMMARY OF THE INVENTION
  • 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.
  • BRIEF DESCRIPTION OF SEVERAL VIEWS OF THE DRAWINGS
  • FIG. 1 is a block diagram illustrating an exemplary network system environment in which one embodiment of the present invention may be implemented for optimizing a build order of component source modules.
  • FIG. 2 is a flow diagram illustrating a process for optimizing a build order of component source modules.
  • FIGS. 3A-3D are diagrams illustrating an example creation of a global reverse dependency graph.
  • FIG. 4 is a flow diagram illustrating a process for calculating relative failure factors for paths of the dependency graph.
  • DETAILED DESCRIPTION OF THE INVENTION
  • The present invention relates to using build history information to optimize a software build process. The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements. Various modifications to the preferred embodiments and the generic principles and features described herein will be readily apparent to those skilled in the art. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features described herein.
  • The exemplary embodiment provides for use of historical information associated with previous build failures to determine a build order of component source code modules for failure first or failure last when dependency information alone does not force the determination.
  • FIG. 1 is a block diagram illustrating an exemplary network system environment in which one embodiment of the present invention may be implemented for optimizing a build order of component source modules. The network system environment 10 may include a hosting system 12 comprising one or more servers 14 coupled to a network 16 that provides a hosting service for a plurality of users of client computers 18. The hosting system 12 may include a build service 20 executing on the server 14, a source code management repository 22 and a binary repository 24. The source code management repository 22 stores a library of component source modules 26 (i.e., source code), and the binary repository 24 stores a library of component binary and application modules 28 (i.e., executable code). The build service 20 performs a build process on the source modules 26 that compiles and links the source modules 26 into the component binary and application modules 28.
  • Developers of the component source modules 26 upload their component source modules 26 from the client computers 18 to the server 14. The build service 20 may store the submitted component source modules 26 in the source code management repository 22 within a directory structure. Once the component source modules 26 are stored in the source code management repository 22, the developers may make changes to the component source modules 26 and re-run the build. At least a portion of the component source modules 26 are dependent upon other component source modules 26 and such dependency information may be stored in dependency files (not shown). Each library in the source code management repository 22 may define its set of dependencies (e.g., using OSGI (Open Services Gateway initiative); a Java Archive (JAR) with an optional manifest file located in a path MANIFEST.MF; Ivy: ivy.xml; or maven: pom.xml). Typically, the order of the dependencies dictates the order of the build process. However, in some cases, the dependencies do not dictate the order of the build process.
  • According to the exemplary embodiment, the hosting system 12 may also include historical build information 30, which is used to optimize the build order of the component source modules 26 when the dependency information alone is insufficient to determine the build order, as explained below.
  • Although the build service 20 is shown as one component, the build process may be implemented as multiple build processes, and the functionality of the build service 20 may be implemented with a greater number of components and run on the same or on multiple servers 14.
  • FIG. 2 is a flow diagram illustrating a process for optimizing a build order of component source modules 26. In the exemplary embodiment, the process is performed by the build service 20, with or without the aid of additional applications. The process may begin by creating a dependency graph (block 200). In one embodiment, a global reverse dependency graph is created by merging dependency files associated with the component source modules 26 and reversing the directions of the edges in the dependency graph.
  • In one embodiment the process may begin by polling the source code management repository 22 for any changes in dependency information in the component source modules 26. In one embodiment, both the source code management repository 22 and/or the binary repository 24 may be polled for changes. In one embodiment, polling may be initiated manually whereby the polling is initiated by a developer via a client computer 18. In another embodiment, polling may be initiated automatically. Automatic polling may be triggered by an expiration of a configured time interval. If no changes are detected, then the polling may be rescheduled for a later time. A continuous integration build server, such as Cruise Control™ or Anthill™ can be used to poll the source code management repository 22 and/or the binary repository 24 for changes. Alternatively, a time-based scheduling service, such as “cron” of UNIX-like operating systems, could be used. In response to detecting changes in the dependency information, the dependency graph may be created based on the dependency information.
  • The historical build information 30 associated with previous build failures is used to calculate relative failure factors for paths of the dependency graph (block 202). The relative failure factors of the paths are then used to determine an order of traversal of the dependency graph during a build process in which component binary and application modules 28 are built from the component source modules 26 (block 204).
  • According to the exemplary embodiment, the historical build information 30 may include the following:
  • a history of which respective component source modules 26 have failed most often in the past as a percentage of the total attempts to build the respective component source modules;
  • a history of the developer's contributions to build failures as a percentage of developer's total contributions;
  • a total number of file changes since a last successful build.
  • In one embodiment, when a component source module 26 is used in a build, historical build data is recorded for the source module and the developer of the source module in the historical build information 30. The list of historical build information may be readily changed and expanded. For example, information such as time of day may be stored to determine whether network access or other outside variables are affecting the build process. These pieces of information can be used to show a relative likelihood of failure.
  • FIGS. 3A-3D are diagrams illustrating an example creation of a global reverse dependency graph. A global reverse dependency graph is created from a merging of the dependencies from two modules, employee.demo and zero.services.rating, and then a reversal of the directions of the edges of the merged graph. FIG. 3A shows a dependency graph 300 of the dependencies for the employee.demo module. An example xml version of the employee.demo module could be:
  • employee.demo/confg/ivy.xml:
    <ivy-module version=“1.3”>
     <info module=“employee.demo” organisation=“zero”
    packagingType=“unknown” revision=“1.0.0”>
      <license name=“type of license” url=“http://license.page”/>
      <ivyauthor name=“AuthorsName” url=“http://authors.home.page”/>
      <description homepage=“http://module.description.page”/>
     </info>
     <publications>
      <artifact name=“employee.demo” org=“zero” type=“zip”/>
     </publications>
     <dependencies>
      <dependency name=“zero.core” org=“zero” rev=“1.0+”/>
      <dependency name=“dojo” org=“dojo” rev=“0.4.3”/>
      <dependency name=“zero.data” org=“zero” rev=“1.0+”/>
     </dependencies>
    </ivy-module>
  • FIG. 3B shows a dependency graph 302 of the dependencies for the zero.services.rating model. An example xml version of the employee.demo module could be:
  • zero.services.rating/confg/ivy.xml:
    <?xml version=“1.0” encoding=“UTF-8”?>
    <ivy-module version=“1.3”>
     <info module=“zero.services.rating” organisation=“zero”
    packagingType=“shared” packagingVersion=“1.0.0” revision=“1.0.0”>
      <license name=“IBM” url=“http://www.ibm.com”/>
      <ivyauthor name=“Project Zero” url=“http://www.projectzero.org”/>
      <description homepage=“http://www.projectzero.org”/>
     </info>
     <publications>
      <artifact name=“zero.services.rating” org=“zero” type=“zip”/>
     </publications>
     <dependencies>
      <dependency name=“zero.core” org=“zero” rev=“1.0+”/>
      <dependency name=“zero.data” org=“zero” rev=“1.0+”/>
      <dependency name=“dojo” org=“dojo” rev=“0.4.3”/>
      <dependency name=“derby” org=“org.apache.derby”
      rev=“10.2.2+”/>
     </dependencies>
    </ivy-module>
  • FIG. 3C shows a merged global dependency graph 304 for the modules employee.demo and zero.services.rating; and FIG. 3D shows a global reverse dependency graph 306, which is created by reversing directions of the edges of the merged global dependency graph 304.
  • FIG. 4 is a flow diagram illustrating a process for calculating relative failure factors for paths of the dependency graph, described in block 204 of FIG. 2, in further detail. The process may begin by determining for each of the path options in the global reverse dependency graph 306, a failure factor value Q (block 400). According to one exemplary embodiment, Q may be defined as
  • Q = P c * ( i = 0 n ( Pd i * Fd i ) i = 0 n Fd i )
  • where Pc represents a percentage of past failures for a particular component source module;
  • Pdi represents the percentage of past failure for a particular developer (di) who committed code to the particular component source module; and
  • Fdi represents a number of files committed by the particular developer (di).
  • After the failure factor values have been calculated, it is determined whether a build should be optimized for failure first or failure last (block 402). As stated above, failure first refers to performing the build in such a way as to find failing component source modules 26 first, while failure last refers to performing the build in such a way as to find a failing component source modules 26 last. The determination of optimizing a build based on failure first or failure last may be based upon user input.
  • When traversing the global reverse dependency graph 306 during the build process, it is determined whether a node has been reached having at least two path options, but dependencies do not determine which path for the build process to take (block 404). If so, and if the build is optimized for failure first, then the build service 20 traverses the global reverse dependency graph 306 and performs the build based on the path options having a highest failure factor value (block 406). If the build is optimized for failure last, then the build service 20 traverses the global reverse dependency graph 306 and performs the build based on the path options having a lowest failure factor value (block 408).
  • During the actual build process, the build service 20 may check the source code management repository 22 to determine whether the component source modules 26 have changed (e.g., using a ‘svn info’ command in the case of a subversion repository), and, whether the changes require compilation or just runtime testing (i.e., skip the building phase). In one embodiment, the component source modules 26 may need recompiling if the compiled source file types for the component have changed, or if any direct compilation dependencies have changed. If any other changes have occurred within a component source module 26, then the component source module 26 only needs to be republished (e.g., config files, scripts). Following the example described in FIGS. 3A-3D and the example XML, the zero.services.rating, zero.data, zero.core, dojo, and derby modules are direct dependencies since they are referenced directly by the ivy.xml module. On the other hand, zero.network and zero.network.support are transitive dependencies.
  • To determine the ordered list of component source modules 26 that need to be compiled, the build service 20 traverses the global reverse dependency graph 306. For each node in the global reverse dependency graph 306 the build service 20 may build the node if there was a change that requires it, i.e., compiled source file types changed, or a compiled source file types of a directly connected node changed. Using the example global reverse dependency graph 306 above, if a change to a compiled source file type was detected in zero.network.support, then the build service 20 would need to build zero.network.support and zero.network since there could have been API changes in zero.network.support that could affect the compilation of zero.network.
  • In one embodiment, the build service 20 may publish the build results to a temporary working repository that is used by the hosting system 12 until all changes have been fully verified by completing all of the above defined phases/steps which ends in publication. Builds may resolve against a chain of binary repositories, where the temporary binary repository has greater precedence than the publicly available binary repository 24. This may allow recently built libraries to be resolved against before the libraries are published.
  • After the component binary and application modules 28 have been built, the build service 20 may test the component binary and application modules 28 based on change information and the dependency graph. The set of component binary and application modules 28 that will need to be tested will be equal to or greater than the set of component binary and application modules 28 that needed to be built during the build phase, since the set includes a full set of transitive dependencies and because the changes that require testing might not be included in those that require building. Continuing with the example described in FIGS. 3A-3D, if zero.network.support had any change, then any connected node (either transitively or directly) would need to be tested. This would include zero.network, zero.core, zero.data, employee.demo, and zero.services.rating.
  • After testing, the build service 20 may publish new libraries of component binary and application modules 28 from a temporary working repository to the binary repository 24, and clean the temporary working repository.
  • A method and system for optimizing a build order of component source module for failure first or failure last has been disclosed. The invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.
  • Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
  • The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD.
  • A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.
  • Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers.
  • Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.
  • The present invention has been described in accordance with the embodiments shown, and one of ordinary skill in the art will readily recognize that there could be variations to the embodiments, and any variations would be within the spirit and scope of the present invention. Accordingly, many modifications may be made by one of ordinary skill in the art without departing from the spirit and scope of the appended claims.

Claims (25)

1. 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 Pc represents a percentage of past failures for a particular component source module;
Pdi represents the percentage of past failure for a particular developer (di) who committed code to the particular component source module; and
Fdi represents a number of files committed by the particular developer (di).
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 Pc represents a percentage of past failures for a particular component source module;
Pdi represents the percentage of past failure for a particular developer (di) who committed code to the particular component source module; and
Fdi represents a number of files committed by the particular developer (di).
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 Pc represents a percentage of past failures for a particular component source module;
Pdi represents the percentage of past failure for a particular developer (di) who committed code to the particular component source module; and
Fdi represents a number of files committed by the particular developer (di).
US12/195,241 2008-08-20 2008-08-20 Using build history information to optimize a software build process Abandoned US20100050156A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US12/195,241 US20100050156A1 (en) 2008-08-20 2008-08-20 Using build history information to optimize a software build process
US14/012,619 US9626167B2 (en) 2008-08-20 2013-08-28 Using build history information to optimize a software build process
US15/478,183 US10649748B2 (en) 2008-08-20 2017-04-03 Using build history information to optimize a software build process

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US12/195,241 US20100050156A1 (en) 2008-08-20 2008-08-20 Using build history information to optimize a software build process

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/012,619 Continuation US9626167B2 (en) 2008-08-20 2013-08-28 Using build history information to optimize a software build process

Publications (1)

Publication Number Publication Date
US20100050156A1 true US20100050156A1 (en) 2010-02-25

Family

ID=41697503

Family Applications (3)

Application Number Title Priority Date Filing Date
US12/195,241 Abandoned US20100050156A1 (en) 2008-08-20 2008-08-20 Using build history information to optimize a software build process
US14/012,619 Expired - Fee Related US9626167B2 (en) 2008-08-20 2013-08-28 Using build history information to optimize a software build process
US15/478,183 Active 2029-08-08 US10649748B2 (en) 2008-08-20 2017-04-03 Using build history information to optimize a software build process

Family Applications After (2)

Application Number Title Priority Date Filing Date
US14/012,619 Expired - Fee Related US9626167B2 (en) 2008-08-20 2013-08-28 Using build history information to optimize a software build process
US15/478,183 Active 2029-08-08 US10649748B2 (en) 2008-08-20 2017-04-03 Using build history information to optimize a software build process

Country Status (1)

Country Link
US (3) US20100050156A1 (en)

Cited By (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100153920A1 (en) * 2008-12-17 2010-06-17 Michael Stavros Bonnet Method for building and packaging sofware
US20100169863A1 (en) * 2008-09-26 2010-07-01 Bluetie, Inc. Methods for determining resource dependency and systems thereof
US20110239192A1 (en) * 2010-03-26 2011-09-29 Oracle International Corporation Fully declarative build system for build optimization
US20120246616A1 (en) * 2011-03-23 2012-09-27 International Business Machines Corporation Build process management system
US20120297359A1 (en) * 2011-05-18 2012-11-22 International Business Machines Corporation Automated build process and root-cause analysis
US20130007709A1 (en) * 2011-06-30 2013-01-03 International Business Machines Corporation Software configuration management
US20130174124A1 (en) * 2011-12-29 2013-07-04 Christina Watters Version numbering in single development and test environment
US20130232469A1 (en) * 2012-03-02 2013-09-05 Oracle International Corporation System and method for automatically resolving dependencies of java archive files for use with maven
US8776014B2 (en) 2010-09-23 2014-07-08 Microsoft Corporation Software build analysis
US8826223B2 (en) 2012-04-18 2014-09-02 International Business Machines Corporation Techniques for objective assessment and improvement of software quality
US20140289704A1 (en) * 2013-03-21 2014-09-25 Infosys Limited Methods, systems and computer-readable media for detecting a partial commit
US8910134B2 (en) * 2013-01-03 2014-12-09 Oracle International Corporation System for applying transformation to improve graph analysis
US20150106797A1 (en) * 2013-10-14 2015-04-16 International Business Machines Corporation Dynamic code selection based on data policies
US9170779B2 (en) 2011-07-19 2015-10-27 International Business Machines Corporation Managing an application development environment
US20150378873A1 (en) * 2014-06-25 2015-12-31 Hcl Technologies Ltd Automatically recommending test suite from historical data based on randomized evolutionary techniques
US9244679B1 (en) * 2013-09-12 2016-01-26 Symantec Corporation Systems and methods for automatically identifying changes in deliverable files
US20160034270A1 (en) * 2014-08-01 2016-02-04 Microsoft Corporation Estimating likelihood of code changes introducing defects
US20160098256A1 (en) * 2014-10-03 2016-04-07 General Motors Llc Visual tool and architecting logical layers of software components
US20160147529A1 (en) * 2014-11-20 2016-05-26 Red Hat, Inc. Source Code Management for a Multi-Tenant Platform-as-a-Service (PaaS) System
US9665849B2 (en) 2015-02-26 2017-05-30 Red Hat, Inc. Employing dependency graph in software build projects
US9720684B2 (en) 2013-09-17 2017-08-01 International Business Machines Corporation Merit based inclusion of changes in a build of a software system
US20180060066A1 (en) * 2016-07-12 2018-03-01 Accenture Global Solutions Limited Application Centric Continuous Integration and Delivery With Automated Service Assurance
US9971570B2 (en) 2015-12-15 2018-05-15 Oracle International Corporation Automated generation of memory consumption aware code
CN109086049A (en) * 2018-07-25 2018-12-25 北京金和网络股份有限公司 The method of traverse user presence data
US10204028B2 (en) * 2013-09-20 2019-02-12 Drexel University Rule spaces and architecture root detection
US10545847B2 (en) 2016-09-15 2020-01-28 International Business Machines Corporation Grouping and isolating software changes to increase build quality
US10649748B2 (en) 2008-08-20 2020-05-12 International Business Machines Corporation Using build history information to optimize a software build process
US11194558B2 (en) 2016-10-14 2021-12-07 Accenture Global Solutions Limited Application migration system
US11347555B2 (en) * 2016-09-02 2022-05-31 Intuit Inc. Integrated system to distribute and execute complex applications
US11463478B2 (en) * 2019-10-29 2022-10-04 International Business Machines Corporation Remediation strategy optimization for development, security and operations (DevSecOps)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10061577B2 (en) * 2014-10-14 2018-08-28 Electric Cloud, Inc. System and method for optimizing job scheduling within program builds
WO2016148132A1 (en) * 2015-03-19 2016-09-22 日本碍子株式会社 Silica film and separation film filter
US9411557B1 (en) * 2015-09-30 2016-08-09 Semmle Limited Specifying a model architecture of software elements and generating an aggregated dependency graph therefrom
CN111026407B (en) * 2018-10-10 2021-12-03 北大方正集团有限公司 Installation package packing method, computer device and computer readable storage medium
US10963242B2 (en) * 2019-06-24 2021-03-30 Hartford Fire Insurance Company Intelligent software agent to facilitate software development and operations
CN111045670B (en) * 2019-12-13 2021-07-13 中国科学院信息工程研究所 Method and device for identifying multiplexing relationship between binary code and source code
US11550553B2 (en) 2020-11-23 2023-01-10 Red Hat, Inc. Usage-based software library decomposition

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4809170A (en) * 1987-04-22 1989-02-28 Apollo Computer, Inc. Computer device for aiding in the development of software system
US5758160A (en) * 1993-06-28 1998-05-26 Object Technology Licensing Corporation Method and apparatus for building a software program using dependencies derived from software component interfaces
US20040194060A1 (en) * 2003-03-25 2004-09-30 John Ousterhout System and method for supplementing program builds with file usage information
US6918111B1 (en) * 2000-10-03 2005-07-12 Sun Microsystems, Inc. System and method for scheduling instructions to maximize outstanding prefetches and loads
US20060085858A1 (en) * 2004-10-19 2006-04-20 Noel Steven E Minimum-cost network hardening
US7251584B1 (en) * 2006-03-14 2007-07-31 International Business Machines Corporation Incremental detection and visualization of problem patterns and symptoms based monitored events
US20080256392A1 (en) * 2007-04-16 2008-10-16 Microsoft Corporation Techniques for prioritizing test dependencies
US20090113396A1 (en) * 2007-10-26 2009-04-30 Microsoft Corporation Monitoring asset state to enable partial build

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100050156A1 (en) 2008-08-20 2010-02-25 International Business Machines Corporation Using build history information to optimize a software build process
CN104272266B (en) * 2012-09-03 2016-11-09 株式会社日立制作所 The management system that the computer system with multiple supervision object device is managed

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4809170A (en) * 1987-04-22 1989-02-28 Apollo Computer, Inc. Computer device for aiding in the development of software system
US5758160A (en) * 1993-06-28 1998-05-26 Object Technology Licensing Corporation Method and apparatus for building a software program using dependencies derived from software component interfaces
US6918111B1 (en) * 2000-10-03 2005-07-12 Sun Microsystems, Inc. System and method for scheduling instructions to maximize outstanding prefetches and loads
US20040194060A1 (en) * 2003-03-25 2004-09-30 John Ousterhout System and method for supplementing program builds with file usage information
US20060085858A1 (en) * 2004-10-19 2006-04-20 Noel Steven E Minimum-cost network hardening
US7251584B1 (en) * 2006-03-14 2007-07-31 International Business Machines Corporation Incremental detection and visualization of problem patterns and symptoms based monitored events
US20080256392A1 (en) * 2007-04-16 2008-10-16 Microsoft Corporation Techniques for prioritizing test dependencies
US20090113396A1 (en) * 2007-10-26 2009-04-30 Microsoft Corporation Monitoring asset state to enable partial build

Cited By (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10649748B2 (en) 2008-08-20 2020-05-12 International Business Machines Corporation Using build history information to optimize a software build process
US9477497B2 (en) * 2008-09-26 2016-10-25 Juniper Networks, Inc. Methods for determining resource dependency and systems thereof
US20100169863A1 (en) * 2008-09-26 2010-07-01 Bluetie, Inc. Methods for determining resource dependency and systems thereof
US8949788B2 (en) * 2008-12-17 2015-02-03 Red Hat, Inc. Building and packaging software
US20100153920A1 (en) * 2008-12-17 2010-06-17 Michael Stavros Bonnet Method for building and packaging sofware
US8627286B2 (en) * 2010-03-26 2014-01-07 Oracle International Corporation Fully declarative build system for build optimization
US20110239192A1 (en) * 2010-03-26 2011-09-29 Oracle International Corporation Fully declarative build system for build optimization
US8776014B2 (en) 2010-09-23 2014-07-08 Microsoft Corporation Software build analysis
US9632769B2 (en) 2010-09-23 2017-04-25 Microsoft Technology Licensing, Llc Software build optimization
US20120246616A1 (en) * 2011-03-23 2012-09-27 International Business Machines Corporation Build process management system
US8762944B2 (en) * 2011-03-23 2014-06-24 International Business Machines Corporation Build process management system
US20120246617A1 (en) * 2011-03-23 2012-09-27 International Business Machines Corporation Build process management system
US8713527B2 (en) * 2011-03-23 2014-04-29 International Business Machines Corporation Build process management system
US20120297359A1 (en) * 2011-05-18 2012-11-22 International Business Machines Corporation Automated build process and root-cause analysis
US8839188B2 (en) * 2011-05-18 2014-09-16 International Business Machines Corporation Automated build process and root-cause analysis
US20130007709A1 (en) * 2011-06-30 2013-01-03 International Business Machines Corporation Software configuration management
US9170779B2 (en) 2011-07-19 2015-10-27 International Business Machines Corporation Managing an application development environment
US20130174124A1 (en) * 2011-12-29 2013-07-04 Christina Watters Version numbering in single development and test environment
US8813031B2 (en) * 2012-03-02 2014-08-19 Oracle International Corporation System and method for automatically resolving dependencies of Java Archive files for use with Maven
US20130232469A1 (en) * 2012-03-02 2013-09-05 Oracle International Corporation System and method for automatically resolving dependencies of java archive files for use with maven
US8826223B2 (en) 2012-04-18 2014-09-02 International Business Machines Corporation Techniques for objective assessment and improvement of software quality
US8910134B2 (en) * 2013-01-03 2014-12-09 Oracle International Corporation System for applying transformation to improve graph analysis
US9785430B2 (en) * 2013-03-21 2017-10-10 Infosys Limited Methods, systems and computer-readable media for detecting a partial commit
US20140289704A1 (en) * 2013-03-21 2014-09-25 Infosys Limited Methods, systems and computer-readable media for detecting a partial commit
US9244679B1 (en) * 2013-09-12 2016-01-26 Symantec Corporation Systems and methods for automatically identifying changes in deliverable files
US11275578B2 (en) 2013-09-17 2022-03-15 International Business Machines Corporation Merit based inclusion of changes in a build of a software system
US9720683B2 (en) 2013-09-17 2017-08-01 International Business Machines Corporation Merit based inclusion of changes in a build of a software system
US10248413B2 (en) 2013-09-17 2019-04-02 International Business Machines Corporation Merit based inclusion of changes in a build of a software system
US10698683B2 (en) 2013-09-17 2020-06-30 International Business Machines Corporation Merit based inclusion of changes in a build of a software system
US9720684B2 (en) 2013-09-17 2017-08-01 International Business Machines Corporation Merit based inclusion of changes in a build of a software system
US10204028B2 (en) * 2013-09-20 2019-02-12 Drexel University Rule spaces and architecture root detection
US9606783B2 (en) * 2013-10-14 2017-03-28 International Business Machines Corporation Dynamic code selection based on data policies
US20150106797A1 (en) * 2013-10-14 2015-04-16 International Business Machines Corporation Dynamic code selection based on data policies
US20150378873A1 (en) * 2014-06-25 2015-12-31 Hcl Technologies Ltd Automatically recommending test suite from historical data based on randomized evolutionary techniques
US9471470B2 (en) * 2014-06-25 2016-10-18 Hcl Technologies Ltd Automatically recommending test suite from historical data based on randomized evolutionary techniques
US9588876B2 (en) * 2014-08-01 2017-03-07 Microsoft Technology Licensing, Llc Estimating likelihood of code changes introducing defects
US20160034270A1 (en) * 2014-08-01 2016-02-04 Microsoft Corporation Estimating likelihood of code changes introducing defects
US20160098256A1 (en) * 2014-10-03 2016-04-07 General Motors Llc Visual tool and architecting logical layers of software components
US10599423B2 (en) * 2014-11-20 2020-03-24 Red Hat, Inc. Source code management for a multi-tenant platform-as-a-service (PaaS) system
US20160147529A1 (en) * 2014-11-20 2016-05-26 Red Hat, Inc. Source Code Management for a Multi-Tenant Platform-as-a-Service (PaaS) System
US9665849B2 (en) 2015-02-26 2017-05-30 Red Hat, Inc. Employing dependency graph in software build projects
US9971570B2 (en) 2015-12-15 2018-05-15 Oracle International Corporation Automated generation of memory consumption aware code
US10409589B2 (en) * 2016-07-12 2019-09-10 Accenture Global Solutions Limited Application centric continuous integration and delivery with automated service assurance
US20180060066A1 (en) * 2016-07-12 2018-03-01 Accenture Global Solutions Limited Application Centric Continuous Integration and Delivery With Automated Service Assurance
US11347555B2 (en) * 2016-09-02 2022-05-31 Intuit Inc. Integrated system to distribute and execute complex applications
US10545847B2 (en) 2016-09-15 2020-01-28 International Business Machines Corporation Grouping and isolating software changes to increase build quality
US11194558B2 (en) 2016-10-14 2021-12-07 Accenture Global Solutions Limited Application migration system
CN109086049A (en) * 2018-07-25 2018-12-25 北京金和网络股份有限公司 The method of traverse user presence data
US11463478B2 (en) * 2019-10-29 2022-10-04 International Business Machines Corporation Remediation strategy optimization for development, security and operations (DevSecOps)

Also Published As

Publication number Publication date
US10649748B2 (en) 2020-05-12
US20170206067A1 (en) 2017-07-20
US9626167B2 (en) 2017-04-18
US20140033186A1 (en) 2014-01-30

Similar Documents

Publication Publication Date Title
US10649748B2 (en) Using build history information to optimize a software build process
US11061718B2 (en) Pattern-based artificial intelligence planner for computer environment migration
US8918774B2 (en) Updating a computer system
US9182966B2 (en) Enabling dynamic software installer requirement dependency checks
US9026502B2 (en) Feedback optimized checks for database migration
US20160117161A1 (en) Installing and updating software systems
US20080244565A1 (en) Dynamic software installation and configuration
De Camargo et al. An architecture to automate performance tests on microservices
US20080270153A1 (en) Service oriented architecture (soa) lifecycle model migration
Kargar et al. Automation of regression test in microservice architecture
US20130275960A1 (en) Validation of current states of provisioned software products in a cloud environment
Weyns et al. An architectural approach to support online updates of software product lines
Sandobalin et al. End-to-end automation in cloud infrastructure provisioning
Spinner et al. A reference architecture for online performance model extraction in virtualized environments
Talwar et al. Comparison of approaches to service deployment
De Gouw et al. On the integration of automatic deployment into the ABS modeling language
US7921417B2 (en) Method and computer system for activation of source files
Cortellessa et al. Selecting optimal maintenance plans based on cost/reliability tradeoffs for software subject to structural and behavioral changes
Esquembri Moreno Automated characterization of build and test failures on a continuous integration system
CN117369864B (en) Integrated software development processing method and system based on artificial intelligence
Morozov et al. Automatic distributed workflow generation with GridMD library
US20170249762A1 (en) Critical Path Detection in Job
Gaikwad et al. Data Collection System based on PWA (Progressive Web App) as SaaS
Balogh et al. Model-based optimization of enterprise application and service deployment
Eloranta Continuous development and release automation of web applications

Legal Events

Date Code Title Description
AS Assignment

Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION,NEW YO

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:BONANNO, JAMES M.;DOYLE, RONALD P.;FRAENKEL, MICHAEL L.;AND OTHERS;REEL/FRAME:021419/0443

Effective date: 20080819

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO PAY ISSUE FEE