This week's book giveaway is in the Android forum.
We're giving away four copies of Head First Android and have David & Dawn Griffiths on-line!
See this thread for details.
Win a copy of Head First Android this week in the Android forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Rob Spoor
  • Devaka Cooray
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • Tim Holloway
Bartenders:
  • Jj Roberts
  • Al Hobbs
  • Piet Souris

Cruise Control

 
Ranch Hand
Posts: 128
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
author
Posts: 83
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 ]
 
Ranch Hand
Posts: 103
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 83
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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...
 
Mike Clark
author
Posts: 83
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 ]
 
Ranch Hand
Posts: 374
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic