Browse Prior Art Database

Build crash recovery with output-oriented build script

IP.com Disclosure Number: IPCOM000234668D
Publication Date: 2014-Jan-28
Document File: 7 page(s) / 90K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed are a method and system that allow the execution of respawn software build processes. The method splits the software build processes into smaller pieces and focuses on the availability of shared machines and storage to process the builds and keep process data.

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

Page 01 of 7

Build crash recovery with output-oriented build script

Software developers (and software testers) rely on an external or internal infrastructure to compile or execute a program. Most of the executions are time-sensitive. This requirement increases the demand on the infrastructure, which results in increased

maintenance cost, reduced efficiency, and increased recovery time (and cost) for a failure of the infrastructure. One of the biggest problems in such environments is the inability to recover from an unexpected failure at the software level (and hardware level) with

minimum human intervention.

Most solutions rely on creating duplicated configurations and creating a backup process, which involves medium to high human

intervention. An example of such configuration is setting up two machines to act as one another 's back up (or in larger scale setting up clusters of machines). Although this might be a good solution for program execution, as it offers load balancing and other needed features, it lacks the ability to adopt (by learning from previous execution history) and lacks ability to allow the system to automatically recover from a failure with minimum human interaction, which then requires executing the program from the initial

state.

The novel contribution is a method that allows the execution of respawn software build processes . The method splits the software build processes into smaller pieces (e.g., tasks, artifacts, and actions) and focuses on the availability of shared machines and storage to process the builds and keep process data. This focus helps avoid losing process contexts and information between the respawn executions.

The method improves the software build recovery process efficiency by allowing a continuous execution of software build processes. Even in the event of a failure, the method enables the system to obtain the software build information from the shared storage area and select another available machine to continue with the build processes. In addition, the method reduces the human intervention needed to maintain machine backups, duplicate machine environments, and monitor and restart build processes.

The build system contains a set of build machines. These machines are used to execute the actual build job. First, the entire build

job is submitted to the queue system. The queue system then determines whether any machines meet the job criteria. If yes, then the system dispatches the job to it.

The queue system regularly pings the build machine to make sure it is still alive. If the check continuously fails within certain period, then that machine is considered down, and the queue system dispatches the job to the other build machine. The Build

1


Page 02 of 7

Registry is a database that keeps track of all the active build jobs. For each of the jobs, it states the active build machine that is running it. The network file system (or shared drive) is a network shared drive accessible by each of the build mac...