Overview:

This concept introduces the practice of continuously integrating completed change sets in order to reduce the effort required to merge parallel development, to find bugs earlier, and to drive a collaborative work environment.

Main Description:

Continuous integration is an implementation practice where team members integrate their work with completed Change Sets from other developers, and test the application, before making their work available to others. This enables detection of integration errors as early as possible, either from compiler errors, configuration management system notifications, or failures reported by the test suite. Ideally the integration is done automatically prior to Promoting Changes.

Continuous integration provides the following benefits:

1. Improved feedback. Continuous integration shows constant and demonstrable progress.
2. 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.
3. 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.
4. 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.
5. Reduced number of parallel changes that need to be merged and tested.
6. Reduced number of errors found during system testing. All conflicts are resolved prior to making new change sets available, by the person who is in the best position to resolve them.
7. Reduced technical risk. You always have an up-to-date system against which to test.
8. Reduced management risk. By continuously integrating your system you know exactly how much functionality that you've built to date, improving your ability to predict when and if you're actually going to be able to deliver the necessary functionality.

Guideline:

Continuous integration is a software development practice that completely rebuilds and tests the application frequently -- ideally, every time a change is introduced.

Basic steps:

The detailed application of continuous integration depends on which tools you use (configuration management system, automated build tool, automated test tool, and so forth). However, these are the basic steps:

1. A developer, let's call her Jane, selects a work item to work on.
2. Jane updates her Workspace to include the most recent Implementation from the integration workspace.
3. Jane makes her changes in her workspace to both her developer tests and to the implementation, and then she tests the changes.
4. Before committing the changes, Jane updates her workspace again (because other developers may have introduced conflicting changes) and reruns her developer tests.
5. If these tests are successful, the changes are promoted (Promoting Changes guideline) to the integration workspace.
6. A complete Build of the application is performed by using the implementation from the integration workspace, and the entire suite of developer tests is run on this build.
7. If any of these tests fail, the team is notified, and the failed test should be addressed as soon as possible.
8. This process repeats as the team develops and continuously integrates and tests functionality in small increments.

Constraints:

Conceptually, continuous integration can be performed manually. However, in practice, there are several constraints that must be respected for it to be effective:

1. All changes must be introduced into a tested configuration that you know to be good.
2. The integrate-build-test cycle must be fast enough so that it can be completed quickly and the team notified of the results. Many published guidelines promote a 10-minute cycle.
3. Keep the Change Sets small enough so that the work can be completed and integration performed several times per day. Many published guidelines promote a 2- to 4-hour cycle between integrations.

These constraints imply the need for a configuration management (CM) repository to maintain configuration information (Item 1 listed previously), automated build and test tools to meet the turnaround constraints (Item 2), and proper planning and discipline by developers to ensure that their work items and change sets are small enough to complete quickly (Item 3).