I have been practicing and preaching about Continuous Integration for the last 5 years and I plan to utilize it for years to come. I am a strong believer in small, frequent code changes, integrating those changes with others, and testing that code base ASAP. The best way to automate and manage this practice is through a CI Server. I highly recommend Jenkins to fill that role.
I used Cruise Control for 2 years, then switched to Hudson for 2 years, and followed the fork to Jenkins the day it came out. I love the modularity (plugin architecture) that Jenkins provides, their delivery cycle, and the prompt responses from the community. I strongly believe the reason it’s so popular is because the core team has made it extremely easy to contribute. They have very good documentation and getting a plugin created, built, deployed, and delivered is all done via a few maven commands. This is a whole lesson in itself on how to build a community and welcome contributors.
Every project/product we work on at Sentry is hooked into our Jenkins instance, which utilizes several slave nodes for balancing the work. We have projects written in PHP, Ruby, C++, Java, and Clojure all running under Jenkins, pulled from either SVN or Git, alerting us (IM and/or Email) whenever something breaks. We also have our Selenium tests (via Fitnesse) being executed from Jenkins as well.
Our builds consist of static analysis code checks, execution of automated unit and integration tests, generating code coverage reports and API documentation.
Building on the CI practice, I am preparing to move several of our products to a Continuous Deployment approach with the goal of Jenkins managing that as well.