14

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)?

Jed Daniels
  • 24,376
  • 5
  • 24
  • 24
  • 2
    So you don't have to stay late next Friday babysitting the build? – Adam Vandenberg Dec 04 '10 at 05:22
  • 3
    I honestly cannot recall when I was last on a project that did not have an automated build running on every single check in and running all the unit tests. People still operate with anything less in a professional development environment? – cfeduke Dec 04 '10 at 05:26
  • @cfeduke, I've come across companies without SCMs. CI and automated testing, to a lot of companies is still new and very foreign. The desktop UI world has been in really bad shape because the tools and techniques have been out of reach for most teams. That's finally changing in the latest MS frameworks. – Jim Rush Dec 04 '10 at 13:14
  • That kills me. Its like the first thing I always do when I start a project. Hudson is so easy to setup and free. TeamCity is free for 20 projects and pretty easy to setup. TFS practically forces it if you really like MS and trust them to do source control. And CruiseControl and its .NET version are free. Then I guess there is Maven for Java but that's a whole other beast I have very little knowledge about. – cfeduke Dec 04 '10 at 16:05
  • This isn't an answer, really, but pulling human error out of the equation is paramount to good builds. Today, because we don't have a Phonegap/Android/iOS build server, I've already screwed up three builds because I missed either an hg pull or a build step. Computers, once given instructions, don't make mistakes like humans do. –  Jan 30 '14 at 19:39

6 Answers6

13

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.

Community
  • 1
  • 1
Sam Ritchie
  • 10,988
  • 4
  • 42
  • 53
2

Allow me to begin by blatantly ripping off Wikipedia. Bear in mind, these are the general benefits of continuous integration, of which nightly builds should be considered a partial implementation. Obviously, your system will be more powerful if you couple nightly builds with your bed of automated (unit, functional, etc.) tests.

Advantages:

  • when unit tests fail or a bug emerges, developers might revert the codebase back to a bug-free state, without wasting time debugging
  • developers detect and fix integration problems continuously - avoiding last-minute chaos at release dates, (when everyone tries to check in their slightly incompatible versions).
  • early warning of broken/incompatible code
  • early warning of conflicting changes
  • immediate unit testing of all changes
  • constant availability of a "current" build for testing, demo, or release purposes
  • immediate feedback to developers on the quality, functionality, or system-wide impact of code they are writing
  • frequent code check-in pushes developers to create modular, less complex code
  • metrics generated from automated testing and CI (such as metrics for code coverage, code complexity, and features complete) focus developers on developing functional, quality code, and help develop momentum in a team

If we're just talking about a nightly build strategy in isolation, what you get is a constant sanity check that your codebase compiles on the test platform(s), along with a snapshot in time detailing who to blame. Couple this with automated testing and a sane strategy of continuous integration, and suddenly you have a robust suite that gives you who failed the tests in addition to who broke the build. Good deal, if you ask me.

You can read about the disadvantages in the remainder of the article, but remember, this is Wikipedia we're talking about here.

MrGomez
  • 23,788
  • 45
  • 72
  • 1
    Given the follow-up answers, I'm assuming you're already aware of continuous integration and are indeed asking about the benefits of daily builds in isolation. http://stackoverflow.com/questions/4352091/why-automate-builds/4352097#4352097 is the superior answer. – MrGomez Dec 04 '10 at 05:39
1

Because,

  1. Integrity of your Unit Test is automatically tested. So you need not to worry about functionality of your program is not broken because of changes made by others.

  2. Automatically gets the latest Checked-In files and compiles, so any compile error caused by other reported.

  3. Instant e-Mail acknowledgment on failure and successful execution of build. So you get to who failed the build.

  4. Can be integrated with Code Standard Tool like FX cop, Style Cop for .Net. So while build it automatically checks the Coding Standards.

indiPy
  • 7,844
  • 3
  • 28
  • 39
  • that's nice, but you haven't said *why* you should use 'cruise control' or automated builds...only its features, which apparently aren't a good enough reason. – mpen Dec 04 '10 at 05:30
1

I think that...

So that you know when you've broken something as soon as possible and can fix it while it's still fresh in your head, rather than weeks later.

is easily my favorite, but here are some other reasons blatantly stolen when I was just searching for reasons why you wouldn't use CI:

  • Code you cannot deploy is useless code.
  • Integrating your code changes with the code changes of other people on the team.
  • I sometimes forget to run ALL the unit tests before I check in. My CI server never forgets.
  • Centralized status of your code which can help with communication. (If I checked in broken code and someone else has to be a deployment... well this goes back to my favorite reason.)
cfeduke
  • 23,100
  • 10
  • 61
  • 65
  • Just a minor quibble: Code you cannot deploy can, in fact, be quite useful code. You're not deploying all your tests, are you? Some sidelines of development intended for later are usually not deployed, either. And some parts you'll want to keep to yourself, like generation of license keys or similar, so that is not deployed either. – foo Dec 04 '10 at 06:55
  • What that means is if you cannot deploy your code base all of your work is for nothing. Tests, signing, utilities, whatever, its all meaningless if you don't have something that deploys. – cfeduke Dec 04 '10 at 16:06
0

If one doesn't do full builds on a regular basis, one can end up with a situation where some part of a program that should have been recompiled isn't, that the failure to compile that part of the program conceals a breaking change. Partial builds will continue to work fine, but the next full build will cause things to break for no apparent reason. Getting things to work after that can be a nightmare.

supercat
  • 77,689
  • 9
  • 166
  • 211
0

One potential social benefit: automated builds could decrease toxicity among team members. If developers are repeatedly carrying out a multi-step process one or more times per day, mistakes are going to creep in. With manual builds, teammates might have the attitude, "My incompetent developers can't remember how to do builds right every day. You'd think they have it down by now." With automated builds, any problems that come up are problems with a program - granted, a program that someone wrote, but still.

Daniel Neel
  • 1,197
  • 13
  • 28