Continuous integration

Edit · View history

Continuous integration

Continuous integration (CI) is a software development practice where developers frequently merge their code changes into a central repository, after which automated builds and tests are run. The key goals are to detect integration errors as quickly as possible and to provide immediate feedback to the team. CI is a core component of modern DevOps and Agile software development methodologies.

The practice was first popularised by Extreme Programming in the late 1990s, notably through the work of Kent Beck and the C3 project. The concept was further refined by the CruiseControl project (2001) and later by hosted services such as Jenkins and Travis CI.

Benefits

Typical workflow

1. A developer commits code to a shared version control system (e.g., Git).

2. A CI server monitors the repository and triggers a build upon each commit.

3. The build compiles the source, runs unit tests, and often performs static analysis.

4. If the build fails, the team is notified immediately; the developer who broke the build is expected to fix it promptly.

5. Successful builds may be deployed to a staging environment for further testing.

Common tools

History

Continuous integration grew out of the need to avoid the "integration hell" common in large projects where developers worked in isolation for weeks. Grady Booch used the term "continuous integration" in his 1991 book Object-Oriented Analysis and Design with Applications, but the modern practice was codified by the Extreme Programming community. The first dedicated CI server, CruiseControl, was released in 2001, and the Hudson project (later Jenkins) followed in 2005. By the 2010s, cloud-hosted CI services made the practice accessible to small teams and open-source projects.

See also