Skip to content

continuous integration

Continuous integration, or CI, is the practice of merging every developer’s work into a shared mainline often, usually at least once a day, with an automated build that runs the test suite against each merge. Catching integration problems this early keeps them from piling up into a painful merge at the end of a project.

Each push to version control triggers a fresh checkout, a build, and a full test run, and a change counts as integrated only once that run comes back green:

Left to right pipeline. A teal "Push to mainline" node runs gray stages (install, lint, pytest). A "pass" advances toward a green "Build green", and any "fail" branches to a coral "Build red".
Every stage must pass for a green build, and the first failure turns it red and blocks the merge.

The practice grew out of Extreme Programming in the 1990s, and Martin Fowler’s canonical write-up sets the bar at one mainline commit per developer per day, each verified by an automated, self-testing build.

How It Shows Up in Practice

A Python developer meets CI first as a status check on a pull request: a green checkmark that says the tests passed on a clean machine, or a red one that blocks the merge until someone fixes it. The rules live in a workflow file committed alongside the code, and the same idea has many implementations. GitHub Actions, GitLab CI/CD, and Jenkins all watch the repository and run a defined sequence of steps on every push.

A minimal GitHub Actions workflow that installs the project and runs its tests on each push and pull request reads like this:

Language: YAML 
name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-python@v6
        with:
          python-version: "3.14"
      - run: python -m pip install -e ".[test]"
      - run: pytest

The run usually layers in more than tests. A linter, a type check, and a coverage gate often share the same sequence, and the whole thing aims to finish in around ten minutes so feedback stays fast. The steps run in order and stop at the first failure.

A red build is meant to be the team’s top priority, because every later commit now builds on a broken base until someone reverts or repairs it.

Continuous Integration vs. Continuous Delivery

CI is the foundation that two later practices build on. Continuous delivery keeps the mainline in an always-releasable state, so shipping becomes a business decision rather than an engineering scramble. Continuous deployment goes one step further and releases every green build to users automatically.

All three lean on the same thing CI provides, a trustworthy automated signal that the mainline still works. That signal is only as reliable as the tests behind it, so a single flaky test that fails at random can erode trust in the whole build. To see how teams keep that test suite both fast and thorough, read test pyramid.

Continuous Integration with Python: An Introduction

Tutorial

Continuous Integration With Python: An Introduction

In this Python tutorial, you'll learn the core concepts behind Continuous Integration (CI) and why they are essential for modern software engineering teams. Find out how to how set up Continuous Integration for your Python project to automatically create environments, install dependencies, and run tests.

intermediate best-practices devops testing

For additional information on related topics, take a look at the following resources:

By Martin Breuss • Updated June 22, 2026
Software Engineering Glossary Share Feedback