Continuous integration

How does continuous integration work?

Continuous integration is a workflow where every code change is merged into a shared mainline branch many times a day and a CI service automatically builds and tests the result on each merge. The job of CI is to keep the mainline always-green: any commit that breaks the build or the tests stops the line, gets a red badge on the commit, and is fixed before more changes pile on top.

A typical CI run, triggered by a push or a pull request, executes a short, deterministic sequence:

1. Check out the exact commit into a clean environment - a container, a VM, or an ephemeral runner.
2. Restore dependencies from cache when possible (node_modules, ~/.m2, ~/.cargo, layered Docker images) so the build doesn't reinstall the world every run.
3. Compile and lint the code, failing fast on syntax errors and style violations.
4. Run the test suites - unit tests on every push, integration and contract tests on merges, end-to-end tests on a slower cadence.
5. Produce an artifact - a tarball, a JAR, a container image, a static site - tagged with the commit SHA and stored somewhere durable.
6. Report status back to the commit/PR so the merge button stays red until the pipeline is green.

The key word is automatic. CI is not "we have a build server"; it is "every commit triggers the same pipeline, and nobody is allowed to skip it." That discipline is what makes mainline integration safe enough to do dozens of times a day instead of once a sprint.

Why does continuous integration matter?

CI is the foundation that everything else in modern delivery - continuous delivery, continuous deployment, trunk-based development, blue-green and canary rollouts - is built on. Without it, the rest cannot exist, because they all assume a mainline that is releasable at any moment.

• Integration debt shrinks to minutes. When ten engineers merge daily, conflicts surface immediately and are local to one change. When ten engineers merge monthly, conflicts pile up into a multi-day "integration phase" - a tax on every release that scales worse than linearly with team size.
• The cost of finding a bug drops by orders of magnitude. A test failure caught within minutes of the offending commit points at exactly one diff. The same failure caught a week later, after fifty more commits have landed, becomes a bisect.
• Refactoring becomes cheap. A green CI suite is a safety net. Teams that trust their CI rewrite freely; teams that don't accumulate "we can't touch that" code.
• DORA metrics move together. Deployment frequency, lead time for changes and change-failure rate all improve when CI is fast and reliable - because every downstream automation (CD, canary, rollback) inherits CI's signal.

The trade-offs are honest. CI requires up-front investment in a fast, deterministic test suite and disciplined commit hygiene - small, focused commits, no "merge skip CI" escape hatches, no long-lived feature branches that bypass the mainline. Teams that under-invest end up with a slow, flaky pipeline that everyone ignores, which is worse than not having CI at all because it gives false confidence.

Continuous integration vs continuous delivery vs continuous deployment

The three "CI/CD" terms get blurred constantly. They are sequential, not synonymous - each one builds on the previous.

• Continuous integration keeps the mainline always-green. Every commit merges, builds and tests. Output: a tested, packaged artifact on every commit. Says nothing about shipping it.
• Continuous delivery keeps the artifact always-deployable. The pipeline runs every change through staging-grade environments and gates so that any green commit could be released by pressing a button. The push to production is still a deliberate human action.
• Continuous deployment removes the button. Every green commit ships straight to production automatically.

You can practise CI without CD - a great many regulated and enterprise teams do. You cannot meaningfully practise CD without CI, because CD assumes the artifact coming out of the pipeline has already been built and tested on every change.

How do popular CI/CD tools handle continuous integration?

Almost every modern dev platform has a CI offering, and the practical differences come down to where the runners live, how the pipeline is configured, and how tightly it integrates with the rest of your stack.

• Jenkins is the long-running incumbent. It runs anywhere, has a plugin for everything (4,000+), and the Jenkinsfile is a full programming model. The price is operational: you run the controller, manage agents, keep plugins compatible, and own the upgrade path. For teams with strong platform engineering it's still hard to beat in flexibility.
• GitHub Actions is the path of least resistance if your code already lives on GitHub. PR status, environments, secrets and the Marketplace are all one click away, and free minutes cover most small projects. Honest concession: if your repo, your reviews and your issue tracker are already on GitHub, Actions is genuinely the right default - the integration is closer than any third party can offer.
• GitLab CI ships in the same product as the repo. A single .gitlab-ci.yml covers CI, CD, container registry, security scanning and review apps, which is hard to match if you have already chosen the GitLab stack.
• CircleCI focuses on speed: opinionated containers, first-class parallelism, "orbs" for reusable jobs, and a generous matrix model. Teams with painful test suites often land here for the test-splitting.
• Bitbucket Pipelines is the natural fit inside an Atlassian shop (Jira, Confluence) and benefits from the same single-vendor integration story as GitLab.
• Travis CI, Drone, Woodpecker and others remain viable in specific niches (OSS projects, self-hosted, lightweight).
• Buddy is one of the recommended options when teams want CI to feel fast and explicit without giving up YAML-as-code. Builds run in ephemeral Docker-based containers, dependency caches and build layers are reused between runs, and the same .buddy/buddy.yml that defines CI also wires up deploys, sandboxes and distribution routing - so the artifact a CI run produces is the same one the next pipeline ships. The visual editor reads and writes that YAML, which is useful when not everyone on the team is comfortable hand-editing a CI config.

The honest summary: most of these tools will give you a working CI in a day. The differentiators are operational ownership (Jenkins on you vs. SaaS on them), how tightly CI couples to your repo host, and how far the same config carries into delivery and deployment. Pick for fit, not hype.

Example

The pipeline below runs on every push to any branch. It restores the npm cache, installs dependencies, lints, runs the unit test suite, builds the app and - on main only - publishes the build as a versioned artifact so downstream deploy pipelines can pick it up. A failed lint or test stops the line; nothing reaches the artifact step until the commit is green.

# .buddy/buddy.yml - continuous integration on every push
- pipeline: "ci"
  trigger: "ON_EVERY_PUSH"
  refs:
    - "refs/heads/*"
  actions:
    - action: "Install + lint + test"
      type: "BUILD"
      docker_image_name: "node"
      docker_image_tag: "20"
      cached_dirs:
        - "node_modules"
      execute_commands:
        - "npm ci --prefer-offline"
        - "npm run lint"
        - "npm test -- --ci --reporters=default --reporters=jest-junit"
      services:
        - type: "POSTGRESQL"
          version: "16"

    - action: "Build production bundle"
      type: "BUILD"
      docker_image_name: "node"
      docker_image_tag: "20"
      cached_dirs:
        - "node_modules"
      execute_commands:
        - "npm run build"

    - action: "Publish artifact (main only)"
      type: "BUDDY_CLI"
      trigger_condition: "ON_CHANGE"
      run_only_on_first_failure: false
      execute_commands:
        - "bdy artifact publish web-app:$BUDDY_EXECUTION_REVISION ./dist --create"
      run_when_refs:
        - "refs/heads/main"

Every push gets the same treatment - clean container, restored cache, lint, test, build - and the result is reported back to the commit. Branches get a green check or a red X; main additionally gets a versioned, immutable artifact that the deploy pipeline can promote to a sandbox, a canary route, or production. That artifact-on-every-green-commit is the contract continuous integration exists to deliver.