Next steps in making CI more effective?

[Ryan Kade]

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]

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

[Ryan Kade]

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]

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.

[Paul Duvall]

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 ]