Continuous integration is the practice of merging the code of all developers on a project and testing for conflicts continuously, as changes are made (at least daily, but ideally several times a day), rather than infrequently or at the end of the project. The goal is to discover and resolve coding issues while the change that introduced them is fresh in the minds of the developers involved, and before additional layers of complexity are allowed to accumulate on top of those issues.
“Continuous integration doesn’t get rid of bugs, but it does make them dramatically easier to find and remove.”
— Martin Fowler, Chief Scientist, ThoughtWorks
One of the most frustrating experiences in software development is to “finish” coding a change after many hours, days, or weeks of work, only to find that your code cannot be merged to the main branch because it conflicts with recent changes made by other developers.
In traditional long-running projects, the “integration” phase was a time set aside near the end for resolving merge conflicts and bugs introduced by misunderstandings between teams. When issues were allowed to cascade across dozens, hundreds, or even thousands of changes, unwinding them could double the length of a project or even cause the project to be abandoned. Being trapped in this phase of a project even has a name: merge hell.
Continuous Integration shifts the discovery of coding conflicts to the left, to a point as far from the end of the project, and as close to the moment the conflicts are introduced, as possible. Teams who practice continuous integration spend less time triaging and resolving internal development issues and more time delivering value to their stakeholders. They are also more likely to enjoy their work and recommend their employer as a great place to work.
For specific recommendations on achieving effective continuous integration (CI) and avoiding watered-down CI practices that still lead all too often to merge hell, read Continuous Integration: What You Don’t Know Can Hurt You.