
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.