Browse Prior Art Database

System and Method to Automatically Detect Build Failures in Complex Development Environments with Many Dependencies by Determining Failure Injection

IP.com Disclosure Number: IPCOM000244532D
Publication Date: 2015-Dec-18
Document File: 6 page(s) / 84K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a means of correlating build breaks to points-of-origin in complex coding environments with multiple dependencies. The net effect is reduced time and expense in debugging code and improved overall business performance for the adopting organization.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 24% of the total text.

Page 01 of 6

System and Method to Automatically Detect Build Failures in Complex Development Environments with Many Dependencies by Determining Failure Injection

Large organizations performing software development often have many developers working together on a single product. Software control and build systems ensure proper code integration and build. However, large, complex teams tend to run into build breaks, and the resultant evaluation process (i.e. understanding what caused the failure) can be both time-consuming and resource intensive.

To further provide context, developers normally compile code and then run a personal build. However, because of dependencies

with other modules, this locally compiled code cannot necessarily detect build failures; therefore, developers commit the code. However, once a whole set of changes is built, a class in a package can fail because of code changed in another class in another package, provoking a problem and failure during compilation or runtime testing. This problem is hard to detect by a developer who is unaware of changes made in other packages.

Current build systems today integrate code bodies, and perform continuous builds to verify that every piece of code works as expected. These systems, however, lack methodologies or components to determine the cause of a build failure .

Integrated Development Environments (IDEs) typically define what is missing within code or changes that might affect other features. However, on large products in which many pieces are assembled, long dependency chains are created. Code changes that locally seem not to impact other features, might in fact affect other key product components. Moreover, when a product code repository has frequent commits (e.g., an average of 30-60 commits or more every 24 hours is common for large projects), build breakdowns can badly impact schedules, as other deliveries stop until the break is resolved.

A system or method is needed to mitigate the occurrence of the dead hours during which code deliveries are impeded . The desired method must quickly ascertain the code responsible for the breakdown and enable the rapid execution of corrective action to reduce the negative impact to development schedules. In addition, a new solution must mitigate increasingly complex application development and delivery tasks.

The novel solution is a method and system to add components to automatically analyze build breaks and find the changes or set of changes that caused the failure. Further, the system can optionally identify the developer who created the offending code, and thus identify the developer who can best resolve the issue.

1


Page 02 of 6

Working in the background, this system monitors code deliveries taken by the concurrent versioning system (CVS), which is a component of any code repository, analyzes each piece of code affected by that change, and creates a map of all packages and classes impacted by the code deliveries. This analysis allows the...