One of the things I spend a lot of my life doing is looking after Continuous Integration environments. As I work for ThoughtWorks, and am one of the guys who created Buildix, it should come as no surprise that this is all done with CruiseControl. However, in the past few months there a few new Continuous Integration tools that have crept out onto the scene. The two that I hear the most about are TeamCity and Bamboo. I finally managed to get a few hours to test them out, and here’s my impressions.
One of the things I wanted to see was how quick and easy it was to get these tools up and running. With this in mind, I specifically decided in advance to pull down the .war bundle of each one and try that out. In my experience, this would be the one that most of the clients I’ve been at would have gone for.
- This is very much a first impressions run of the products – I had a limited time window (2 hours total) to do this in.
- People could quite fairly say that I have a biased view, but I’ve tried to keep this as fair as possible.
- I only tested doing an Ant build of a simple sample webapp from a subversion repository.
- You have to buy a license for TeamCity and Bamboo (I got evaluation licenses for both), but CruiseControl is still free…
- Fedora Core 4
- Via C3 800 server with 512Mb RAM
- Sun Java 1.6.0-b105
- Apache Ant 1.7.0
- Jetty 6.1.1
- Subversion 1.2.3
Part of what we’re doing at my current client is writing an HTTP interface to allow read only access to a Tangosol cache. For the first month or so we’ve been using Jetty (6.0.2) for testing and development, because it’s free and easy. Everything has been going well, and we finally got the official ruling that our webapp will run in production under JBoss (4.0.3SP1). We did expect this, as current webapps they have in production run under JBoss, but we were not sure of which version we were going to end up on so we stuck with Jetty. We’ve been very carefull to keep our app as vanilla as possible, but when we deploy our happy app under JBoss, we start getting showered with NullPointerExceptions like these:
After a bit of poking around I found that the only nulls that existed in that area of our code was when we were calling startElement() and endElement() with nulls. A quick look at the JavaDocs for these methods says that you should pass “the empty string” if there is no Namespace URI or Namespace. Simply replacing calls like:
transformerHandler.startElement(null, null, ERROR_TAG_NAME, errorAttributes)
transformerHandler.startElement(“”, “”, ERROR_TAG_NAME, errorAttributes)
sorted out the problem!
We’re only due to go live with this app in July, but one of the patterns that has saved me many times is to test early and often. The trick is not to limit your testing, but push it as far as you can go. In this case, testing in a production like environment 5 months before we’re due to go live has meant we only needed to change a few lines of code in two classes. Imagine how much more we would have to change in 5 months time…