Skip to topic | Skip to bottom


Home

Main
Main.BuildfarmProjectr1.1 - 19 May 2009 - 13:20 - RobVermaas

Start of topic | Skip to actions

Research Project: LaQuSo? Buildfarm

Introduction

An important recent development in software dependability research that is attracting world wide attention is the notion of a build farm, in which evolving software components are continuously and fully automatically retrieved from a version management system, compiled, analyzed, tested individually, and assembled and tested in all relevant configuration combinations.

The purpose of a build farm is to continuously build and test components from a version management system, thus providing feedback to developers of components and systems assembled from these components. Specific reasons why one wants a build farm include:

  • The software may need to be built and tested on many different platforms (i.e., portability testing). It is infeasible for each developer to do this before every commit.
  • Likewise, many projects have very large test sets (e.g., regression tests in a compiler, or stress tests in a database management system) that can take hours or days to run to completion.
  • It may also be necessary to build many different variants of the software. For instance, it may be necessary to verify that the component builds with various versions of a compiler.
  • Developers will typically use incremental building to test their changes (since a full build may take too long), but this is often unreliable with many build management tools (such as Make). That is, the result of the incremental build might differ from a full build.
  • It ensures that the software can be built from the sources under revision control (since developers commonly forget to place source files under revision control).
  • The machines on which the build farm runs ideally provides a clean, well-defined build environment. If this environment is administered through proper configuration management techniques, then builds produced by the system can be reproduced. In contrast, developer work environments are typically not under any kind of revision control.
  • In large projects, developers often work on a particular component of the project, and do not build and test the composition of those components (again since this is likely to take too long). To prevent the phenomenon of big bang integration, where components are only tested together near the end of the development process, it is important to test components together as soon as possible (hence continuous integration).

A secondary goal of a build goal is to support release management: a successful build also provides (binary) packages that can be installed by developers and users a possibly wide range of platforms.

We propose to establish a build farm as part of the NIRICT LaQuSo? Laboratory, which we call EBF, the Evolution Build Farm. The unique characteristics of this build farm include its support for distributed (global) software development, the inclusion of a growing collection of advanced analysis tools, and the focus on facilitating continuous integration for research groups.

The build farm will contribute to the objectives of NIRICT and its laboratories in the following ways.

  • First, setting up a build farm is a research topic in itself. How should variability be managed? Which configurations are likely to generate failures? How can faults be isolated so that we can proceed with builds in order to identify other potential errors? How can build farms be used in a setting for distributed (global) software development?
  • Second, a build farm can act as a testbed for all sorts of complex analysis techniques that can be applied to monitor the quality of evolving systems. At the Delft Software Evolution Laboratory we are developing various of such analyses, and the build farm will offer an excellent opportunity for advancing these techniques.
  • Third, any group developing software as part of its research, can benefit from the build farm. As such, our own research group will be one of the first users of this infrastructure. But usage need not be restricted to this, and can include researchers from any areas, such as embedded systems, microchip design, civil engineering, and so on.
  • Fourth, a build farm offers an excellent valorisation platform. Sophisticated analysis techniques aimed at improving dependability will be included, and companies can make use of the build farm services.
  • Last but not least, while not a direct research goal, the build farm will play a key role in software engineering education. Initially, MSc students can make use of the build farm services, but as the build farm matures, we will include these services in all computer science courses including a substantial programming component.

Team

  • Eelco Dolstra
  • Rob Vermaas
  • Eelco Visser

Publications

  • Eelco Dolstra and Eelco Visser. The Nix Build Farm: A Declarative Approach to Continuous Integration. In International Workshop on Advanced Software Development Tools and Techniques (WASDeTT? 2008), Paphos, Cyprus. July 2008.

Relevant Links

Public Links


CategoryResearchProject


Main.BuildfarmProject moved from Main.BuidlfarmProject on 19 May 2009 - 13:14 by RobVermaas - put it back
You are here: Main > BuildfarmProject

to top

Copyright © 2003-2017, Software Engineering Research Group, Delft University of Technology, The Netherlands