«  
  »

Manual Continuous Integration

A few weeks ago I gave my opinions on James Shore’s idea of manual continuous integration.

Today the continuous build for one of our projects has three steps:

  1. Check in code to CVS repository.
  2. Log into the build box and manually run a
    1
    cvs update

    .

  3. Wait for cruisecontrol to run a build and send out email notifications.

Our other projects have a two step build:

  1. Check in code to CVS repository.
  2. Wait for cruisecontrol to run a build and send out email notifications.

The reason for the three step process is simple pragmatism. After you spend 40+ hours between yourself and a developer trying to get it to run you should look for something that works. The problems we ran into were numerous:

  • Turned out figuring out how to run maven2 from cruisecontrol was a bit annoying. We ended up having to use the mvnscript command instead of mvnhome. The note in cruisecontrol’s documentation was a hint at the problems we’d see:

    • Due to the current status of Maven (in heavy development) only the “script” start mode is supported.

  • Then for some reason we still haven’t been able to figure out the
    1
    scm

    plugin in maven just didn’t work for updating from CVS from cruisecontrol. It would just bomb on the pserver password over and over despite the fact that the user it was launched under already had a valid

    1
    cvs login

    performed.

  • Next we tried just adding an extra ant target to do the CVS checkout. That didn’t work because cruisecontrol would checkout the project from the first ant command, and then return success and complete. It turns out you can’t run an ant and maven task within the same project.
  • Then I tried setting up two project, one to just do the checkout, but I couldn’t get the dependencies to work in cruisecontrol.
  • Then I tried luntbuild which was a bit of pain to setup, but finally looked like it was going to work. Only as soon as it starts to run maven2 it fails and exits with an unsuccessful build.
  • Then I tried to look for an ant task to run maven from ant. Turns out you can run ant from maven, but the tasks are only for utilizing Maven’s artifact handling features.

The worst part is that in the past 30 day Sprint we’ve missed important build failures including several checked in unit tests that were failing and lately even some missing files that were causing the compiler to fail.

So we’re back to manual continuous integration instead of investing more time in the tools.

September 2nd, 2006 | Category: automated builds, software development

7 comments to Manual Continuous Integration

  • Jason Yip
    September 2, 2006 at 4:15 pm

    There are Maven 2 users on the CruiseControl lists so you may get better advice there. If any fixes pop up, I can commit them.

    My other thought is that if you really want to use Maven, you may want to look at Continuum: http://maven.apache.org/continuum/

  • Mariano Kamp
    September 3, 2006 at 12:27 am

    Hey Ed,

    I am always wondering if it wouldn’t be a good idea to do continuous integration with the ruby tools, especially rake and maybe capistrano.

    Cheers

    ps. Great blog, read it every day.

  • Ed Gibbs
    September 5, 2006 at 7:16 pm

    The jury’s probably still out a bit on maven for our shop. We don’t have really complex build environments so generally even our ant builds files are pretty simple. When I get a chance again I’ll take a look at other options, but enough effort had been spent at this point.

    I like the ide of doing something with rake and capistrano, but I haven’t really thought about using them for a Java specific project.

    Thanks for the kudos as well.

  • Nick Z
    September 7, 2006 at 7:18 pm

    Consider Ivy instead of maven. It was recommended to me by a group we contracted in.. I’ve found it much more fruitful to use than maven.

  • Mariano Kamp
    September 8, 2006 at 1:41 am

    Well, my personal first hands experience with Maven is very limited to non-existent, but from what I heard I would gather that the idea of a common project layout is a great idea, but it is not that easy to change the way Maven acts on it and tailor it to your needs in an agile way.

    That’s what I like about Rake. It’s both declarative and programmatic. You can easily add some glue code to a task.

    I haven’t tried using Rake with Java myself yet, but I was thinking about it a lot (for building our OSGI bundles) and after reading the Fowler article on rake, I believe it is a good idea to probably use rake to generate and execute Ant scripts, so that the jvm doesn’t have to be started all that often and you don’t have to pay the price of the slow jvm startup.

  • Ed Gibbs
    September 8, 2006 at 5:35 am

    OK, when I get some downtime to look at build tools again I’ll probably take a look at Ivy and seeing if perhaps rake might do the trick.