What is the point of a “Build Server”? [closed]

Question

I haven't worked for very large organizations and I've never worked for a company that had a "Build Server".

What is their purpose? Why aren't the developers building the project on their local machines, or are they? Are some projects so large that more powerful machines are needed to build it in a reasonable amount of time?

The only place I see a Build Server being useful is for continuous integration with the build server constantly building what is committed to the repository. Is it I have just not worked on projects large enough?

Someone, please enlighten me: What is the purpose of a build server?

Answer 1

Build servers are important for several reasons.

• They isolate the environment The local Code Monkey developer says "It compiles on my machine" when it won't compile on yours. This can mean out-of-sync check-ins or it could mean a dependent library is missing. Jar hell isn't near as bad as .dll hell; either way, using a build server is cheap insurance that your builds won't mysteriously fail or package the wrong libraries by mistake.

• They focus the tasks associated with builds. This includes updating the build tag, creating any distribution packaging, running automated tests, creating and distributing build reports. Automation is the key.

• They coordinate (distributed) development. The standard case is where multiple developers are working on the same code base. The version control system is the heart of this sort of distributed development but depending on the tool, the developers may not interact with each other's code much. Instead of forcing developers to risk bad builds or worry about merging code overly aggressively, design the build process where the automated build can see the appropriate code and processes the build artifacts in a predictable way. That way when a developer commits something with a problem, like not checking in a new file dependency, they can be notified quickly. Doing this in a staged area let's you flag the code that has built so that developers don't pull code that would break their local build. PVCS did this quite well using the idea of promotion groups. Clearcase could do it too using labels but would require more process administration than a lot of shops care to provide.

Answer 2

Maybe i'm the only one...

I think everyone agrees that one should

• use a file repository
• do builds from the repository (and in a clean environment)
• use a continous testing server (e.g. cruise control) to see if anything is broken after your "fixes"

But no one cares about automatically built versions. When something was broken in an automatic build, but it's not anymore - who cares? It's a work in progress. Someone fixed it.

When you want to do a release version, you run a build from the repository. And i'm pretty sure you want to tag the version in the repository at that time and not every six hours when the server does it's work.

So, maybe a "build server" is just a misnomer and it's actually a "continous test server". Otherwise it sounds pretty much useless.

Answer 3

For consistent quality and to get the build 'off your machine' to spot environment errors and so that any files you forget to check in to source control also show up as build errors.

I also use it to create installers as these take a lot of time to do on the desktop with code signing etc.

Answer 4

A build server also gives you a basis for escrow, being able to capture all the parts necessary to reproduce a build in the case that others may have rights to take ownership.

Answer 5

It's about management and testing for us. With a build server we always know that we can build our main "trunk" line from version control. We can create a master install with one-click and publish it to the web. We can run all of our unit tests each time code is checked in to make sure it works. By collecting all these tasks into a single machine it makes it easier to get it right repeatedly.

Answer 6

You are right that developers could build on their own machines.

But these are some of the things our build server buys us, and we're hardly sophisticated build makers:

• Version control issues (some have been mentioned in earlier responses)
• Efficiency. Devs don't have to stop to make builds locally. They can kick it off on the server and get on to the next task. If builds are large, then that is even more time the dev's machine is not occupied. For those doing continuous integration and automated testing, even better.
• Centralization. Our build machine has scripts that make the build, distribute it to UAT environments, and even to production staging. Keeping them in one place reduces the hassle of keeping them in sync.
• Security. We don't do much special here, but I'm sure a sysadmin can make it such that production migration tools can only be accessed on a build server by certain authorized entities.