aspose file tools*
The moose likes Agile and Other Processes and the fly likes CI builds when there's continuous changes Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "CI builds when there Watch "CI builds when there New topic
Author

CI builds when there's continuous changes

Burk Hufnagel
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
    
    3
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


SCJP, SCJD, SCEA 5 "Any sufficiently analyzed magic is indistinguishable from science!" Agatha Heterodyne (Girl Genius)
Paul Duvall
author
Greenhorn

Joined: Jul 17, 2007
Posts: 29

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.


Co-author of <a href="http://www.amazon.com/gp/product/0321336380/" target="_blank" rel="nofollow">Continuous Integration: Improving Software Quality and Reducing Risk </a> <br />(Addison-Wesley Martin Fowler Signature Series, 2007). Companion website for the book is <a href="http://www.integratebutton.com/" target="_blank" rel="nofollow">IntegrateButton.com</a>
Burk Hufnagel
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
    
    3
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
Greenhorn

Joined: Jul 17, 2007
Posts: 29
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.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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.


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
Burk Hufnagel
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
    
    3
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
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: CI builds when there's continuous changes