Integrate Button Weblog

Archive for July, 2007

Practice 5: Write Automated Developer Tests

Wednesday, July 25th, 2007

Practice 5 of the book (which is the fourth practice in chapter 2) is Write Automated Developer Tests. It’s a high-level practice that covers:

  • Writing an automated test using an xUnit-based framework such as JUnit or NUnit
  • Committing these tests to a version control repository
  • Running these automated tests as part of an integration build with every checkin (using Continuous Integration)

This video example demonstrates using the JUnit test framework with Eclipse.

Useless facts about Continuous Integration book

Monday, July 23rd, 2007

Book Signing at Barnes and Noble in Reston, Virginia

Friday, July 20th, 2007

For those of you in the Washington DC area, my co-author Andy Glover and I will be doing a book signing for Continuous Integration on Thursday, August 30th, 2007 at the Reston Barnes and Noble bookstore. Here are the details:

Barnes & Noble
Thursday, August 30th @ 7:30pm
1851 Fountain Dr
Reston, VA 20190
703-437-9490

See you there.

Supply update: Last week, some retailers had sold out of the book, but last I checked, it is in stock in most stores and online book retailers in North America now. It may be a few weeks before those of you in Australia, Europe and Asia start receiving copies.

Start the presses: Continuous Integration orders

Friday, July 13th, 2007

I am learning more and more about the publishing business every day. I know that some (many?) of you have ordered the Continuous Integration book and it’s yet to arrive. I’m sorry to hear that and I wish I had control over it, but I don’t. Some retailers (you know who you are :-)) didn’t order enough copies of the book and there was a larger than expected demand for Continuous Integration. I’m sure you can figure out the rest. In fact, I ordered the book online from a well-known online retailer, just to see what readers would see and I’m not supposed to receive my copy until next week. One of these retailers is indicating a 4-6 week delay and I’m informed it probably won’t be that long a wait. My publisher has informed me they still have copies in stock that can be ordered at http://www.awprofessional.com/title/0321336380. Thanks for your patience.

Asserting architectural soundness article and podcast

Thursday, July 12th, 2007

IBM developerWorks recently interviewed me for my latest Automation for the people article called Asserting architectural soundness. Scott Laningham has a very efficient operation as the whole podcast interview process took no more than 10-15 minutes to complete. Asserting architectural soundness describes a technique to build checks into your build scripts so that you discover architectural violations as soon as they are introduced into the code. For instance, let’s say your presentation layer is making a direct call to your data layer and this is a violation to your architectural layering rules. By using the JDepend API, JUnit and Ant, I show how you can find out about this type of error as soon as you build your software. What’s more, if you’re using Continuous Integration, you’ll learn about the violation for any developer that commits code to the repository and in a consistent manner - several times a day.

Managing JBoss with Cargo

Wednesday, July 11th, 2007

If you find yourself in need of a generic management tool that facilitates installing, starting, and stopping a container, plus the ability to deploy artifacts like war and ear files, then you may want to take a look at Cargo.

Briefly, Cargo is an innovative open source project that aims to automate container management in a generic fashion, such that the same API used to deploy a war file to JBoss can also start and stop Jetty. Cargo also can download and install a container automatically; and you can utilize Cargo’s API in a few different fashions, ranging from Java code to Ant tasks to Maven goals.

For example, if you’d like to create a repeatable deployment process that avoids environmental assumptions (like that the instance of the application server is properly configured, etc), you can use Cargo to automatically download and install a pre-defined kosher version, say of JBoss. Once JBoss has been installed and is started, you can then deploy artifacts and begin testing.

Using Ant to accomplish this process is actually quite simple. All you need are two jar files (at a minimum). If you are using the latest version of Cargo (at the time of this posting) then the two files are: cargo-core-uberjar-0.9.jar and cargo-ant-0.9.jar.

With these two files in your classpath, you can then create an Ant target that initializes Cargo’s task like so:

<taskdef resource="cargo.tasks">
 <classpath>
  <pathelement location="${libdir}/${cargo-jar}" />
  <pathelement location="${libdir}/${cargo-ant-jar}" />
 </classpath>
</taskdef>

Then you can download and install a container, plus start it as follows:

<cargo containerId="jboss4x" action="start" wait="false" id="${jboss.refid}">
 <zipurlinstaller installurl="${jboss.installer.url}" />
 <configuration type="standalone" home="${jboss.tmp.dir}">
 </configuration>
</cargo>

Note, you can deploy ear and war files between the two configuration tags. Also note, if JBoss is already installed, Cargo won’t attempt to reinstall.

Lastly, if you’d like to stop JBoss, then you can issue the following command:

<cargo containerId="jboss4x" action="stop" refid="${jboss.refid}" />

A refid is required to find a process as these steps are logically broken up. Also note that Cargo requires two different directories to properly install and configure JBoss– you can not use the same directory.

Cargo makes automated and reliable deployments a non event because this framework manages the container environment so you don’t have to. Give it a try and you’ll see a drastic increase in your ability to choreograph deployments quickly.

For more information on using Cargo for repeatable testing check out

You might need Continuous Integration if…

Thursday, July 5th, 2007

It looks as if this may have been posted a while ago, but very useful nonetheless. It’s called 34 signs that continuous integration isn’t working. I understand why it was entitled this, but I think the title is a bit misleading. I think a better title may be: “34 symptoms that you might need (effective) Continuous Integration”. The article is almost like a list of smells that indicate you may need a better way to integrate your changes. I’ve identified some of the practices we describe in the Continuous Integration book to combat these “smells”.

Here are some great ones:

  1. Everyone has a different set of projects checked out on their PC (Perform Single Command Builds, Centralize Software Assets)
  2. You don’t have a master build script that builds everything on any (workstation) (Automate Builds, Centralize Software Assets)
  3. You sometimes check in without catching up with other people’s changes (Run Private Builds)
  4. You hate/fear checking code in (Commit Code Frequently)
  5. It’s difficult to take a (’cut’) of the code that’s consistent enough to make a release… (Perform Single Command Builds, Centralize Software Assets)
  6. It takes forever to make a release
  7. Things that were working fine suddenly stop working (Perform Single Command Builds)
  8. If you want to know what code is running live, you checksum or diff it against known versions (Build for Any Environment)
  9. The code works in development and pre-production, but not in production or test (Build for Any Environment)
  10. You are only allowed to release in the middle of the night/weekend/both (Release Working Software Any Time, Any Place)
  11. Releasing a one-line fix for a show-stopping production bug is “too risky” (Label Each Build, Label a Repository’s Assets)
  12. You often check in only some of the changed files in your workspace