What is the purpose of a dedicated "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?

Collectivize

Answer 1

The reason given is actually a huge benefit. Builds that go to QA should only ever come from a system that builds only from the repository. This way build packages are reproducible and traceable. Developers manually building code for anything except their own testing is dangerous. Too much risk of stuff not getting checked in, being out of date with other people's changes, etc. etc.

Joel Spolsky on this matter.

Linderman

Things get especially hairy when developers are building against bleeding-edge libraries, not realizing it and then getting "NoClassDefFound" errors all over the place during testing and everyone else wondering what the hell went wrong. (This was problematic in my Java-based job until I set up Hudson and we moved QA builds to that) – Sanitarium

Actually this is only a reason for building from a clean checkout, not for building from a dedicated build-agent on a dedicated build-server. Running an automated build-script in a clean checkout of the repository on a local developers machine already gives most of the advantages of a dedicated build-server. – Inception

One major benefit, IMHO, is that it forces you to use a buildsystem that will run 100% automated and highly encourages you to have zero buttons to push to get it started. It's not just that you then have a single source for releases and test builds, but also about making sure that people don't screw your build system. – Taveda

Answer 2

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.

Caddish

+1 Getting programmers to document changes to their build environment is like herding cats. They simply can't remember at what stage they updated their .Net or Boost lib, if they realize they did it at all. Having a central server doing a daily build catches them in the act the evening after they check in the code- and there's nothing quite as motivating as being told, "you broke the team build, what did you forget?" – Molini

Answer 3

What is their purpose?
Take load of developer machines, provide a stable, reproducible environment for builds.

Why aren't the developers building the project on their local machines, or are they?
Because with complex software, amazingly many things can go wrong when just "compiling through". problems I have actually encountered:

• incomplete dependency checks of different kinds, resulting in binaries not being updated.
• Publish commands failing silently, the error message in the log ignored.
• Build including local sources not yet commited to source control (fortunately, no "damn customers" message boxes yet..).
• When trying to avoid above problem by building from another folder, some files picked from the wrong folder.
• Target folder where binaries are aggregated contains additional stale developer files that shoulkd not be included in release

We've got an amazing stability increase since all public releases start with a get from source control onto an empty folder. Before, there were lots of "funny problems" that "went away when Joe gave me a new DLL".

Are some projects so large that more powerful machines are needed to build it in a reasonable amount of time?

What's "reasonable"? If I run a batch build on my local machine, there are many things I can't do. Rather than pay developers for builds to complete, pay IT to buy a real build machine already.

Is it I have just not worked on projects large enough?

Size is certainly one factor, but not the only one.

Precedent

Answer 4

A build server is a distinct concept to a Continuous Integration server. The CI server exists to build your projects when changes are made. By contrast a Build server exists to build the project (typically a release, against a tagged revision) on a clean environment. It ensures that no developer hacks, tweaks, unapproved config/artifact versions or uncommitted code makes it into the released code.

Blueness

great answer. upvote for the name as well. – Imminence

Answer 5

The build server is used to build everyone's code when it is checked in. Your code may compile locally, but you most likely won't have all the change made by everyone else all the time.

Axillary

Answer 6

To add on what has already been said :

An ex-colleague worked on the Microsoft Office team and told me a complete build sometimes took 9 hours. That would suck to do it on YOUR machine, wouldn't it?

Fredette

Answer 7

It's necessary to have a "clean" environment free of artifacts of previous versions (and configuration changes) in order to ensure that builds and tests work and don't depend on the artifacts. An effective way to isolate is to create a separate build server.

Substantialism

Answer 8

I agree with the answers so far in regards to stability, tracability, and reproducability. (Lots of 'ity's, right?). Having ONLY ever worked for large companies (Health Care, Finance) with MANY build servers, I would add that it's also about security. Ever seen the movie Office Space? If a disgruntled developer builds a banking application on his local machine and no one else looks at it or tests it... BOOM. Superman III.

Dunk

absolutely @Greg! Everyone here seems to have missed that part. I am right now working on a change control process for compliance that requires a secondary department deploy to production. Well, unless you want to teach IT how to use Visual Studio and deploy yada yada yada... this gives you a way to do this with quick clicks.Not sure how this is considered "useless" as some have said. – Prisoner

Answer 9

These machines are used for several reasons, all trying to help you provide a superior product.

One use is to simulate a typical end user configuration. The product might work on your computer, with all your development tools and libraries set up, but the end user most likely won't have the same configuration as you. For that matter, other developers won't have the exact same setup as you either. If you have a hardcoded path somewhere in your code, it will probably work on your machine, but when Dev El O'per tries to build the same code, it won't work.

Also they can be used to monitor who broke the product last, with what update, and where the product regressed at. Whenever new code is checked in, the build server builds it, and if it fails, its clear that something is wrong and the user who committed last is at fault.

Motherinlaw

Answer 10

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.

Ballon

Answer 11

We use one so that we know that the production/test boxes have the same libraries and versions of those libraries installed as what is available on the build server.

Matadi

Answer 12

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.

Rustice

Answer 13

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.

Brannen

Answer 14

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.

Joses

Answer 15

A build server gets you a sort of second opinion of your code. When you check it in, the code is checked. If it works, the code has a minimum quality.

Salomo

Answer 16

Additionally, remember that low level languages take much longer to compile than high level languages. It's easy to think "Well look, my .Net project compiles in a couple of seconds! What's the big deal?" Awhile back I had to mess with some C code and I had forgotten how much longer it takes to compile.

Append

IMHO, that's not so much about low-level vs. high-level languages, but rather about C's broken/non-existent module system (i.e. include files) vs. languages with a functioning module system. – Borsch

Answer 17

A build server is used to schedule compile tasks (e.g. nightly builds) of usually large projects located in a repository that can sometimes take more than a couple of hours.

Atilt

Answer 18

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.

Nerine