Huge projects with subprojects - which tools are most effective?

[Suzanne Israel]

I work on a huge application with a primary project and a growing number of subprojects. At present, we manage the automated build process using a combination of perl and Ant (submitted nightly via a Unix cron job).

The perl scripts manage setting and verifying system and environment properties, backup of the prior build, checkout from CVS, triggers the primary Ant build tasks, starts and stops our development Weblogic 6.1 server and precompiles our JSPs.

The Ant build script itself is large and complex (it includes java and C++ compiles, javadocs, automated unit tests etc), and additionally invokes perl wrappers for other Ant build files.

As our application grows larger, the build process becomes more and more convoluted and the number of sub-builds grows.

What tools are most effective for this type of scenario? I know that we could probably improve the process a lot by using a build.properties file instead of the separate perl wrapper scripts, and handling the CVS checkout directly from within Ant, but would we benefit from using Cruise Control, Maven or some of the other automation tools?

Suzanne Israel

[Lasse Koskela]

To me it sounds like your complex build scripts aren't due to using the wrong tools but due to a complex application. Are there any specific things about your daily development routines that bugs you (pun not intended)?

Regarding the use of CruiseControl, if you'd like to incorporate more visual feedback into your scheduled builds then CruiseControl is definitely a safe choice. Otherwise, if your cron setup works smoothly, I'd probably try to convince myself to resist the urge to use a more sexy tool like CruiseControl or AntHill.

[Daniel Moore]

I'd avoid using perl scripts where possible. Ant has a lot of power, but most folks don't use it beyond the 'compile, test, war' scenario. For instance, you can check modules out from CVS. I like perl, but simplifying your build environment might make maintenance easier.

Also, definitely look at abstracting out properties that differentiate subprojects into properties files. A proper build environment is much like coding--the DRY (Don't Repeat Yourself) principle should be followed wherever possible.

If you're having problems with dependencies, a look at Savant may be worthwhile.

[Suzanne Israel]

Lasse wrote:

To me it sounds like your complex build scripts aren't due to using the wrong tools but due to a complex application. Are there any specific things about your daily development routines that bugs you (pun not intended)?

Regarding the use of CruiseControl, if you'd like to incorporate more visual feedback into your scheduled builds then CruiseControl is definitely a safe choice.

You're right - our tools are good so far as they go (and definitely a huge improvement on what we had before).

The tricky part is the feedback, especially integrating all of the sub build results into the overall results displayed to our developers on our build results web page.

The overall build log includes all the sub-build log info, but we aren't currently able to automatically integrate (for example) the sub-build junit test reports or javadocs. We're handcoding these links into the build results page as each new sub-build is added.

thanks,
Suzanne

[Mike Clark]

Perhaps the sub-builds could be broken out into separate Ant build files just as a way to make the build steps more cohesive. This certainly depends on the intent and structure of the sub-build. Ant 1.6 has some powerful features for managing complexity of this sort by way of build file inheritance and macros. Those features certainly add some complexity, but using them may reduce the overall complexity you're fighting.

Without seeing your Perl scripts, I'd venture to guess that some of the support built in to CruiseControl would be beneficial to your project. Specifically, CruiseControl will checkout from CVS, trigger Ant build targets, and publish results to a build status web page. I suspect the minimal configuration to do that in CruiseControl will be easier and more maintainable than Perl. Also, you can easily extend CruiseControl to publish custom results, say for integrating all of the sub-build results into the overall results, by using built-in publishers or a generic XSL tranformation of XML results.

In short, if the Perl scripts are becoming difficult to maintain and extend, then I'd look to CruiseControl to minimize the overall complexity.

Mike

[Suzanne Israel]

Thanks for all your replies and suggestions. I'll definitely try to find out more about Cruise Control - it sounds like it might be exactly what we need.

Suzanne

[Lasse Koskela]

Originally posted by Suzanne Israel:
Thanks for all your replies and suggestions. I'll definitely try to find out more about Cruise Control - it sounds like it might be exactly what we need.

I must plug my recent article here. If you decide to read it, I'd be grateful to get any kind of feedback on it.

[friso dejonge]

yeah, that was a good document lasse. I read it a couple of days ago. When we decided to use it, a lot of developers felt this as an intrusion, since everyone could see who was making the errors. However in the end, when it was their turn to make a build, they were happy that it already compiled and build their ear-file.