This post originated from an RSS feed registered with Agile Buzz by Jared Richardson. Original Post: Continuous Integration... Why Bother? Feed Title: Jared's Weblog Feed URL: http://www.jaredrichardson.net/blog/index.rss Feed Description: Jared's weblog. The web site was created after the launch of the book "Ship It!" and discusses issues from Continuous Integration to web hosting providers. Latest Agile Buzz Posts Latest Agile Buzz Posts by Jared Richardson Latest Posts From Jared's Weblog

As Ship It! is starting to trickle out into the world, we are beginning to get feedback from readers around the world. As we hear from you about the topics in the book we'll try to post some of the more interesting replies to shine more light on some (hopefully) interesting topics.

M. Fridental asked some questions about our justification for using a Continuous Integration system.

One of the reasons we use a CI system to catch compile problems quickly. M. pointed out that the nightly or weekly builds would catch the same errors, and he's correct.

(The problems) all will be detected during the next release (say, in two weeks), but CI can detect it quicker (say, in two hours). One must decide for himself if the advantage of quick bug reports covers extra costs of creating and supporting separate build environment.

True, but if you've got a lot of code changes during those two weeks you can waste a lot of time running down the problems. The CI system isolates each code change so that you don't have that pain. Most people I've worked with think it's just a part of development, but after a few months of running with a CI system, they can't imagine working without one. I guess that's where I'm at today. I truly can't imagine trying to work without a CI system in the background.

Problems can also be found and fixed by the developer who changed the code. Most CI systems will send mail to all the developers who've changed the code since the last good build.

Haven't we all tried to fix someone else's code at one time or another? It's not that you can't fix it. It's that the developer who wrote the code can usually fix it faster than you can. It saves time.

Last point: in a weekly build, who runs down the errors? Is it the new guy in the shop doesn't know the code well enough to fix the problems? You might dump it on the new guy so he can learn, but what you're really doing is giving him the job you don't want to do yourself.

However, M. Fridental liked what we had to say about using the CI system to run the project's tests.

this testing argument is probably the strongest one for using CI. I must remind my colleagues every week to run test cases more often. With CI I can determine myself how often test cases will run.

If the CI system is running your tests every time the code changes, then functional breaks can be fixed very quickly. If you wait for the end of the week to run a test suite, how do you figure out which change broke the test? You waste more time code diving! Use a CI system and have the changes to your code isolated.