Why automate builds?

Question

So, I'm a firm believer in having automated builds that run nightly (or even more often), especially during the late phases of a project. I was trying to convince a colleague tonight that we need to make some changes to facilitate this, and he challenged the whole premise of having automated builds in the first place. It is late on a Friday night, I've had a long week, I'm tired, and I honestly couldn't come up with a good answer. So, good people of the amazingly awesome Stack Overflow community, I come to you with this simple question:

Why have an automated build (or why not)?

Answer 1

I have a continuous integration server set up in a VM that mimics my production environment; by running automated builds, I know a LOT sooner when I've done something to screw up the code, and can make moves to fix it.

In a project with multiple people, especially larger projects, there are no guarantees that every user is running the tests and doing a full build. The longer you go without a full build, the greater the chances that some bug will sneak its way into the system while each dev is plugging away at his branch. Automated builds negate this issue by making sure the whole team knows, within the day or so, when something went wrong, and who was responsible.

For more backup, especially when tired, you might send over this article from our own Jeff Atwood, or this one from Joel Spolsky. From this last:

Here are some of the many benefits of daily builds:

When a bug is fixed, testers get the new version quickly and can retest to see if the bug was really fixed.

Developers can feel more secure that a change they made isn't going to break any of the 1024 versions of the system that get produced, without actually having an OS/2 box on their desk to test on.

Developers who check in their changes right before the scheduled daily build know that they aren't going to hose everybody else by checking in something which "breaks the build" -- that is, something that causes nobody to be able to compile. This is the equivalent of the Blue Screen of Death for an entire programming team, and happens a lot when a programmer forgets to add a new file they created to the repository. The build runs fine on their machines, but when anyone else checks out, they get linker errors and are stopped cold from doing any work.

Outside groups like marketing, beta customer sites, and so forth who need to use the immature product can pick a build that is known to be fairly stable and keep using it for a while.

By maintaining an archive of all daily builds, when you discover a really strange, new bug and you have no idea what's causing it, you can use binary search on the historical archive to pinpoint when the bug first appeared in the code. Combined with good source control, you can probably track down which check-in caused the problem.

When a tester reports a problem that the programmer thinks is fixed, the tester can say which build they saw the problem in. Then the programmer looks at when he checked in the fix and figure out whether it's really fixed.