Search: 

Home
Overview
Search
Mailing lists
Forum
FAQ

Nightly Builds

Nightly builds are a good thing, they provide immediate feedback to developers if they broke the build. Having a nightly build means that the software stable and is likely to build for new users.

Software that is not built regularly is difficult to release. McCarthy says "If you build it, it will ship".

Nightly builds and Testing

An essential part of the nightly build is to actually run the software, ideally with a test suite.

Test results from nightly builds provide developers with feedback on how their test suite is progressing

Nightly builds are very important when there is deadline pressure, running the nightly build several times a day can result in improved stability.

Nightly Build Strategies

Nightly builds really should be separate from your development tree, so the nightly build should not interfere with work by developers. If a dummy user account is used to run the builds, then it is much easier to configure the build environment properly and not have it break from minor environment changes.

If the nightly build involves bootstrapping a compiler, it is best if the path of the dummy user account includes the basic directories that the operating system originally included, and whatever other directories are necessary

The cron facility can be used to start up a script that runs the nightly build itself. The cron entry below runs the ptIInight.cron script that sends email to the ealtech alias

30 3  * * * csh -c "/users/ptII/adm/bin/ptIInightly.cron ealtech"
The cron entry should be as simple as possible. If the nightly build is run as a script, it is much easier to run the script by hand when debugging.

Ideally, the nightly build will check out the current source tree and build using those sources.

Build Culture

Nightly builds promote cooperation between developers, since there is a fair amount of social pressure not to break the build.

Usually, it is better when developers work in fairly small steps, and check in their working code on daily regular basis in such a way so that their changes do not break the build.

Obviously, this is not always possible, but we have found that code that is kept out of the tree for a long period of time tends to cause problems when it is finall checked in.

Nightly builds don't solve this problem, but the build can help identify code that is not present in the build.

The future

Eventually, nightly builds could be run on gigasource. Groups could receive nightly email with build log information and with code coverage statistics.