Why should my development team have a build server?

We know this is good to have, but I find myself justifying i开发者_如何学JAVAt to my employer. Please pitch in on why a development team needs a build server.

There are multiple reasons to use build servers. In no particular order and off the top of my head:

1. You simplify the developers' workflow and reduce the chance of mistakes. Your build server can take care of multiple steps such as checking out latest code, having required software installed, etc. There's no chance of a developer having some stray DLLs on their machine that can cause the build to pass or fail seemingly at random.

   Your build server can replicate your target environment (operating system, etc.) and there's less of a chance of something working on developers' desktops and breaking in production.

2. While it's a good practice for developers to test everything they check in, sometimes they just don't. Then it's good to have the build server there to catch test errors and let the team know the product is broken.

3. Centralized builds provide easy access to code metrics -- which tests passed, which failed, how often, how well is your code covered by your tests, etc. Having a solid understanding of the quality state of the codebase reduces maintenance and testing costs by providing timely feedback that allows errors to be fixed quickly and easily.

4. Product deployment is simplified -- the developer or QA doesn't have to remember multiple manual steps. It can be easily automated.

5. The link between developers and QA is simplified. QA personnel can go to a known location to grab latest, propertly versioned builds.

6. It's easy to set up builds for release branches, providing an extra safety net for products in their release stage, when making code changes must be done with extra care.

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.

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.

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

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.

Two main reasons that non technical people can relate to:

• It improves the productivity of the dev team because problems are identified earlier.

• It makes the state of the project very obvious. I've shown my management the build status dashboard an now they look at it all the time.

One more thing. Something like Hudson is very simple to set up - you might want to simply run it somewhere in a corner for a while and then show it later.

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

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.