Build Systems: Relevancy of Automated Builds In A Web World

Often when I’m on a job interview, I’ll ask whether or not the company I’m talking with makes use of an automated build system of any kind. More often than not, the answer I get is somewhere along the lines of “build systems are irrelevant to the web; we can simply upload changes instantly.”

This thinking could not be farther from the truth. Build systems are just as relevant to the web (if not more so) than they are to compiled code. Build systems offer significant advantages to the development of software applications, and it is crucial that developers not take them for granted.

Here are my reasons for wanting a build system for web applications:

Build systems make continuous integration easier.
Having a build system is a critical component of a continuous integration server. For those who don’t know, continuous integration is a process whereby documentation is automatically created, the build is assembled, and the tests are run (among other things). This is a great way to ensure that the build is always “shippable” – that is, the unit tests pass and the documentation is ready to go.

Continuous integration requires a build system to run unit tests and create a shippable version of your software. Having a build system in place makes continuous integration that much more reasonable, and useful.

Build systems ensure that the same process is followed each and every time when making a release.
Ask four different developers how they release a web application and you’ll get four different answers. Even having documentation that outlines the steps, you’ll get slight deviations in the process. That’s the way human beings are; we’re unique, different, and individual. But the build process shouldn’t be.

An automated build process ensures that each and every time the application is built, the same process is followed. That might stand out as a “duh!” but the reality is that following the same process is absolutely crucial, especially when releasing software to a large audience. The potential for human error must be mitigated, lest a mistake get rolled into a release.

With a one-step system, errors are reduced.
An automated build system can still be flawed, if it requires more than one step to complete. This additional step or set of steps allows for the possibility of human error. But with a one-step build system in place, human error is almost reduced to zero.

Joel Spolsky makes a great case for why you should employ a one-step build system and I support him 100% in his assertions. Having come from an environment where creating releases was something I did, I do know that when you’re ready to create a shippable build, human error can creep in to any system that has more than 1 step.

Creating a build system reenforces the entire development process.
With a build system in place, there’s a formality to the development process that wasn’t there before. Code that is committed doesn’t simply go into the ether; instead, it is compiled into the latest build, tested, and documented. Developers relying on continuous integration see the immediate impact of their code. And since the build process probably includes testing (it should, anyway), there’s a formal process to getting code into the product.

Requiring automated builds and a build process ensures that the development process has a set of standards that must be followed when software is released. This is crucial to ensuring that the development cycle has a rhythm to it.

A build system introduces formality to the release process.
With a build system in place, when it comes time to make the release build, there’s a formality to the release that is different than simply “uploading the changes.”

I’ve found that when I prepare to “do a release” I am that much more careful, even if I’ve done a release a hundred times before. Why? Because my name is on it, and I have a process I must follow. It’s not something I do each and every day; it’s special.

When all you do to make a release is upload files to a web server, there’s nothing special about that. There’s nothing unique. In fact, you probably do it with some regularity. You’re not replacing the entire application with a new version; you’re just replacing a few files with some other files. This isn’t release management.

Build systems are still relevant. They haven’t gone out of style, and they still have a place in the development of applications, including applications that are compiled at runtime. There are lots of build systems out there, Phing being one of the more popular PHP-based ones for PHP projects.

Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP

Thiago Belem (@tiutalk) wrote at 1/11/2010 3:16 pm:

Yeah… that’s great! But what you think about small companies with small/mediu projects that don’t use all that bureaucracy?

Benjamin Dubois wrote at 1/11/2010 4:12 pm:

Hello,

@Thiago : in my company, we are 2 permanent developers and we work with freelances on our biggest projects. Continuous integration is very useful in our case because the newcomers just have to read our automagically generated phpdoc to understand our code, and can start working with it in a few hours.

Also, I think that for small businesses, a simple continuous integration server is a great basis for the creation of a strict quality process. It forces developers to follow some rules and helps keep quality in mind.

Brandon Savage (@brandonsavage) wrote at 1/12/2010 7:20 am:

The larger the project, the more stringent your standards should be. To me, having a continuous integration server and a build system is a requirement regardless of project size; I use one even for my own projects. It encourages unit testing, development cycles, and other good development practices.

Copyright © 2023 by Brandon Savage. All rights reserved.