Continuous Integration Myth: CI vs Nightly Builds
This particular myth was one I hadn’t anticipated, but I’ve seen variations repeated often enough to convince me that there is some confusion about the relationship between continuous integration and nightly (or indeed daily) builds.
The first point to clarify is that having a build that runs daily is not the same as practicing continuous integration. Daily is just not frequent enough — indeed the goal should be a new build for every change, or continual builds if the former is impossible. Add on top of that the fact that having a build server is not the same as CI, and it’s clear that we are talking about different beasts.
Where things get more interesting is when people start to ask questions like “Is there any value in a nightly build when you are already practicing CI?”. It may seem, if you’re building twenty times a day, that there’s little point building a twenty-first time overnight. But far from making a nightly build redundant, a CI setup can include nightly builds as a complement to the normal continuous builds. Let’s look at some common examples:
- Fast Build/Slow Build: larger projects can often develop a test suite that takes hours to run. Although the goal should be to cut this time down mercilessly, the reality is some forms of testing are slow. A common workaround is to split the slower tests out of the continuous build (to keep it fast), and run a nightly build with the full test suite.
- Nightly Releases: a build can be used to release a full package nightly based on the last known good revision. This is a good example of how the CI build complements the nightly — by identifying the most recent revision that passed all tests, making the nightly releases more reliable.
- Resource Intensive Builds: the idle hours in the night are a great time to run tests that require a lot of resources, as the build can make use of hardware that would normally be tied up during the day.
So, nightly builds are not CI, but at the same time a CI setup should not neglect nightlies altogether.
This entry was posted on Tuesday, January 27th, 2009 at 4:53 am and is filed under Agile, Build, Continuous Integration, Opinion, Technology, Testing. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

January 28th, 2009 at 12:29 pm
Mark says:I thought you might appreciate this case study about a financial company that is doing frequent integration builds with a longer nightly build.
http://damonpoole.blogspot.com/2008/05/agile-case-study-litle-co.html
I find Damon’s blog enlightening.
More details on that continuous integration at Litle is here:
http://www.accurev.com/case-studies.html
Mark
January 30th, 2009 at 2:37 am
Hi Mark,
Thanks for the comment. I’ve seen a few posts from Accurev in this area which are interesting.
December 29th, 2009 at 8:34 am
A blind spot of Continuous Integration « Schneide Blog says:[…] For a good comparison of CI vs. Nightly Builds see this blog entry. […]
August 23rd, 2011 at 12:23 am
Tomek Kaczanowski says:I’ve also blogged about the CI vs. nightly build issue at http://www.dzone.com/links/r/why_nightly_build_is_a_musthave_tomeks_blog.html
The main point is, that while CI is great for making sure that changes in your code were ok, the nightly build tells you if changes in your environment were also fine.
—
Cheers,
Tomek Kacanowski