In software engineering, continuous integration (CI) is the practice of merging all developers' working copies to a shared mainline several times a day that triggers automated build with testing. Grady Booch first proposed the term CI in his 1991 method, although he did not advocate integrating several times a day. Extreme programming (XP) adopted the concept of CI and did advocate integrating more than once per day – perhaps as many as tens of times per day. Rationale When embarking on a change, a developer takes a copy of the current code base on which to work. As other developers submit changed code to the source code repository, this copy gradually ceases to reflect the repository code. Not only can the existing code base change, but new code can be added as well as new libraries, and other resources that create dependencies, and potential conflicts. The longer development continues on a branch without merging back to the mainline, the greater the risk of multiple integration conflicts and failures when the developer branch is eventually merged back. When developers submit code to the repository they must first update their code to reflect the changes in the repository since they took their copy. The more changes the repository contains, the more work developers must do before submitting their own changes. Eventually, the repository may become so different from the developers' baselines that they enter what is sometimes referred to as "merge hell", or "integration hell", where the time it takes to integrate exceeds the time it took to make their original changes. Workflows Run tests locally CI should be used in combination with automated unit tests written through the practices of test-driven development. All unit tests in the developer's local environment should be run and passed before committing to the mainline. This helps prevent one developer's work-in-progress from breaking another developer's copy. Where necessary, incomplete features can be disabled before committing, using feature toggles, for instance. Compile the mainline periodically; run tests of the mainline and/or use continuous quality control A build server compiles the code periodically. The build server may automatically run tests and/or implement other continuous quality control processes. Such processes aim to improve software quality and delivery time by periodically running additional static analyses, measuring performance, extracting documentation from the source code, and facilitating manual QA processes. Use CI as part of continuous delivery or continuous deployment CI is