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 together 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.