“ In software engineering, continuous integration (CI) implements continuous processes of applying quality control — small pieces of effort, applied frequently. Continuous integration aims to improve the quality of software, and to reduce the time taken to deliver it, by replacing the traditional practice of applying quality control after completing all development.”
members of a team integrate their work frequently
each integration is verified by an automated build (including test) to detect integration errors as quickly as possible
Source = http://en.wikipedia.org/wiki/Continuous_integration See the advantages of CI
During November 2010, an issue arose in the community of Hudson with respect to the infrastructure used, which grew to encompass questions over Oracle's stewardship and perceived control of the project.
Negotiations between the principal project contributors and Oracle took place, and although there were many areas of agreement a key sticking point was the control of the name "Hudson" itself, which Oracle claimed, and for which it submitted a trademark registration in early December 2010 (not granted as of February 2011).
As a result, on January 11, 2011, a proposal was made to change the project name from "Hudson" to "Jenkins". The proposal was overwhelmingly approved by those that voted on January 29, 2011, creating the Jenkins project.
On February 1, 2011, Oracle indicated that they, in partnership with others in the community intended to continue development of Hudson making the necessary infrastructure changes, confirming two development branches.
Both the Jenkins and Hudson projects appear to consider the other to be a fork.
CloudBees is committed to supporting the ongoing growth, maturity and viability of the Jenkins Continuous Integration (CI) platform.
CloudBees also wants to promote engagement amongst the Jenkins community. Therefore, in support of these goals, CloudBees announces two contests to help identify and resolve bugs in the Jenkins CI platform.
The reporting and resolution of bugs improves the platform for the benefit of the entire Jenkins Community.
Jenkins vs. Hudson Comparison of key metrics
Most of the Huston developers moved to Jenkins and made more contribution.
Jenkins GitHub repositories outnumber Hudson by a ratio of sixty to one.
Jenkins 'ticket activity' is significantly higher than that of Hudson.
On May 3, 2011, the Eclipse Foundation in conjunction with the key Hudson committers, Oracle, Sonatype and other community supporters put forward a formal proposal for the transfer of Hudson, including the core code and problematic trademarks to the Eclipse Foundation.
The founder of Hudson saw the Oracle move as validating Jenkins. "When we were talking with Oracle to find a middle ground, they made it very clear that they have no intention of giving up the trademark control. But with this move, they clearly acknowledge that Oracle couldn't keep up with the Jenkins project.“
He also questioned whether Oracle could legally reassign copyright and relicense all the Hudson intellectual property as part of the move to Eclipse.
when unit tests fail or a bug emerges, developers might revert the codebase to a bug-free state, without wasting time debugging
developers detect and fix integration problems continuously - avoiding last-minute chaos at release dates, (when everyone tries to check in their slightly incompatible versions).
early warning of broken/incompatible code
early warning of conflicting changes
immediate unit testing of all changes
constant availability of a "current" build for testing, demo, or release purposes
immediate feedback to developers on the quality, functionality, or system-wide impact of code they are writing
frequent code check-in pushes developers to create modular, less complex code
metrics generated from automated testing and CI (such as metrics for code coverage, code complexity, and features complete) focus developers on developing functional, quality code, and help develop momentum in a team