Traditional software development methods don't dictate how frequently or regularly you integrate all of the source on a project. Programmers can work separately for hours, days, or even weeks on the same source without realizing how many conflicts they are generating.

In XP, pairs commit their source to the code repository, and clean up any differences or conflicts, several times per day. At the very least you should integrate after you finish each task. It is even better to integrate after each test-code-refactor cycle. That way you are integrating every 15--30 minutes. When you're doing this, it's especially important to have your tests run quickly, because before integrating you have to verify that all the tests run.

It is vital to never leave anything unintegrated at the end of the day. If you can't integrate before you leave for the day, throw it out and start fresh in the morning. If a task takes longer than a day to do, either the task is too complex (and has to be broken up) or your solution is too complex (and you need to find a simpler one). In either case, start over.

Integrating the code continuously works well if you have an exhaustive suite of automated unit tests that ensure that you are not committing buggy code. And at the end of each day, the entire codebase has become, by definition, a solid build, generally in good enough shape that anyone can play around with it safely. Frequent integration is one of the practices that are vital to a shared codebase.

Continuous integration means that integration is never a headache, because your work reflects only slight divergence from the codebase. If the team must regularly deal with small-scale divergences, they never have to deal with truly scary ones. They also get the opportunity to discuss different design approaches on the day that they arise, because integrating that day brings them to the entire team's attention. This is another way in which XP prevents small design flaws from blossoming into large ones.

[Next Practice]