Build Scripts? We Don't Need No Stinkin' Build Scripts!
If your undergraduate studies were anything like mine, you found yourself woefully unprepared for the work of a good software craftsman. It isn't that my education was bad - it was actually quite good and I wouldn't trade the experience. In fact, it prepared me very well to begin a career as a professional computer scientist. However, life as a software craftsman, delivering value through working software to customers day in and day out, and life as a computer scientist doing academic research are two vastly different occupations.
What we've got then is a crop of new developers that don't know, among other things, what automated build systems are and why they are important. Lest I continue to rant on the state of software engineering education, let's jump right into it.
I struggled a bit with what to put up front. What won out was the idea that we're seeking repeatable results. We want a process in place that when handed the raw materials that make up our application (source code, database scripts, configuration files, stylesheets, web page templates, images, etc.), an identical package is produced every time, regardless of who starts the process or what machine they use. Interestingly enough, this is precisely one of the reasons that we write software. Given some set of user inputs, the applications that we write produce a repeatable outcome for our customers. One common motivator for automating business processes with software is to reduce error rates. It certainly seems like the business understands that humans make errors. Why would we as developers think we're any better? (see You're a Bad Programmer. Embrace It.)
And yet every modern integrated development environment (IDE) of which I'm aware is capable of producing a deployable package, given proper configuration of course. I can only assume that this functionality stays around because we're using it! The problem with that is that my IDE is most certainly configured a bit differently from yours. And it's quite possible that I perform the sequence of build steps a bit differently from you. And it's also possible that I have different versions of 3rd party libraries and frameworks than you. What's that you say? A checklist? Great! Just make sure that as your process changes that the checklist always gets updated and that everyone always has the same version, etc., etc., etc.
The bottom line is that you need to treat your build process like a first-class citizen in your software. The best way to ensure that your build process is consistent and repeatable is to have everyone on your team use the same automated script to build the software in any and every situation. If it ever gets out of synch, someone will raise a flag almost immediately. However, if you're all doing it your own way, you may not discover problems until release day.
Conserve Your Concentration
Don't forget the point that I raised in my last article. According to Neal Ford, "...performing simple, repetitive tasks by hand makes you dumber, and it steals part of your concentration, which is your most productive asset." What's more mundane and repetitive than slapping together a deployment artifact through brute force? Let machines do what machines are good at, and you focus on solving problems that require intellect. The more you automate, the more you'll be able to focus, and the more bandwidth you'll have to work through the increasingly hard problems confronting us as software craftsmen.
Lower Your Bus Number
So you've gotten clever and made someone the build master, eh? Everyone else gets to focus on real work while this guy periodically slaves away in the corner putting together the next deployment. Good idea? Sure, as long as he never gets hit by a bus the day of a release (and as long as you're not that guy!). How do you release software when the only person that can build it has gone AWOL? No, automate your build so that anyone can perform that all important step on any machine at any time.
Enable Continuous Integration
Continuous integration is one of the most important feedback loops in agile software development. It is the practice of having a server tool continuously monitor your team's source code repository for changes. When a change is detected, it checks out the latest copy of the code, builds the software, executes any available automated tests, and then generates a report of the results. The very best teams have this report sent to each member via email, IM, etc. Unfortunately, your continuous integration server doesn't have a "mini me" hiding behind a curtain pulling levers and pushing buttons. It's just a computer, and therefore it needs code to execute. You simply have to automate your build to get the benefits of continuous integration.
Consider the task of orienting a new team member to your project. On the one-hand, you have a mess of source directories and 3rd-party dependencies with a complicated IDE-based build and a 30-item checklist to get from where you are to running software in roughly one hour. On the other-hand, you have a project that follows the nearly ubiquitous Maven project structure and an automated build script that gets you from where you are to running software in roughly 3 minutes. Which new team member is going to have an easier time ramping up on the project? Starting to get the picture?
The benefits of automating your build are many - I've only touched on a few of them here. My main focus has been on decreasing the costs and lowering the risks of the build process. A consistent, repeatable build that anybody (including a server and the new guy) can perform at any time on any machine without personally performing any of its steps is certainly cheaper and less risky.
I hope that I've been able to convince you of build automation merits; or, if you're already convinced, that I can help you articulate the benefits to someone that isn't. Now, go forth and script your build!
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)