wood burning stoves 2.0*
The moose likes Agile and Other Processes and the fly likes Next steps in making CI more effective? 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 "Next steps in making CI more effective?" Watch "Next steps in making CI more effective?" New topic
Author

Next steps in making CI more effective?

Ryan Kade
Ranch Hand

Joined: Aug 16, 2005
Posts: 69
Welcome Paul and Andy, thanks for your time.

We just started using CruiseControl about two months ago. We had an automated build script already in place (via Ant) but had no CI process at all ... you only found out if the build was broken after you updated from version control and tried. Now we find out immediately, and it works great.

But I'm told that discovering broken commits is just the tip of the iceberg in benefits one can draw from CI. The next step I'd like to go to is getting some more Unit Tests written for our code--sadly, a Herculean task all by itself--so that they can be run by CruiseControl during each build as well. Someday I'd even like to migrate our culture to TDD.

What other starter steps do you recommend we take to maximize the CI benefit?

Thanks!
Ryan
[ August 28, 2007: Message edited by: Ryan Kade ]
Paul Duvall
author
Greenhorn

Joined: Jul 17, 2007
Posts: 29
But I'm told that discovering broken commits is just the tip of the iceberg in benefits one can draw from CI. The next step I'd like to go to is getting some more Unit Tests written for our code--sadly, a Herculean task all by itself--so that they can be run by CruiseControl during each build as well. Someday I'd even like to migrate our culture to TDD.

What other starter steps do you recommend we take to maximize the CI benefit?



Ryan - Yep, I'd agree that "continuous compilation" is the tip of the iceberg as far as the benefits from CI. There's another way to look at your lack of automated tests. Just start adding new tests for any new or modified code that is updated to the repository. There's no need to go back and write tests for code unless you need to modify (refactor or otherwise) it. This may help you see that you don't have to do it all at once to get the benefits.

There are many processes I'd recommend that are described in the book, but the first I'd suggest you look into is packaging and deploying the software into the target environment. For instance, if you deploy to a web container, have the build script generate the .war/.ear copy it to target location (local or remote), configure datasources and so on.

If you want to get something running very quickly, then look into running automated "inspections" - static/dynamic analysis) such as using CheckStyle/PMD for coding standard checks and other similar tools so that you can learn about source code violations as they are introduced to the code base. This is described in chapter 7, Continuous Inspection, in the book or you can learn some of this in an article I wrote last year for IBM developerWorks: http://www-128.ibm.com/developerworks/java/library/j-ap08016/

Paul


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>
Ryan Kade
Ranch Hand

Joined: Aug 16, 2005
Posts: 69
Thanks for the prompt reply!

Yes I agree, there's no easy way to retrofit existing code for unit testing. Some of our business objects would require complete refactoring and I think the potential to introduce risk is greater than the risk posed by leaving it un-unit tested.

The standards checking suggestion is great. I've seen CheckStyle used in some other open source projects I've downloaded, so I'll check that.

I neglected to mention, we do also have an automated deploy to a testing environment working, thanks for that suggestion as well.

I appreciate your input!
Ryan
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Ryan Kade:
Yes I agree, there's no easy way to retrofit existing code for unit testing. Some of our business objects would require complete refactoring and I think the potential to introduce risk is greater than the risk posed by leaving it un-unit tested.


You most probably *don't* need to completely refactor your code to write unit tests for it. In fact I'd bet that you could write your first test today, without taking much risk.

Some of our team are currently reading "Working Effectively With Legacy Code", and it has been a great help with doing exactly that (we, too, have a lot of untested legacy code to deal with).


The standards checking suggestion is great. I've seen CheckStyle used in some other open source projects I've downloaded, so I'll check that.


I'd advise to make sure that you don't measure something just because it's easy to measure. Think hard about how you will use the information you will get. Having the process produce information that isn't acted upon has a high risk of reducing the perceived significance of the whole process.


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
Paul Duvall
author
Greenhorn

Joined: Jul 17, 2007
Posts: 29
I'd advise to make sure that you don't measure something just because it's easy to measure. Think hard about how you will use the information you will get. Having the process produce information that isn't acted upon has a high risk of reducing the perceived significance of the whole process.


I agree with this and an approach I've used and discuss in the book is to start by checking nothing and then add the built-in checks from the ground up (one-by-one) as necessary for the project. This is especially beneficial because running something like a CheckStyle with all its built-in rule checks can quickly overwhelm a team to the point where they never look at or, more importantly, *implement changes* based on the reports.
[ August 30, 2007: Message edited by: Paul Duvall ]
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Next steps in making CI more effective?
 
Similar Threads
Which challenges do you experience the most with CI?
Continuous Integration
CI with ClearCase
[book] Nothing on Continuous Integration ?
Huge projects with subprojects - which tools are most effective?