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?)

You'll find easy-to-implement recipes to automate your Java project, using the same popular style as the rest of our Jolt Productivity Award-winning Starter Kit books. Armed with plenty of examples and concrete, pragmatic advice, you'll find it's easy to get started and reap the benefits of modern software development. You can begin to enjoy pragmatic, automatic, unattended software production that's reliable and accurate every time.

---

Product Details

• Amazon Sales Rank: #182090 in Books
• Published on: 2004-07-01
• Original language: English
• Number of items: 1
• Binding: Paperback
• 176 pages

From the Publisher
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. Enlist your computer to automate all of your Java project's repetitive tasks from individual builds and testing through to product release and deployment. Enjoy pragmatic, automatic, unattended software production that's reliable and accurate every time.

About the Author
Mike Clark is an author, speaker, consultant, and most importantly, he's a programmer. He is co-author of Bitter EJB (Manning), editor of the JUnit FAQ, and frequent speaker at software development conferences. Mike has been crafting software professionally since 1992 in the fields of aerospace, telecommunications, financial services, and the Internet. In addition to helping develop commercial software tools, Mike is the creator of several popular open-source tools including JUnitPerf and JDepend.

Excerpted from Pragmatic Project Automation: How to Build, Deploy and Monitor Java Apps by Mike Clark. Copyright © 2004. Reprinted by permission. All rights reserved.
Chapter 1 Introduction

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.

---

Customer Reviews

Gives good ideas to accelerate development
The book introduces many tools which might be useful during automation the build, installation, and monitoring of a large-size java application. (Ant, JUnit, Groovy, CruiseControl, NSIS, Java Web Start, XFD build monitor, Unix scripting, Ruby, log4j, Jetty)

The description of these tools is not deep at all, the book places more emphasis on covering the whole process from the first build to the customer support, taking all automation options used by professional software developer companies.

The text is easy to understand. The only reason why I gave four stars is the poor book binding: pages start falling very soon.

Good philosophy and overview, pity it's so Java-oriented
The philosophy of this book is one that I agree with completely. That is, if you want a reproducible, traceable and maintainable system for building and releasing your software, then automate the processes involved. The larger the project, the more time and money you will save.

So, in terms of philosophy, I'm a big fan of this book. I particularly like the extreme feedback devices for making the status of builds very visible. That visibility tends to encourage people to follow good practices and write working software, probably more than anything else. I also like the explanations of starting with a process started interactively, to a scheduled process, to a continuous/triggered process. Similarly, the discussion of release builds being separate from development builds is good.

However, this book does have limitations. The (easily missed) sub-title "How to Build, Deploy and Monitor Java Applications" warns the reader of the main one. This book really is aimed at people working with Java and tools that are primarily aimed at Java developers. Whilst tools such as Ant and Cruise Control (and their derivatives) can be used for non-Java projects, Java is their key target. Similarly, this book refers to CVS in its examples. Unfortunately, the choice of version control software can make a significant difference to how build and releases processes are implemented (in particular the use of labels vs. tag directories). Whether done in an update to this book, or whether it is done in a separate book, it would be good to include more about building for other languages (e.g. C++), more about non-UNIX operating systems (e.g. Windows), using other version control systems (Subversion, PVCS, SourceSafe etc), using tools other than Ant and Cruise Control (including scripting languages, whether batch-files on Windows, Python or other scripts) etc. The problem then would be that the book would be two or three times as long, at which point many people might decide it is too "heavy" to read. Tricky.

So, I love the philosophy. I like the overview of what people should be doing. I find the descriptions of the tools used adequate. But I would have liked to see wider coverage beyond the Java, Ant, Cruise Control etc environment discussed.

Enough information to start implementing good practices, not overwhelming
I bought this book over 3 years ago and still use it today, even though I have 100's of books on software development and software testing. Like all the pragmatic programmer books I own (I have about 6) it's clear, direct, and helpful. These books are good value for money and portable.

Books such as Java Power Tools from O'Reilly are complementary (covering a range of newer tools) and the Manning JUnit Recipes & JUnit in Action cover JUnit in great breadth and depth.