Fireman Automatic Build System

The Fireman automatic build is a set of Perl scripts that automatically builds, tests, and releases new versions of the software whenever changes are committed to the CVS repository. This is better than a daily build - it's a continuous build. Continuous builds are based on the development philosophy that one always has a working system, always. All changes must be improvements - if the system worked before the changes, it must also work after the changes. And the only way to ensure this works-before-works-after invariant is to write the tests at the same time one writes code. Fireman compiles the code, runs the unit tests and the acceptance tests, and then builds the release. If there are no errors in any of that, then the build is good and the always-works invariant is maintained.

A Quick "How It Works"

The scripts are stored in the CVS repository in the Fireman module. The code is of varying quality, but the basic idea is that the FiremanCron.pl script is run with an initialization parameter specifying the build. E.g.,

     FiremanCron.pl --init=Website_init.pl
The FiremanCron script (so named because it is designed to be run on regular intervals by the cron daemon), looks at the CVS history for the appropriate module. If any commits have occured, the rest of the script invokes additional Perl modules to build, test, and release. The code is semi-documented and can be read by an average Perl programmer.

Our version is slightly more complex: we have a cron job that runs the runfireman.pl script every minute. This script checks for certain flag files, and if those files exist, it runs the FiremanCron.pl script. We use this trick to reduce the CPU, disk, and network overhead of running the cvs history command (contained in FiremanCron.pl) every minute. The flag files are set via the firemanloginfo.pl script, which is called bia the CVS loginfo control file (in the CVSROOT module of each repository):

DEFAULT         /cse/courses/cse403/02su/Fireman/firemanloginfo.pl %s

Fireman keeps each build in a separate directory so that each build is a from-scratch build. Additionally, Fireman reveals the statii of the builds through a set of automatically updated web pages. In the original Fireman scripts, the web pages were dynamically generated by a CGI script, but in the version we are using, the web pages are statically generated by Fireman and then placed on the web server.

Fireman is completely controlled by the configuration files. Each build (e.g., Foobar) has a Foobar_init.pl configuration file. There is also a generic_init.pl configuration file of all the common and global configuration information.

Fireman requires a small module in each CVS repository because Fireman uses cvs history to determine if it needs to run, but all cvs commands require a module (even when they don't use the module). We use an almost completely empty module named Fireman.History for this purpose.

The running Fireman code is stored in ~403admin/Fireman; the builds are in ~403admin/Fireman.builds; the flag files are in ~403admin/Fireman.flags; the Fireman CVS module is in the production-code repository.

Adding a New Build

Adding a new build, e.g., for CVS module FooBar, is quite simple:

  1. Log in as user 403admin
  2. Create the Foobar_init.pl file (as well as any targets that are referenced, such as FoobarLinuxTarget.pm - see code for details and examples) in the Fireman directory, e.g., /cse/courses/cse403/02su/Fireman.
  3. Create the build directory in the Fireman.builds directory, e.g. /cse/courses/cse403/02su/Fireman.builds/.
  4. Create the build.xml file for the compile step.
  5. Commit these changes to CVS.
  6. Manually run the first build via FiremanCron.pl --init=Foobar_init.pl --force. That first run will register the build and the system will automatically rebuild it whenever the appropriate flag file is set.
  7. If this new build includes an installer, there is more to do.

Notes:

Removing an Obsolete Build

To completely remove a build, e.g., for CVS module FooBar, one must remove all traces of it from all the places that it leaves files: the website, the build directories, etc.

  1. Remove its subdirectory from the build directory, e.g.,
        rm -rf /cse/courses/cse403/02su/Fireman.builds/FooBar
  2. (optionally) Remove the Foobar_init.pl and any Foobar*Target*.pm files from Fireman directory using CVS. This step is optional because leaving the files around will not harm anything, nor will it cause Foobar builds to occur.
  3. If the old build included an installer, there is more to do.

The Traffic Light

The traffic lights uses a VB server program on a number of computer (see generic_init.pl for list). The server listens to port 5353. When certain strings appear on that port input, the server sends commands to the relay control box attached to serial port 1. The relays switch the 120VAC to control the lights. Relay 1 is red, 2 is yellow, and 3 is green. Assuming that green is on most of the time, relays 1 and 2 are used NO and relay 3 is used NC.

The VB server is an NT service, although just barely. Using the MSDN article about VB NT services, the Traffic Light Server is an NT service. It starts and stops and logs informational messages. So far it hasn't crashed. To install and start the service:

  1. Use TrafficLightServer -install
  2. Change the "logon" properties to log on as the local Administrator
  3. Set the startup to Automatic

$Id: whatisfireman.html,v 1.17 2002/06/26 18:29:23 jwalker Exp $