And it’s like… what’s the deal with build servers?
The simplest way I can think of to explain a build server is to imagine hiring a brand new developer for each code check in, giving them explicit instructions to accomplish the build, and letting them go at it. Maybe that requires a bit of explanation — the idea of a build server is to provide a reproducible set of instructions/steps to accomplish building your application from start to finish without requiring additional input from the developer checking in the code.
As a developer without a build server, you might be in a situation where you have a project that builds perfectly fine locally, but when another developer attempts to build your latest bits, you encounter compile errors as far as the eyes can see. I unfortunately have experienced such a situation for each project I have pulled from source control (in instances where a build server was not used) — not that I fault the organization, persons, or projects involved — if you don’t know better, you don’t know better.
Once you do know about build servers, I do feel it is important to implement one if at all possible, as they are relatively easy to configure, and once done, an inordinate amount of time can be saved across developers.
I only really see two reasons to not utilize a build server… and one is more of an excuse than a reason. The first reason was mentioned above, if you don’t know about a build server process, then you likely wouldn’t have one. The second reason (the excuse) — would be thinking it’s “too hard” or “not worth it” to set up. If the build server is too hard to set up, that likely means your manual build process is quite complex, and could likely benefit *more* from a build server than a simple application. If grabbing a project from source control for the first time gives you a nice 10–15+ errors, which can take anywhere from 5 minutes, to several hours to resolve — and involve several developers — then you really need to think about what needs to be changed in order to fix that.
Are there external libraries being utilized that need to be added to source? Are there several SDKs missing from the developers machine required to build? Did I miss something in check in that would not allow the next developer to build? All of those questions can be quite difficult to deduce when building locally. With a build server, it’s like a *separate* developer working on a project for the first time, every time, at every check in.
If some new dependency is added to the project and is missed in the check in, the build server will immediately report failure and the developer (could) be notified as such, and actions can be taken to correct. Without a build server, it could be quite the mystery as to why a project all of a sudden won’t build, or why a project will not build for the first time.
So why don’t you have a build server yet?
Other build servers include (but are not limited too):
Having a build server gets you and/or your organization a lot of benefit, but in my opinion, one of the best benefits is the ability to implement automated deployment. Once a build is completed, your project’s bits can be deployed to your next environment, AUTOMAGICALLY.
Originally published at kritner.blogspot.com on January 21, 2015.