Product Description
Forget wizards, you need a slave--someone to do your repetitive, tedious and boring tasks, without complaint and without pay, so you'll have more time to design and write exciting code. Indeed, that's what computers are for. You can enlist your own computer to automate all of your project's repetitive tasks, ranging from individual builds and running unit tests through to full product release, customer deployment, and monitoring the system.
Many teams try to do these tasks by hand. That's usually a really bad idea: people just aren't as good at repetitive tasks as machines. You run the risk of doing it differently the one time it matters, on one machine but not another, or doing it just plain wrong. But the computer can do these tasks for you the same way, time after time, without bothering you. You can transform these labor-intensive, boring and potentially risky chores into automatic, background processes that just work.
In this eagerly anticipated book, you'll find a variety of popular, open-source tools to help automate your project. With this book, you will learn:
- How to make your build processes accurate, reliable, fast, and easy.
- How to build complex systems at the touch of a button.
- How to build, test, and release software automatically, with no human intervention.
- Technologies and tools available for automation: which to use and when.
- Tricks and tips from the masters (do you know how to have your cell phone tell you that your build just failed?)
From the Publisher
About the Author
Excerpted from Pragmatic Project Automation: How to Build, Deploy and Monitor Java Apps by Mike Clark. Copyright © 2004. Reprinted by permission. All rights reserved.
This is the book your computer didn’t want published. Until now, your computer has had a life of leisure: reading email, displaying web pages, and maybe even compiling Java code. Meanwhile you’ve been on the treadmill doing repetitive, mundane, and downright boring tasks that take away time from delivering valuable software and seeing your family.
Simply put, this book tells you how to put this thing called a computer to work doing some of that mundane (but important) project stuff. That means you’ll have more time and energy to do the really exciting—and challenging—stuff, such as writing quality code. In other words, we’ll task computers to do what they’re good at, leaving us to do what we do well.
But aside from the obvious efficiency gains, automation also makes our project’s procedures consistent and repeatable so that we spend less time debugging problems. How does this play out in real life? Let’s start with a story....
1.1 Look Ma, No Hands!
Today we find Fred, our favorite programmer, working on his company’s flagship product, the document management system, or DMS for short. OK, so "document management system" might be what Fred calls it on his resume. It’s really just a collection of HTML files that can be indexed and then searched. Fred chuckles as he thinks of how much venture capital (VC) money his company could have raised in 1998 just for promoting something by that name.
But it’s 2004, and a cool product name and a web site just don’t cut it. These days you actually have to demonstrate working software to loosen the VC purse strings. Speaking of which, Fred is in charge of preparing a demo for the venture capitalists tomorrow at noon. There’s just one problem: By that time tomorrow Fred will be a few state lines away from the office. In fact, his RV is out in the parking lot right now, gassed up for a trip to the yearly family reunion in Kansas. Just as soon as he adds this last feature, Fred and his family will hit the road.
It Works on My Machine
Fred can already taste the barbecue sauce as he finishes up the last bit of code. He presses the Compile button on his favorite IDE. No errors. Then he runs all his local unit tests, and they pass. So far, so good. Now for the grand finale. Fred checks out the latest version of the rest of the project from the version control system to set up for an integration test. Then he touches off a build by running the project’s build script.
WooHoo! The build succeeded. Fred is reminded once again that he’s the world’s greatest programmer. So he commits his changes, grabs his lunch pail, and races for the elevator. In the morning, all his team needs to do to deploy the demo is run the deployment script. They may even have time for a game of foosball before the venture capitalists show up at noon. Life is good as Fred, the missus, and all the rugrats crawl into the Winnebago and drive out of town.
Somewhere Out on I-70...
Fred has the pedal to the metal as the RV lumbers down I-70 in the dead of night. Just as the kids have dozed off, Fred is startled back into reality by a beep of his cell phone. It’s a text message sent from the scheduled build process on the build machine back at the office, hundreds of miles in Fred’s rearview mirror. When it woke up and tried to run a build, it failed. Fred grimaces as he reads the error message. In his haste he forgot to check in a new source file.
Fred leaves a voice mail for his faithful teammate Barney, letting him know that he’ll need to check in the file before the demo. And then Fred goes back to counting mile markers.
The Next Morning
Barney strolls into the office a tad late the next morning. The whole team had worked hard preparing for the demo all week, so last night they celebrated by downing some brews at the bowling lanes. Checking voice mail is the last thing on what’s left of Barney’s mind. He’ll return phone calls after the demo.
But he can’t help but notice the boiling red bubbles in one of the Lava Lamps that the team uses to indicate the build status. 1 Oh no! The scheduled build has failed. When they left work last night, the green lamp was bubbling. "What could have happened?" Barney wonders as he checks the build status web page. It tells him that since the last successful build, one person has checked in code...Fred! The error message says he forgot to check in a file.
Back on Solid Ground
Perhaps it’s time for Barney to check voice mail. He listens as Fred sheepishly explains that a local file on his machine needs to be checked in for the build to work. Having checked in the missing file, Barney wants some confidence that everything is in place for the demo. So he forces an independent build on the build machine. He also cranks up the frequency of scheduled builds so that Fred can’t get so far away next time before finding out the build failed.
Everything compiles, and the tests pass on the build machine. Barney then runs a script that automatically creates a release branch containing the current versions of all files in version control, builds and tests the release branch, creates a distribution file, and deploys it into the demo web server.
After running the deployment script, Barney clicks through a few pages of the demo to make sure it looks right. Then he takes an early lunch before folks show up for the demo.
