Benefits of CI for highly modularized projects

There has been some discussion in abandoning our CI system (Hudson FWIW) due to the fact that our projects are somewhat segmented. Without revealing too much, you can think of each project as similar to a web site project: it has dependencies, its own unit tests, etc.

It seems like one of the major benefits of CI is to make sure that each component of a project works together, b开发者_Python百科ut aside from project inheritance most of our projects are standalone and unit tested fairly well.

Given what I have explained here (the oddity in our project organization); can anyone explain any benefits of CI for segmented\modular\many projects?

So far as I can tell, this is the only good reason I've found:

“Bugs are also cumulative. The more bugs you have, the harder it is to remove each one. This is partly because you get bug interactions, where failures show as the result of multiple faults - making each fault harder to find. It's also psychological - people have less energy to find and get rid of bugs when there are many of them - a phenomenon that the Pragmatic Programmers call the Broken Windows syndrome.”

From here: http://martinfowler.com/articles/continuousIntegration.html#BenefitsOfContinuousIntegration

I would use Hudson for the following reasons:

• Ensuring that your projects build/compile properly.
• Building jobs dependent on the build success of other jobs.
• Ensuring that your code adheres to agreed-upon coding standards.
• Running unit tests.
• Notifying development team of any issues found.

If the number of projects steadily increases, you will find the need to be able to manage each one effectively, especially considering the above reasons for doing so.

In your situation, you can benefit from CI in (at least) these two ways:

• You can let the CI server run certain larger test suites automatically after each subversion/... check-in. Especially those which test the interaction of different modules, hence the name continuous integration. This takes away the maintenance work and waiting time from the developers when they consider a check-in. Some CI (e.g. Hudson) also can be configured to automatically build modules when a depending module is build. This way you can let it automatically test if depending modules are compatible with the new version of the changed one.

• You can let the CI server publish the new artifacts to the repository of a dependency resolver (e.g., Ivy, Maven). This way, the various modules can automatically download the latest (stable) revisions of the modules they depend on. Combine this point with the previous one and imagine the possibilities (!!!).