Continuous integration explained

Continuous integration (CI) is a working practice: every developer merges their work into the shared main branch at least daily, and every merge is verified by an automated build that compiles the code and runs the tests. The tool that runs the build (GitHub Actions, GitLab CI, Jenkins, Woodpecker) is called a CI server, but the practice is the point; the server only makes it cheap.

The problem it solves

Before CI, teams worked on separate branches for weeks and merged at the end. The merge was painful (hundreds of conflicts), the merged result was broken in ways nobody could attribute, and fixing it took days. The longer two pieces of work stay apart, the more they drift. Integrating continuously keeps the drift tiny: a conflict involves yesterday’s changes, not last month’s, and a failing build points at the one commit that broke it.

What a CI run does

A typical pipeline, triggered by a push or a pull request, runs on a clean machine and does the following in order, stopping at the first failure:

1. Check out the exact commit being tested.
2. Install dependencies from a lock file, so the build does not depend on what happened to be on someone’s laptop.
3. Lint and format: cheap checks for style, unused imports and obvious errors.
4. Build or compile, including type checks for typed languages.
5. Test: unit tests first, then slower integration tests against a temporary database or service.
6. Report: a green check or a red cross on the commit and the pull request, with logs attached.

The minimal GitHub Actions expression of that idea fits in a few lines:

on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - run: make test

Everything else in CI is refinement of this: faster feedback, more kinds of checks, more platforms.

Rules that make CI work

• The build must be fast. Ten minutes is a common ceiling; beyond that people stop waiting for the result and start merging before it finishes. Split slow tests into a separate job or run them nightly.
• A red main branch is everyone’s top priority. Either fix it or revert the commit within minutes. A team that lives with a red build has no CI, only a slow notification system.
• Test on a clean machine. “Works on my machine” is exactly the class of bug CI exists to catch; the runner must install everything from scratch.
• Pin what you depend on. Lock files for packages, exact versions for actions and container images. A build that breaks because a dependency released a new version overnight teaches people to distrust the red cross.
• Do not require manual steps. If a human has to click something for the build to be trusted, it will be skipped under pressure.

Pull requests and branch protection

Most teams combine CI with short-lived branches and pull requests: push a branch, open a pull request, CI runs on the proposed merge, a colleague reviews, and the merge button is enabled only when the checks are green. Branch protection rules on the main branch enforce the last part so nobody can merge around a failing build. The branch still lives only hours or a day or two, which keeps the spirit of integrating continuously.

CI, CD and the other CD

• Continuous integration: every change is built and tested automatically.
• Continuous delivery: every green build also produces a deployable artifact (a container image, a package) and could be released at any moment with one action.
• Continuous deployment: every green build on main is released to production automatically, with no human in the loop.

They build on each other. You cannot deliver continuously without integrating continuously, and you should not deploy automatically until the test suite is trusted enough to be the only gate. Many teams stop at continuous delivery deliberately, releasing on a schedule, and that is a legitimate choice.

Where to start

Pick the test command you already run by hand and make a pipeline that runs it on every push. That single job catches the most common failure (someone forgot to run the tests) and gives the team a green check to protect. Add linting, a second language version or a deployment step only after the basic loop is reliable. The tutorial Your first GitHub Actions workflow: run tests on every push does exactly that.

Official documentation

• Martin Fowler: Continuous Integration
• GitHub Docs: About continuous integration
• GitLab CI/CD documentation