This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes Ant, Maven and Other Build Tools and the fly likes Cruise Control Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Engineering » Ant, Maven and Other Build Tools
Bookmark "Cruise Control" Watch "Cruise Control" New topic
Author

Cruise Control

Sonny Pondrom
Ranch Hand

Joined: Jun 05, 2001
Posts: 128
I read about this in an artical called Continuous Integration. And it sounds like a must have for a project with many programmers. But is it worth the setup time for just two programers?
Mike Clark
author
Ranch Hand

Joined: Aug 15, 2003
Posts: 83
Originally posted by Sonny Pondrom:
I read about this in an artical called Continuous Integration. And it sounds like a must have for a project with many programmers. But is it worth the setup time for just two programers?


(I'll assume you're using version control.)

Have you ever had a situation where you thought you checked in a file to version control, but when the other programmer tried to build the system it failed because the contents of the version control repository weren't what you expected? Or has the other programmer checked in code that didn't compile or pass all the tests? How long did it take to debug those situations?

I've found that the relatively minimal cost of setting up CruiseControl is usually far less than the time teams of more than one person spend debugging these types of integration problems. If you're not experiencing those problems, then I wouldn't recommend changing anything.

Mike
[ September 21, 2004: Message edited by: Mike Clark ]

Mike Clark<br />Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0974514039/ref=jranch-20" target="_blank" rel="nofollow">Pragmatic Project Automation</a>
Daniel Mayer
Ranch Hand

Joined: Sep 09, 2004
Posts: 103
Originally posted by Mike Clark:
Have you ever had a situation where you thought you checked in a file to version control, but when the other programmer tried to build the system it failed because the contents of the version control repository weren't what you expected? Or has the other programmer checked in code that didn't compile or pass all the tests?


Or worse, it worked fine in all the developers IDEs, but once you tried to produce a production release, the build scripts failed - and the last known working version is from weeks or even months ago...

When I started work in my current team three years ago, building a distribution could take up to three days because of integration problems (with a team of four developers). Today we are typically able to just use the CC build from last night.
Mike Clark
author
Ranch Hand

Joined: Aug 15, 2003
Posts: 83
Great point, Daniel!

Having a nightly build that passes all of its tests means you could cut a release every morning. Having continuous builds throughout the day increases the probability that the nightly build will be successful.

Mike
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Mike Clark:
Having a nightly build that passes all of its tests means you could cut a release every morning.


Yes. Actually we are already deploying a webstart distribution to the intranet at the end of our nightly build. Our administrator recently joked that we now only need to automate burning a CD every night...

[quoe]Having continuous builds throughout the day increases the probability that the nightly build will be successful.


For that it's vital that the continuous builds are really fast, though. In my experience everything above ten minutes (from checkin to having the email in the inbox) is unlikely to work well. The 60 minutes we are currently experiencing are deadly, at least...


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Mike Clark
author
Ranch Hand

Joined: Aug 15, 2003
Posts: 83
Originally posted by Ilja Preuss:
For that it's vital that the continuous builds are really fast, though.


I agree, which is why I use a tiered build approach if the build cycle is too long. During the day I'll have one schedule that compiles the code and runs the unit tests. That schedule might run every 15 minutes or so, depending on how long it takes to compile/test. I'll also have a schedule that runs every hour or two that compiles the code, generates other artifacts like war files, and runs all of the tests for the system. Then the nightly schedule builds the whole ball o' wax from scratch.

In other words, on big projects I'd use multiple CruiseControl schedules to get timely feedback throughout the day to set up for a successful nightly build.

Mike
[ September 22, 2004: Message edited by: Mike Clark ]
David Hibbs
Ranch Hand

Joined: Dec 19, 2002
Posts: 374
Originally posted by Ilja Preuss:

For that it's vital that the continuous builds are really fast, though. In my experience everything above ten minutes (from checkin to having the email in the inbox) is unlikely to work well. The 60 minutes we are currently experiencing are deadly, at least...


Yeah; Long running builds aren't much help in the terms of problem solving if they run up until the next scheduled build time!

What I found is that you don't want to run all the targets all the time. i.e. for the hourly builds, skip some/all of the reports (checkstyle, ncss, javadoc, etc) -- esp if you have plugins that report it in your workspace. (Can you tell I use eclipse a lot? )

If you think it safe, skip unit tests. Or else pick specific heavy-hitters to skip, or specific heavy-hitters to run -- then build a test suite and just run that suite.

All of these can be used to reduce that cycle time to the point you have a chance to fix problems before the next build starts and cleans out your previous results.


"Write beautiful code; then profile that beautiful code and make little bits of it uglier but faster." --The JavaPerformanceTuning.com team, Newsletter 039.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by David Hibbs:
Yeah; Long running builds aren't much help in the terms of problem solving if they run up until the next scheduled build time!


I think the bigger problems are that when you only get feedback after half an hour or more,

- you probably are already working on a new task, making having to fix the build more disturbing and costly because of the context switch, and
- you are unlikely to wait for the feedback before you go home.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Cruise Control