Automatic or Nightly Builds? When, Why, and Why Not

I've had two different development teams over the past couple of months try to convince me that implementing either nightly or automatic software builds is critical. Now I've been a part of many software development teams and none of them employed any of these builds. This includes a shrink wrap software package company that had a half dozen products built from a very large common code base and delivered for PC, Mac, and UNIX. It also includes an ASP (Application Service Provider, or now known as SaaS) that had a base web platform and application that was customized to hundreds of websites.

Even in my last post, Top 10 Tips On Version Control for Small Agile Software Teams, I received a number of comments regarding nightly builds. I did some poking around on the subject and found this relatively old, but good entry on Joel Spolsky's blog Daily Builds Are Your Friend.

So here are some examples where a nightly or automatic build makes sense:

• Your team is implementing unit tests. Unit tests can run as part of the nightly build and alert developers on errors.
• Developer instances may not have access to full data sets or production data. New tests can be built and automated for the nightly build to test and report on changes to the code (features) against a more complete data set.
  
• You have a QA member on the team that will perform functional and regression tests on the nightly builds.
• You want your stakeholders to review and comment on checked in features.
• You have other teams that perform other tests and validation. Maybe load testing, browser testing, or builds for multiple OS's.
• Your building a SOA set of shared services and want to run tests against older versions.
• You have multiple features being developed for a single release and may need to role back to a stable point if implementing one feature is dragging the time line. Let's call this lazy branching.

These are all good examples, but I still maintain that they're not necessarily the first thing a new development team should prioritize. Implement your nightly or automatic build when you find a customer (QA, stakeholder), a process (unit testing, load testing) or to address an issue.