jump to navigation

Building applications November 1, 2007

Posted by Phill in General J2EE, Other Stuff.
Tags: , , , ,

I came across this email exchange today, courtesy of today’s post at Jeff Atwood’s blog.

Unfortunately the scenario was all-too-familiar for me: in my first job as a developer, I was working for a small company. This meant that we were very busy, and little things like documentation were often missed (of course, this is something which bigger companies have been guilty of as well…) My development workstation became “The development machine”. This meant that when we needed to deploy an application, someone would come to me and say “Phill, we need a new EAR file for application x” (it wasn’t actually called ‘application x’, but actually that would have been kind of cool). I would then go into my IDE, open up the project, and run the build process.

The problem came when I needed to get someone else up to speed on the project… trying to get someone else’s IDE to be exactly the same as yours is a total nightmare. The dependencies were all over the place, it took hours to get it all up and running.

However, we did learn from that: we created a ‘build server’ which used a continuous integration tool, Cruise Control, and Apache Maven. What this did was create a new ‘build’ of each of our projects when we checked them in. If you have never experienced this, I highly recommend it. You get almost instantly notified if what you have checked in causes a build failure. It gives you confidence that the build you have created works (you can set it up to run unit tests automatically), and – in our case – it gave us a central place for people to go to for builds. Which was good for me, because I didn’t like getting interrupted for people to ask me for a new build!

Continuous integration is certainly an invaluable asset to a project, and I would suggest that all projects should have at the very least a repeatable build system in place (such as Apache Ant) which would work on any PC, i.e. not dependent on any special set-up on one machine). Of course, in the real world things don’t always work out that nicely – machines do need to be set up with custom software, properties etc. In this case, there are two options I would recommend:

  • Use virtualisation software such as VMWare to create a virtual development environment which everyone can share. Keep this up to date with all the custom software etc which is needed to build your project.
  • Make a document which details all the steps needed to set up your environment. Keep this up to date every time something changes.

In fact, it’s not really an either / or – even if you do set up a virtual environment, it’s definitely worth keeping a document detailing what exactly went into it, just in case things go wrong.

In conclusion, there are a few things that can be done to make building applications less error-prone: 1. Use a repeatable build process; 2. Use a continuous integration tool; 3. make sure the steps to reproduce your development environment are clear! Good old fashioned documentation in this instance cannot be avoided, but at least using appropriate tools it can be reduced.



1. Code Coverage with Cobertura and JUnit « Phill’s J2EE Blog - June 3, 2008

[…] you use Ant or Maven (if you’re still using your IDE to build your projects, you really should switch!) it’s fairly easy to integrate Cobertura into your […]

Sorry comments are closed for this entry

%d bloggers like this: