Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Continuous Integration

Pattern

A reusable solution you can apply to your work.

Also known as: CI

Understand This First

Context

This is an operational pattern that builds on Version Control and feeds into Deployment. Continuous integration is the practice of merging all developers’ work into a shared mainline frequently (at least daily) and validating each merge automatically with builds and tests. The idea is simple: if integrating code is painful, do it more often until it isn’t.

In agentic coding, CI becomes even more important. AI agents can generate large amounts of code quickly, and that code needs to be validated just as rigorously as hand-written code, arguably more so since the developer may not have read every line.

Problem

Developers work on separate branches for days or weeks. When they finally merge, the conflicts are enormous and the interactions between changes are unpredictable. Bugs hide in the gaps between components that were developed in isolation. Integration becomes a dreaded, multi-day event. How do you keep a codebase healthy and integrated when multiple people are changing it simultaneously?

Forces

  • Long-lived branches accumulate merge conflicts and hidden incompatibilities.
  • Running the full test suite manually before every merge is tedious and easy to skip.
  • Broken builds block everyone, creating pressure to either skip validation or delay integration.
  • Different developers (and agents) may introduce changes that individually work but collectively conflict.

Solution

Merge to the shared mainline frequently, ideally multiple times per day, and run automated validation on every merge. This validation typically includes compiling the code, running unit and integration tests, checking code style, and performing static analysis. If any check fails, the build is “broken” and fixing it becomes the top priority.

Set up a CI server (GitHub Actions, GitLab CI, Jenkins, CircleCI, or similar) that automatically triggers on every push or pull request. The CI pipeline should be fast enough that developers get feedback within minutes, not hours. If the full test suite takes too long, run a fast subset on every push and the full suite on a schedule.

The key discipline is that the main branch should always be in a working state. If a merge breaks the build, it gets fixed immediately, not left for someone else to deal with. This requires cultural commitment as much as tooling.

When working with AI agents, CI is your automated quality gate. The agent can generate code freely, but nothing reaches the main branch without passing CI. This gives you confidence to let agents work boldly while maintaining the safety of automated verification.

How It Plays Out

A team with three developers and one AI agent merges to main four to six times per day. Each push triggers a GitHub Actions workflow that runs tests in under five minutes. When the agent’s generated code introduces a failing test, the developer sees the failure in the pull request before merging. The broken code never reaches main.

A team without CI merges a week’s worth of changes on Friday. Two developers modified the same service with incompatible assumptions. The merge succeeds (no textual conflicts) but the application crashes on startup. The team spends their weekend debugging interaction effects that would have been caught immediately if they had integrated daily.

Tip

A good CI pipeline is fast. If it takes more than ten minutes, developers will start working around it: pushing without waiting for results, merging despite failures. Invest in making CI fast before making it comprehensive.

Example Prompt

“Create a CI workflow that runs on every pull request: install dependencies, run the linter, run the type checker, and run the test suite. Fail the PR if any step fails. Target total run time under five minutes.”

Consequences

Continuous integration keeps the codebase in a consistently working state. Integration problems surface immediately, when they are small and easy to fix. The team moves faster because merging is routine rather than risky. CI also produces a stream of verified artifacts that feed into Continuous Delivery and Deployment.

The cost is building and maintaining the CI pipeline, and the discipline of keeping it green. Flaky tests (tests that pass or fail unpredictably) are the bane of CI, because they erode trust in the system. A team that ignores red builds has CI in name only.

  • Depends on: Version Control — CI is triggered by version control events.
  • Enables: Continuous Delivery — CI is the foundation that makes continuous delivery possible.
  • Enables: Deployment — CI produces validated artifacts ready for deployment.
  • Uses: Environment — CI runs in its own dedicated environment.
  • Complements: Git Checkpoint — CI validates the code at each checkpoint.