Continuous integration automatically builds and tests a project whenever a code change is committed to a shared source-code repository. It provides rapid feedback about integration problems and regressions, so developers can address issues while changes are still fresh. section 8.0
The practice works best when supported by a robust, comprehensive automated test suite. Automated scenarios—especially acceptance tests defined collaboratively with testers—verify simpler cases before a release reaches manual testing. Testers can then concentrate on complex or exploratory work, while teams release faster and with fewer regressions. section 8.0 section 1.2.1
A practical continuous-integration flow is:
- Commit a change to the shared source-code repository. section 8.0
- Automatically build the project and run its automated tests. section 8.0
- Use the results to expose integration issues, regressions, and the project’s current delivery status. section 8.0
- Extend the pipeline toward continuous delivery only when every successful build can serve as a potential release candidate and pass additional quality checks. section 8.0
From commit to focused testing
A developer commits a feature change. The integration process builds the application and runs unit and automated acceptance tests. If those checks pass, testers receive an application that has already cleared many simpler cases and can spend their time on exploratory testing. If a regression appears, the automated feedback identifies the problem earlier than a lengthy manual testing phase would. section 8.0 section 1.2.1
