How important are daily builds? [closed]

Question

One of the criteria of the Joel Test is daily builds. The idea is that if the build is broken, whoever broke it is around to fix it up. If the build cannot be fixed, everyone will have to check out an old version and work on that. I can understand how this can be pretty bad on centralised version control where it is important to avoid merging and branching as much as possible, but this only sounds like a minor nuisance for distributed version control. Do you agree with this? Are there other reasons why daily builds are important?

Answer 1

I think what's important to note here is that regular builds help catch errors sooner rather than later. It doesn't have to be daily, but often enough. Ideally, it can also run your unit tests.

The goal is to find out when a build breaks before the final testing phase, to find them as soon as possible.

Just set it up to build your main development branch(es).

We use it at work (although we build hourly), and often when we forget to set-it up we find about problems just hours before releasing.

Answer 2

Need to add a bit to this (and @GoodEnoughs):

but this only sounds like a minor nuisance for distributed version control.

Emphatically no - what a "server" build does is tell you that your trunk will build and pass its tests more or less from clean (the less is the amount of config you need to do of your environment).

I'm contemplating a switch to DVCS but even having done so you will drag my continuous integration from my cold dead hands.

To take a simple example - you're developing feature "a" he's developing feature "b" distributed or not at some point you need to stitch it all together - if, when you commit, you forget to add a file the app will build on your machine but it won't anywhere else. So when you push the build to your "trunk" the Continuous Integration will trigger and the build will fail and you will know and hopefully before anyone pulls your not quite so complete code you'll be able to take steps.

If you're working on a project with multiple developers you've got to be able to define where release versions come from - the trunk in effect - this is true regardless of how your version control works.

If you've added a feature - especially one on which other people have a dependency - to be able to be confident that when it is pushed to "live" that it builds and passes tests somewhere other than your dev environment is huge. More than that, I deploy from builds from my build server - its kind of how one specifies the "definitive" build. Ultimately I'm going to have user triggered deployment builds. Its no good saying that you can work round it - you can't if you need it (and I have scrambled round dev boxes in an office to find and commit missing files).

Is that all a bit strong? Don't know - but my build server is one of those things that having got I have no wish to give back.

Answer 3

Daily builds I believe are very important. If you have a distributed team in different time-zones then it is best to find time which is roughly 'end-of-day' for most of the team. In addition if the daily builds have a automated test component then it is more desirable.

In the days of central source control systems, I would advocate continuous builds running every 5-10 minutes when anything is changed in source code. Since a compilation error has a potential of slowing most of the team. For organisations running distributed source control systems, a continuous build might not be needed as much since developers touch the 'pristine' code-base directly less often.

Answer 4

Ideally, unless you're building something massive that takes over half a day to build, you would build more than once a day. Once you've set-up a continuous integration server, such as Hudson or TeamCity, the builds will happen automatically, typically every hour or on every commit, and you'll will be notified if there are any problems.

It's a good way to catch errors early, especially if you are also running automated tests as part of the build. It's particularly useful for finding configuration errors where the build works on one developer's machine but doesn't work elsewhere because something was omitted from the repository or the environment.

The more advanced continuous integration servers also allow you to track metrics over time (e.g. code coverage percentage, build time, lines of code, etc.)

Answer 5

Daily Builds are okay. You definietly need them if you have nothing else but to be honest I think Joel's test is a little out dated these days.

In my opinion you should be building continuously through out the day, running your unit, system and functional level test cases and ideally packaging and deploying to a stage like environment at the same time while verifying that any DB and environment versioning mechanisms you have in place are working as expected.

If build or deployment times are excessive then consider optomizing away some of these problems with physical or software ram disks, faster internet connections, parallellizing builds, etc. The time you will save by rapidly identifying build breaks is going to amoratize the hardware cost pretty rapidly.

Answer 6

Daily builds aren't important. Daily builds that always are successful are (or ones where it's only broken for an hour). Having CI when the build is broken 70% of the time isn't very useful, because if the thing is mostly broken it doesn't help you identify an error.

Answer 7

I think it should be daily build, test and deploy to staging server.

The idea behind 'daily build' is to always have something ready which testers and project managers can run so that everyone has an idea of what the real state of the project is.

In the past with desktop apps after the 'daily build' a tester or project manager can immediately run the app so no deploy step had to be mentioned.