• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

CI builds when there's continuous changes

 
Ranch Hand
Posts: 883
3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm interested in getting a CI process going for my team and I'm a bit concerned about how it will work.

Our current build process takes about fifteen minutes for a clean build (just to comlpile the code and create the jar/war/ear files) and I'm wondering what happens if during that time someone checks in more changes. Does CC or Hudson restart the process or does complete the current build/deploy/test and then start over?

I know the build itself can be sped up, but the question still remains.

Thanks,
Burk
 
author
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Our current build process takes about fifteen minutes for a clean build (just to comlpile the code and create the jar/war/ear files) and I'm wondering what happens if during that time someone checks in more changes. Does CC or Hudson restart the process or does complete the current build/deploy/test and then start over?



The CI server will wait until the current build is complete before running the next build. It will not restart the process as new changes are added.
 
Burk Hufnagel
Ranch Hand
Posts: 883
3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the quick response. I didn't expect an answer until this afternoon.

While it's good to know that the process comtinues, I'm wondering if it's also possible to manually override the process and force a new build to start?
 
Paul Duvall
author
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

While it's good to know that the process comtinues, I'm wondering if it's also possible to manually override the process and force a new build to start?



Is this because there's no value in an integration build if other changes have been made since the build started? I don't know how large your code base is, but you may need to upgrade your integration build machine resources (RAM, processor, disk speed). Also, make sure that you are only pulling down source-related assets. 15 minutes is a while for just compilation and packaging.

But, to go back to your question, one approach could be to setup a different CI server instance, on a different port, that only performs an on-demand build that you could run that if there are changes since the last build. Although, I'd spend time on getting the compile to be faster and/or separate your project into smaller projects that are built separately.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with Paul: fifteen minutes is a long time. You should do anything you can to get your build time at least below ten minutes - the shorter the better.
 
Burk Hufnagel
Ranch Hand
Posts: 883
3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The bad news is it's all build - no time spent pulling down files.

There's some code generation, but the vast majority is spent compiling files and packaging them into jar, war, and ear files.

While the code base is rather large, the primary culprit is that the same files are compiled and jared numerous times. The people who initially wrote the build.xml file didn't take the time to determine dependencies and now we're suffering the long build.

Let this be a lesson to others. Taking short cuts on creating your build may save you some time initially, but everyone on the team pays for it several times a day.

Keep your builds fast and lean - it's worth it!
 
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 Burk Hufnagel:
The bad news is it's all build - no time spent pulling down files.

There's some code generation, but the vast majority is spent compiling files and packaging them into jar, war, and ear files.



How much time is spend for the packaging?

One important thing to know is that using update="true" with an Ant jar- or similar task is *horribly* slow.


While the code base is rather large, the primary culprit is that the same files are compiled and jared numerous times. The people who initially wrote the build.xml file didn't take the time to determine dependencies and now we're suffering the long build.



Then it's time to refactor the build script. In my experience, it's often easier than it initially looks.

Let this be a lesson to others. Taking short cuts on creating your build may save you some time initially, but everyone on the team pays for it several times a day.

Keep your builds fast and lean - it's worth it!



I totally agree. A build script needs as much care as other code.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic