Of all the best practices enunciated by the Agile movement, perhaps no other makes as much sense in practice as continuous integration (CI). It is predicated on the simple theory that if you rebuild the project every time source code is checked in, developers can be informed immediately of changes that break the build. The shorter the loop between the break and notification to the developer, the more likely the developer will still remember the details of the changes, hunt down what's wrong, and get it fixed. This approach is easy to understand, straightforward to implement, and very effective. If you're not using continuous integration, you're working under a very substantial handicap.
A secondary, but important, benefit of CI is that by building the product regularly, the organization has in theory a working (if still incomplete) binary that it can use to demo the software if the need arises. (Without warning, the CIO might want to see where things stand). Moreover, the usual problem of discovering build problems one of the final stages in waterfall-like methodologies is moved up the cycle, so that the effects of changes on the builders are known all the way along. This step removes all the frantic patching and rewriting that occurs in non-CI shops when a project is first tested.
The next step in CI, called "Continuous Delivery" after the Jolt Award-winning book that came out in 2010, takes CI even further. It contends that the process automation of CI should be extended to delivering and installing the apps and running tests on the installed app. This added step gives the development organization an additional level of comfort. They can automate installation and verification with each new build, and know that the product subset they can deliver on any given day is completely ready to go should the client want to see it. The need for tighter integration between development and operations caused by the automation of continuous delivery is what forged the term "DevOps." It is supposed to mean a closer relationship between developers and operators (a historically wide and sometimes acrimonious divide), but in fact, everyone seems to have different definitions of what DevOps really means.
Given the new emphasis on CI and continuous delivery, you'd think that the industry would be offering all kinds of new tools somewhat akin to the sudden profusion of cloud technology vendors. But in fact, the reverse is happening. The high end is consolidating around two or three principal products, and the low-to-middle end is being dominated by two OSS solutions. The numerous other OSS CI products of the past have disappeared entirely or are simply awaiting word of their impending doom.
At the high end, there are IBM Rational BuildForge, ElectricCloud's Electric Commander, and UrbanCode's DevOps Platform. These products regularly handle the build, test, deploy stages of codebases greater than 20 million LOCs. In fact, that kind of line count is their sweet spot. In the next tier are mid-range products such as Atlassian's Bamboo. There then comes a very large gap as we enter the domain of CI servers for SMBs and enterprise departments. Historically, these were served by open-source tools, especially Cruise Control. Other competitors, although somewhat less capable than Cruise Control, were Continuous, Hudson, LuntBuild, and others. Today, these are all more or less shrinking (LuntBuild seems to have ceased activity entirely) and being replaced by Jenkins (formerly Hudson).
Hudson was, for years, gaining ground on the other products listed here due to its ease of installation and numerous plugins. When it was acquired by Oracle as part of the Sun purchase, there arose a dispute over the Hudson name. Most developers, including the principal developer, decided to fork the project and renamed it "Jenkins." Hudson was then donated by Oracle to the Eclipse Foundation, where it is primarily maintained by Oracle contributors and staff from Sonatype (the Maven company). While the bulk of the new activity is occurring in the Jenkins fork, Hudson is undergoing a top-to-bottom cleanup. Which version you prefer depends mostly on personal choice as the differences between them are salient mostly to diehards within the respective communities. Either one will serve you well. And between them, they are clearing out all other competitors in the low to lower-middle strata of the market.
It's not often that we see a market's mission expand, while the number of its constituent products contracts. Nonetheless, I expect, that both trends will continue. Continuous delivery will reach farther into development process automation and the number of companies who can keep up with the new demands will continue to shrink. As a result, it makes sense to take time to choose your CI platform with particular care. CI builders can be difficult to swap out if you made the wrong choice.
Updated to move UrbanCode to the top tier in scalability, which is where it should have been categorized originally.