Continuous Integration

In Turkish: Sürekli Entegrasyon

Updated October 6, 20263 min read

In short

Continuous integration is the practice of merging code changes into a shared main branch at least daily, with an automated build and tests checking every merge.

What is continuous integration?

Continuous integration, usually shortened to CI, is a development practice in which everyone merges their work into the shared main branch, often called the mainline, at least once a day. Every merge triggers an automated build and test run, so the team learns within minutes whether the combined code still works. The practice was named and spread by Extreme Programming in the late 1990s, and Martin Fowler's article about it made it widely known.

In practice, a CI service such as GitHub Actions, GitLab CI or Jenkins watches the repository. When someone pushes a commit or opens a pull request, it checks out the code on a clean machine, installs the dependencies, compiles the project, runs linters and the automated tests, and reports a green or red status back to the pull request. A red build is the team's top priority: whoever broke it fixes the problem or reverts the change before anything else is merged. To keep feedback fast, teams aim for a build of about ten minutes, a target that also comes from Extreme Programming.

Think of several people writing one report together. If each of them writes alone for a month and everything is combined the night before the deadline, the chapters contradict each other and merging takes days; developers call this integration hell. If everyone adds their pages to the shared draft every day and an editor reads it right away, conflicts stay small and get fixed while they are still fresh.

Continuous integration is often confused with continuous delivery, and with simply having a CI tool. CI ends with verified code on the main branch; continuous delivery picks up from there and keeps that code ready to deploy to production at any time. Running a CI server on feature branches that live for weeks isn't continuous integration in the original sense either: the point is to integrate small changes into the mainline often, which is why CI goes hand in hand with trunk-based development.

Key takeaways

Continuous integration means merging small changes into the main branch at least daily.
Every merge triggers an automated build and test run on a clean machine.
A broken build is fixed or reverted before anything else is merged.
Fast feedback matters: a build of about ten minutes is a common target.
CI verifies the code; continuous delivery keeps it ready to release.

Example

A CI workflow that checks every pull requestyaml

# .github/workflows/ci.yml: verify every pull request and every push to main
name: CI
on:
  pull_request:
  push:
    branches: [main]
jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - run: npm ci         # install the exact locked versions
      - run: npm run lint   # style and static checks
      - run: npm test       # a failing test turns the check red
      - run: npm run build  # prove the project still builds

Readers ask

What is the difference between continuous integration and continuous delivery?

Continuous integration builds and tests every change merged into the main branch. Continuous delivery goes further: it moves each build that passes through the remaining tests and environments, so it could be released to production at any time.

How often should developers integrate?

At least once a day, and often several times a day. The smaller and more frequent the merges, the smaller the conflicts, and the easier it is to find which change broke the build.

What happens when the CI build fails?

The team treats it as the most urgent task: whoever broke it fixes it quickly or reverts the change. Branch protection rules usually stop pull requests from being merged until their checks pass.

Sources

Spotted a mistake or something missing on this page?Suggest an edit