YOC4WW2T4CGI4OV6BRFOEPTBURZSIU7JSRH3B7HAT5DVHV2IPQQQC Hydra is a tool for continuous integration testing and softwarerelease that uses a purely functional language to describe build jobsand their dependencies. Continuous integration is a simple techniqueto improve the quality of the software development process. Anautomated system continuously or periodically checks out the sourcecode of a project, builds it, runs tests, and produces reports for thedevelopers. Thus, various errors that might accidentally be committedinto the code base are automatically caught. Such a system allowsmore in-depth testing than what developers could feasibly do manually:<p/><ol><li> <em>Portability testing</em>: The software may need to be builtand tested on many different platforms. It is infeasible for eachdeveloper to do this before every commit.<p/>
Hydra is a buildfarm system based on the Nix software deploymentsystem.
<li> Likewise, many projects have very large test sets (e.g.,regression tests in a compiler, or stress tests in a DBMS) that cantake hours or days to run to completion.<p/><li> Many kinds of static and dynamic analyses can be performed aspart of the tests, such as code coverage runs and static analyses.<p/><li> It may also be necessary to build many different <em>variants</em>of the software. For instance, it may be necessary to verify thatthe component builds with various versions of a compiler.<p/><li> Developers typically use incremental building to test theirchanges (since a full build may take too long), but this isunreliable with many build management tools (such as Make), i.e.,the result of the incremental build might differ from a full build.<p/><li> It ensures that the software can be built from the sources underrevision control. Users of version management systems such as CVSand Subversion often forget to place source files under revisioncontrol.<p/><li> The machines on which the continuous integration system runsideally provides a clean, well-defined build environment. If thisenvironment is administered through proper SCM techniques, thenbuilds produced by the system can be reproduced. In contrast,developer work environments are typically not under any kind of SCMcontrol.<p/>
<li> In large projects, developers often work on a particularcomponent of the project, and do not build and test the compositionof those components (again since this is likely to take too long).To prevent the phenomenon of ``big bang integration'', wherecomponents are only tested together near the end of the developmentprocess, it is important to test components together as soon aspossible (hence <em>continuous integration</em>).<p/><li> It allows software to be <em>released</em> by automaticallycreating packages that users can download and install. To do thismanually represents an often prohibitive amount of work, as one maywant to produce releases for many different platforms: e.g.,installers for Windows and Mac OS X, RPM or Debian packages forcertain Linux distributions, and so on.<p/></ol>
... advantages ...
In its simplest form, a continuous integration tool sits in a loopbuilding and releasing software components from a version managementsystem. For each component, it performs the following tasks:<ol><li>It obtains the latest version of the component's source codefrom the version management system.<li> It runs the component's build process (which presumably includesthe execution of the component's test set).<li> It presents the results of the build (such as error logs andreleases) to the developers, e.g., by producing a web page.
<li> They do not manage the <em>build environment</em>. The buildenvironment consists of the dependencies necessary to perform a buildaction, e.g., compilers, libraries, etc. Setting up the environmentis typically done manually, and without proper SCM control (so it maybe hard to reproduce a build at a later time). Manual management ofthe environment scales poorly in the number of configurations thatmust be supported. For instance, suppose that we want to build acomponent that requires a certain compiler X. We then have to go toeach machine and install X. If we later need a newer version of X,the process must be repeated all over again. An ever worse problemoccurs if there are conflicting, mutually exclusive versions of thedependencies. Thus, simply installing the latest version is not anoption. Of course, we can install these components in differentdirectories and manually pass the appropriate paths to the buildprocesses of the various components. But this is a rather tiresomeand error-prone process. <p/><li> They do not easily support <em>variability in softwaresystems</em>. A system may have a great deal of build-timevariability: optional functionality, whether to build a debug orproduction version, different versions of dependencies, and so on.(For instance, the Linux kernel now has over 2,600 build-timeconfiguration switches.) It is therefore important that a continuousintegration tool can easily select and test different instances fromthe configuration space of the system to reveal problems, such aserroneous interactions between features. In a continuous integrationsetting, it is also useful to test different combinations of versionsof subsystems, e.g., the head revision of a component against stablereleases of its dependencies, and vice versa, as this can revealvarious integration problems.</ol>
<em>Hydra</em>, is a continuous integration tool that solves theseproblems. It is built on top of the <a href="http://nixos.org">Nixpackage manager</a>, which has a purely functional language fordescribing package build actions and their dependencies. This allowsthe build environment for projects to be produced automatically anddeterministically, and variability in components to be expressednaturally using functions; and as such is an ideal fit for acontinuous build system.