Developers check in their work and integrate it into the main stream regularly and frequently
Developers check in their work and integrate it into the main stream regularly and frequently, ideally several times a day.
As an XP core practice, the recommendation is to integrate work several times a day. Other methodologies may prefer a longer cycle period, but still benefit from Continuous Integration. Shorter cycles reduce the risk of interference with other developers, whether by blocking them by checking out a module that others want to modify, or where source control is non-blocking, by reducing the risk of, and amount of, work to be done merging code when updates are found to clash. There ought to be other practices in place to reduce the impact of instability if the code base is to change this frequently. Where everyone is working in small chunks, as is implied by Continuous Integration, this helps. Approaches to deal with the RippleEffect will also help.
Where a PrivateWorld approach is not in use, developers may struggle to keep up with continuous change, and NamedStableBases may be a more appropriate approach. Without TestDrivenDevelopment or some alternative approach that gives a complete set of automated regression tests, Continuous Integration will be expensive.