Continuous Integration is a good thing.
Hmmm, it works on my machine.
– Developer
I paired up with a developer yesterday to hook a new project into the build box and Cruisecontrol. We expected a few wrinkles since this is the first project we’re hooking up to maven instead of ant. Should be just a simple <maven2> tag and a few parameters.
We got past the parameter settings faster than expected, maybe 5 minutes on syntax errors like using
1 | mavenhome |
instead of
1 | mvnhome |
and forgetting to checkout the project manually for the first run. So after five minutes it’s up and running, but it starts failing soon after getting started.
So next we try debugging by just running the maven goals in the checked out codebase. Over and over again it pulls down about 10 dependent jars and then bails on the 11th. It’s not the same jar each time so the error isn’t obvious. Current theory is maybe the build box is being throttled by the proxy server, but it was late so we’ll get back to it in the morning. The build of course works on the developers machines.
Without hooking up the continuos integration early in the project we would have missed what may be a fairly subtle bug.
Hi Ed,
Good post. At my last position this was the sole reason we initially hooked up CruiseControl.NET – because I was tired of hearing, “but it works on my machine!”
The most common problems for us were absolute dependency locations instead of relative. One developer had his machine’s hard drive partitoned into 15 (!) seperate drives. The second most common was just forgetting to check in files.
But what an improvement it made in the build! I do hope you follow up with what was causing it not to work.
Turns out the issue was a local dependency. There were some jars that aren’t in the maven repository and had to be manually added to a repository on the local machine. As we get more sophisticated with maven I assume we’ll put these on a server somewhere, but the developer was installing them by hand for now.