Nightly Builds: Why should I do it? [closed]

You should do nightly builds to ensure that your codebase stays healthy.

A side effect of doing nightly builds is that it forces the team to create and maintain a fully automated build script. This helps to ensure that your build process is documented and repeatable.

Automated builds are good at finding the following problems:

• Somebody checked in something that breaks stuff.
• Somebody forgot to check in a necessary file or change.
• Your build scripts no longer work.
• Your build machine is broken.

Doing this nightly ensures that you catch such problems within 24 hours of when they occur. That is preferable to finding all the problems 24 hours before you are supposed to deliver the software.

You should also, of course, have automated unit tests that are run for each nightly build.

I've personally found continuous integration to be better than nightly builds:
http://en.wikipedia.org/wiki/Continuous_integration

I even use it on one man projects, it's amazing how fast you can expose issues and take care of them right there.

I've been doing build engineering (among other things) for 16 years. I am a strong believer in build-early, build-often, continuous integration. So the first thing I do with a project is establish how it will be built (Java: Ant or Maven; .NET: NAnt or MSBuild) and how it will be managed (Subversion or some other version control). Then I'll add Continuous Integration (CruiseControl or CruiseControl.NET) depending upon the platform, then let the other developers loose.

As the project grows, and the need for reports and documentation grows, eventually the builds will take longer to run. At that point I'll split the builds into continuous builds (run on checkin) that only compile and run unit tests and daily builds that build everything, run all the reports, and build any generated documentation. I may also add a delivery build that tags the repository and does any additional packaging for a customer delivery. I'll use fine-grained build targets to manage the details, so that any developer can build any part of the system -- the Continuous Integration server use the exact same build steps as any developer. Most importantly, we never deliver a build for testing or a customer that wasn't built using the build server.

That's what I do -- here's why I do it (and why you should too):

Suppose you have a typical application, with multiple projects and several developers. While the developers may start with a common, consistent development environment (same OS, same patches, same tools, same compilers), over the course of time their environments will diverge. Some developers will religiously apply all security patches and upgrades, others won't. Some developers will add new (maybe better) tools, others won't. Some will remember to update their complete workspace before building; others will only update the part of the project they're developing. Some developers will add source code and data files to the project, but forget to add them to source control. Others will write unit tests that depend upon specific quirks of their environment. As a consequence, you'll quickly see the ever-popular "Well, it builds/works on my machine" excuses.

By having a separate, stable, consistent, known-good server for building your application, you'll easily discover these sorts of problems, and by running builds from every commit, you'll be able to pinpoint when a problem crept into the system. Even more importantly, because you use a separate server for building and packaging your application, it will always package everything the same way, every time. There is nothing worse than having a developer ship a custom build to a customer, have it work, and then have no idea how to reproduce the customizations.

When I saw this question, first I searched for Joel Spolsky's answer. Bit disappointed, so I planned to add it here.

Hope everyone is aware of Joel Test on Careers.

From his blog on The Joel Test: 12 Steps to Better Code

3. Do you make daily builds?

When you're using source control, sometimes one programmer accidentally checks in something that breaks the build. For example, they've added a new source file, and everything compiles fine on their machine, but they forgot to add the source file to the code repository. So they lock their machine and go home, oblivious and happy. But nobody else can work, so they have to go home too, unhappy.

Breaking the build is so bad (and so common) that it helps to make daily builds, to insure that no breakage goes unnoticed. On large teams, one good way to insure that breakages are fixed right away is to do the daily build every afternoon at, say, lunchtime. Everyone does as many checkins as possible before lunch. When they come back, the build is done. If it worked, great! Everybody checks out the latest version of the source and goes on working. If the build failed, you fix it, but everybody can keep on working with the pre-build, unbroken version of the source.

On the Excel team we had a rule that whoever broke the build, as their "punishment", was responsible for babysitting the builds until someone else broke it. This was a good incentive not to break the build, and a good way to rotate everyone through the build process so that everyone learned how it worked.

Though I haven't got an opportunity to make daily builds, I'm a great fan of it.

Still not convinced? Check out the brief here in Daily Builds Are Your Friend!!

You don't actually, what you should be wanting is Continuous Integration and automatic testing (which is a step further than nightly builds).

If you are in any doubt you should read this article by Martin Fowler about Continuous Integration.

To summarize, you want to build and test as early and often as possible to spot errors immediately so they can be fixed while what you were trying to achieve when you caused them is still fresh in your mind.