The effort required to integrate a system increases exponentially with time. By integrating the system more frequently, integration issues are identified earlier, when they are easier to fix, and the overall integration effort is reduced.  The result is a higher-quality product and more predictable delivery schedules.

Continuous integration provides the following benefits:

• Improved feedback. Continuous integration shows constant and demonstrable progress.
• Improved error detection. Continuous integration enables you to detect and address errors early, often minutes after they've been injected into the product. Effective continuous integration requires automated unit testing with appropriate code coverage.
• Improved collaboration. Continuous integration enables team members to work together safely. They know that they can make a change to their code, integrate the system, and determine very quickly whether or not their change conflicts with others.
• Improved system integration. By integrating continuously throughout your project, you know that you can actually build the system, thereby mitigating integration surprises at the end of the lifecycle.
• Reduced number of parallel changes that need to be merged and tested.
• Reduced number of errors found during system testing. All conflicts are resolved before making new change sets available and by the person who is in the best position to resolve them.
• Reduced technical risk. You always have an up-to-date system to test against.
• Reduced management risk. By continuously integrating your system, you know exactly how much functionality that you have built to date, thereby improving your ability to predict when and if you are actually going to be able to deliver the necessary functionality.

The essence of continuous integration

The essence of continuous integration can be described by the following activities:

• Developers make small changes to the latest integration-tested implementation in their workspaces, and they unit test them before making the changes available to the team.

• Change sets from all developers are integrated in an integration workspace and tested frequently (at least daily-- ideally any time a new change set is available).

The first activity ensures that changes are made to a configuration that is known to be good and tested before making the changes available. The second activity identifies integration issues early so that they can be corrected while the change is still fresh in the developer's mind.

The best way to read this practice is to first familiarize yourself with its overall structure: what is in it and how it is organized.  Then begin by reviewing the key concepts to understand the terminology. Next, review the Integrate and Create Build task Integrate and Create Build to learn what needs to be done. Finally, review the associated guidelines for more information on the overall workflow.

For step-by-step instructions on how to adopt this practice, see How to adopt the Continuous Integration practice.

Books and articles

For more information on this practice,  see the practice resource page on IBM® DeveloperWorks®.

• How to adopt the Continuous Integration practice

• Key Concepts
• Change Requests
• Change Set
• Workspace

• Build

• Integrate and Create Build

• Continuous Integration

• Promoting Changes

• Measurements

• [Technical Implementation]