Continuous Integration is the idea of continuously merging the code of all developers into the code base. What does that mean? Well, when an application has more than one developer working on it periodically you need to make sure that the code all works together. Traditionally, we call this integration. In the old days (and in many shops today), we would pick various points in time (weekly, monthly, etc) to regularly integrate the code (often referred to as a “merge window”) to make sure everything everyone was doing worked together. As you might imagine, that integration period has a few problems.
First up, if the period is too big (e.g. monthly), there is often a lot of work to merge the code together. Why? Because developers in that long a span of time may actually make changes to the same files or even the same lines of code. We also have no real way of predicting how many conflicts we can expect. As a result, we end up with a merge procedure which is unpredictable in length and requires detailed, careful work by, usually, one person that also blocks the rest of the team from continuing. Typically we would also use this merge window to integrate any patches for any of the dependencies of the application, e.g. operating system updates, security fixes in libraries.
Obviously, we can mitigate some of these issues by reducing the length of time between “integrations.” However, we still have the unpredictability factor and one person blocking the team for some period of time.
As a result, even though continuously integrating may require more effort (in total) over time than using traditional integration merge windows, the consensus is that the advantages are worth it. Specifically, the work is allocated not to a single “merge expert” but rather the author’s of the code, the chances for major conflicts are much lower, and typically results in better software.