Browse Prior Art Database

Dynamically restartable automated distributed multiplatform software build process

IP.com Disclosure Number: IPCOM000014505D
Original Publication Date: 1999-Dec-01
Included in the Prior Art Database: 2003-Jun-19
Document File: 2 page(s) / 46K

Publishing Venue

IBM

Related People

Jerrold Heyman: AUTHOR [+2]

Abstract

Disclosed here is a method and process for having a dynamically restartable automated distributed multiplatform software build process. The problem that is being solved is one that is prevalent among any software development shop that supports multiple platforms (where platform is defined as different OSes and/or different hardware). The goal is always to provide a way to deliver all platforms simultaneously. One method that accomplishes this objective is what is disclosed here.

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

Page 1 of 2

  Dynamically restartable automated distributed multiplatform software build process

    Disclosed here is a method and process for having a dynamically restartable automated distributed multiplatform software build process. The problem that is being solved is one that is prevalent among any software development shop that supports multiple platforms (where platform is defined as different OSes and/or different hardware). The goal is always to provide a way to deliver all platforms simultaneously. One method that accomplishes this objective is what is disclosed here.

    Currently, software create for multiple platforms can be difficult to do because of the fundamental differences within the different Operating Systems. Because of that, generic tools are generally used, and have to be watched to make sure that no build breaks (bad compilations, bad linking) take place. If a break does occur, then having to restart all the different platforms at an intermediate point can be difficult to accomplish. The build process used is basically the following:

1) Create the necessary baseline deltas
2) Extract the baseline code
3) Extract the delta created in step 1
4) Distribute the source code to the various platforms for local builds
5) Do the necessary configuration steps to build the software
6) Compile/Link the software on each platform
7) Collect all the various platform outputs in a central location
8) Package the necessary pieces of the software output into product

The goal of this invention was to have a single control point, and all the necessary steps being executed on each of the various platforms - as appropriate. A secondary goal was to make sure that new platforms could be introduced, others deleted, and even some ignored for a given build. Another main goal was the ability to pick and choose which of the eight (8) listed steps was to be executed and in what order.

    With the use of the Tivoli Management Agent (TMA), we can create a Tivoli Managed Region (TMR) that contains an endpoint machine for each platform that we wish to build on. Using the TMR, we can create a gateway that is the controller and have all the TMA's talking to it. A task library is created for each distinct product built, with all the eight (or more) steps identified as individual (or multiple) executable scripts. These scripts are written so that regardless of the platform that they execute on, there is only one script for each step - write once, run anywhere (to borrow Java's phrase). These scripts are then distributed to the endpoint and executed in parallel (where appropriate). The results of each task are then returned back to the controller which makes the determination as to whether the step/substep executed correctly and what action to take next. These actions are defined for errors, correct results, and even when the user has specified to skip steps. Because we are using a TMR, there is no requirement that the various endpoint platforms physically reside in the same r...