Continuous Integration
The practice was described by Grady Booch in 1994 and formalized as a core practice of Extreme Programming by Kent Beck in 1999. Martin Fowler popularized it with his seminal article "Continuous Integration" (2000, updated in 2006).
Why it exists
When developers work on separate branches for days or weeks and then try to integrate their work, what is known as integration hell sets in: changes made by different developers are incompatible with one another, and resolving the differences takes more time than the original development.
Continuous integration solves this problem at its root: if everyone integrates frequently into the same branch, conflicts are small and surface immediately.
CI requirements
For continuous integration to work, the team needs:
- Version control: all code (and usually also configuration and infrastructure) lives in a shared version control repository.
- Automated build: the compilation and packaging process is automatic and reproducible.
- Automated test suite: unit and integration tests that validate that the code has not broken anything. Without tests, CI only automates compilation, not validation.
- CI pipeline: a CI server (Jenkins, GitHub Actions, GitLab CI, etc.) that runs the build and the tests automatically on every commit or pull request.
- Build status visibility: every team member knows at all times whether the build is red (something is broken) or green (everything passes).
CI and CD
Continuous integration is the first stage of a delivery pipeline:
- CI (Continuous Integration): integrating and validating code frequently.
- CD (Continuous Delivery): keeping the code in a deployable state at all times, with automatic deployments to staging environments after each successful integration.
- CD (Continuous Deployment): automatically deploying to production after each successful integration, without human intervention.
The difference between continuous delivery and continuous deployment is the point of human intervention before reaching production.
CI for AI-generated code
Continuous integration is especially critical in teams that use generative AI to produce code:
- AI-generated code may compile and appear correct without having been validated against the system's actual behavior. CI immediately detects whether the generated code breaks existing tests.
- AI agents that generate code autonomously need a robust CI pipeline as a quality control mechanism: every contribution from the agent must meet the same criteria as that of any developer.
- The reinforced DoD for teams working with AI includes automated static analysis and test execution as a mandatory part of the integration process.
Common mistake
Calling a build that runs once a day or at the end of the sprint CI. Continuous integration means "several times a day," not "more often than before." A nightly build is an improvement over having nothing, but it is not CI: the day's integration problems are not detected until the next day, when the context of the changes may have gone cold and resolution is more costly.
References
- Beck, Kent. (2000). Extreme Programming Explained: Embrace Change. Addison-Wesley.
- Fowler, Martin. (2006). "Continuous Integration". martinfowler.com.
See also
Want to advance in agility? You can search for calls for courses and exams or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.