Continuous integration, often shortened to CI, is the practice of integrating each developer’s changes into a shared codebase frequently rather than letting separate lines of work diverge for long periods. Martin Fowler, who popularized the term in his widely read article on his own site, describes it as “a software development practice where each member of a team merges their changes into a codebase together with their colleagues changes at least daily.”
The key idea is that every integration is verified by an automated build and an automated test suite. When merges happen often and are checked automatically, the gap between introducing a problem and discovering it stays small, so defects are caught while the change that caused them is still fresh. This stands in contrast to the older pattern of a painful “integration phase” in which separately developed pieces were combined late and broke in ways that were hard to diagnose.
The practice was named and developed within Extreme Programming, the agile methodology in which frequent integration was one of several mutually reinforcing disciplines. Fowler’s article, first published in 2000 and revised over the following years, gave the practice a clear description that spread well beyond its original context.
Continuous integration created demand for the tooling that automates it: servers and services that watch a repository, build the software on every change, run the tests, and report results. Jenkins and Travis CI are among the tools built to make this loop fast and routine, and CI in turn became the foundation on which continuous delivery and DevOps practices were built.