Why should my development team have a build server?

Question

We know this is good to have, but I find myself justifying it to my employer. Please pitch in on why a development team needs a build server.

Answer 1

This should sum up why it is critical to have a build server:

http://www.codinghorror.com/blog/2006/10/the-build-server-your-projects-heart-monitor.html

Answer 2

To avoid the "but it works on my box" issue.

Have a consistent, known environment where the software is built to avoid dependencies on local dev boxes.

You can use a virtual server to avoid (much) extra cost if you need to.

Answer 3

ASAP knowledge on what unit tests are currently working and which do not; furthermore, you'll also know if a once passing unit tests starts to fail.

Answer 4

This is my principal argument:

• all official releases must be build in a controlled environment. No exception.

simply because you never know how the developers create their personal releases.

You also don't need to talk about build server as in "blade that costs an arm a a leg". The first build server I set up was a desktop machine that sat unplugged in a corner. It served us very well for more than 3 years.

One you have your build machine, you can start adding some features (Hudson is great) and implement everything that the other posters mentioned.

Once your build machine becomes indispensable to your organization (and everyone sees its benefits), you will be able to ask for a shiny new blade if you wish :-)

Answer 5

The simplest thing you can do to convince your your employer to have a build server is to tell them that they will be able to release faster and with better quality.

Faster releases come from the immediate feedback about quality of the build. If someone breaks the build, he or she can fix the broken build immediately thus avoiding a delay in the build and release schedule. Without a build server the team will have to spend time trying to find what and when happened and how to fix it.

Better quality is achieved by the build server running bug detection tools automatically every time someone check is changes into a version control system. You don't mention what is the main development language in your organization, but such tools, advanced but commercial and simple but free, exist practically for all languages. Lint, FxCop, FindBugs and PMD come to mind.

You may also check this presentation on benefits of continuous integration for a more extensive discussion.

Answer 6

It's a continuous quality test dashboard; it shows you statistics about how the quality of your software is doing, and it shows them to you now. (JUnit, Cobertura)

It makes sure developers aren't hamstrung by other developers breaking the build, and encourages developers to write better code. (FindBugs, PMD)

It saves you time and money throughout the year by getting better code from developers the first time - less money on testing and retesting - and by getting more code from the same developers, because they're less likely to trip each other up.