in 99 words

Keep code integrated and build release infrastructure with the rest of the application. The ultimate goal is to be able to deploy all but the last few hours of work at any time.

To do so, integrate every few hours and keep your build, test, and other release infrastructure up to date. Each integration should get as close to a real release as possible.

Prefer synchronous integration, in which you wait for the integration to succeed, to asynchronous integration, in which a tool tests the integration for you. Synchronous integration requires fast builds, but ensures that they never break.

Brain Dump

Forces Affecting Continuous Integration

Inside the Book

• Continuous Integration
• Why It Works
• How to Practice Continuous Integration
• Never Break the Build
• The Continuous Integration Script
  • To update from the repository
  • To integrate
• Sidebar: Continuous Integration Servers
• Introducing Continuous Integration
• Dealing with Slow Builds
• Multistage Integration Builds
• Questions
  • I know we're supposed to integrate at least every four hours, but what if our current story or task takes longer than that?
  • What should we do while we're waiting for the integration build to complete?
  • Isn't asynchronous integration more efficient than synchronous integration?
  • Are you saying the asynchronous integration will never work?
  • Our version control system doesn't allow us to roll back quickly. What do we do?
  • We rolled back our check-in, but the build is still failing on the integration machine. What do we do now?
  • Why do we need an integration machine? Can't we just integrate locally and check in?
  • I seem to always run into problems when I integrate. What am I doing wrong?
  • I'm constantly fixing the build when other people break it. How can I get them to take continuous integration seriously?
• Results
• Contraindications
• Alternatives