Nightly Software Building and Tagging

http://mail.gnu.org/pipermail/info-cvs/2001-August/018972.html

By Teala Spitzbarth <teala@intersan.net>

This email describes how one company uses CVS to do a nightly build and tag; here are some interesting editted snips from this email.

Nightly builds involve tagging the module with a descriptive tag of the format "bl_projectData_time", such as "bl5_project14Aug01_0000"

Can anyone explain the point of this? CVS can checkout a project as it appeared at a specific date and time, without using a tag. Regular tags therefore seem superfluous. I'd skip straight to the next bit. --jammin

I guess just to make it super-obvious when looking at a list of tags, build logs, automated emails, and so on. --Wim

It's so that you can tell what changed between the two points. When in a distributed team (12 timezones apart New Zealand/UK) it can be very difficult to find a "quiet period" where no one is checking code in. So, to have a hope of producing something consistent, we found it necessary to use tags. Then it is possible to do the whole "on hook", "responsible for failed build" kind of thing. In a more agile environment, with continuous builds, this becomes even more important, since the set of changes (and developers) between any two points is smaller. It's all about attribution, and increasing the peer pressure on individuals to keep the code base in a useable state. :) -- Jason Pollock

When one of those nightly builds (or requested build during the day) is deemed to pass acceptance criteria and enters QA, it is retagged with a formal build level tag such as "PROJECT_BL5"

When there is a new build, the tree is closed to new development for a short period of time. This allows QA to do a quick check to see that it is generally acceptable, and to do some cleanup of tags in CVS.

Development on the main tree now continues

If QA needs something fixed in a build in order to finish testing it, then it is branched. For example, a "PROJECT_BL5-fixes" branch is created based off of the "PROJECT_BL5" build tag. Fixes are then done first on this branch, then forward ported to the main development tree.

Fixes on the fixes branches are not automatically merged back into the main tree. This is because, often, the fix is not the same; i.e., the code in the main tree has already been rewritten and will require a different fix, or maybe no change at all.

When the fixes are rolled into the new build, it would get tagged as well, such as "PROJECT_BL5-2"

All tagging is done automatically by nightly build scripts that do everything from tagging the tree, pulling the source code, building the code, doing unit tests on multiple operating systems, creating CDs, and posting the results of the entire process.

Ongoing development builds are done at night by a cronjob, while branch fix builds are started manually

A tool that automates nightly builds is Anthill Build Management Server.

Parabuild Server supports both continuos integration and stable scheduled (nightly/daily) builds.

... back to Software Engineering Resources