Kent Beck
2005-01-11 08:33:09 UTC
Integrate and test changes after no more than a couple of hours. Team
programming isn't a divide and conquer problem. It is a divide, conquer, and
integrate problem. The integration step is unpredictable, but can easily
take more time than the original programming. The longer you wait to
integrate, the more it costs and the more unpredictable the cost becomes.
The most common style of continuous integration is asynchronous. I check
in my changes. Soon thereafter, the build system notices the change and
starts to build and test. If there are problems; I am notified by email,
text message, or (most coolly) a glowing red lava lamp.
I prefer a synchronous model in which my partner and I integrate after
each pair-programming episode, no more than a couple of hours. We wait for
the build to complete and the entire test suite to run with no regressions
before proceeding.
Asynchronous integrations are a big improvement on daily builds
(especially without automated tests), but they don't have the inherent
reflection time built into the synchronous style. Waiting for the compiler
and the tests is a natural time to talk about what we've just done and how
we might have done it better. Synchronous builds also create positive
pressure for a short, clear feedback cycle. When I get notified of a problem
half an hour after starting a new task; I waste a lot of time remembering
what I was doing, fixing the problem, and then finding my place in the
interrupted task.
Integrate and build a complete product. If the goal is to burn a CD, burn
a CD. If the goal is to deploy a Web site, deploy a Web site, even if it is
to a test environment. Continuous integration should be complete enough that
the eventual first deployment of the system is no big deal.
programming isn't a divide and conquer problem. It is a divide, conquer, and
integrate problem. The integration step is unpredictable, but can easily
take more time than the original programming. The longer you wait to
integrate, the more it costs and the more unpredictable the cost becomes.
The most common style of continuous integration is asynchronous. I check
in my changes. Soon thereafter, the build system notices the change and
starts to build and test. If there are problems; I am notified by email,
text message, or (most coolly) a glowing red lava lamp.
I prefer a synchronous model in which my partner and I integrate after
each pair-programming episode, no more than a couple of hours. We wait for
the build to complete and the entire test suite to run with no regressions
before proceeding.
Asynchronous integrations are a big improvement on daily builds
(especially without automated tests), but they don't have the inherent
reflection time built into the synchronous style. Waiting for the compiler
and the tests is a natural time to talk about what we've just done and how
we might have done it better. Synchronous builds also create positive
pressure for a short, clear feedback cycle. When I get notified of a problem
half an hour after starting a new task; I waste a lot of time remembering
what I was doing, fixing the problem, and then finding my place in the
interrupted task.
Integrate and build a complete product. If the goal is to burn a CD, burn
a CD. If the goal is to deploy a Web site, deploy a Web site, even if it is
to a test environment. Continuous integration should be complete enough that
the eventual first deployment of the system is no big deal.