Build Systems: Relevancy of Automated Builds In A Web World
Out Of Date Warning
Languages change. Perspectives are different. Ideas move on. This article was published on January 8, 2010 which is more than two years ago. It may be out of date. You should verify that technical information in this article is still current before relying upon it for your own purposes.
- Painless Spec and Schedule Development
- Integrating Source Control Into Your Projects
- Tracking and Fixing Bugs In Software Projects
- How To Win Developers and Influence Code Quality
- Build Systems: Relevancy of Automated Builds In A Web World
- Testing: Making Sure Code Works Before Shipping It
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.