Skip to content
Getting Digital
Contact

Continuous Integration (CI)

Also: CI, CI/CD, CI pipeline, build pipeline, continuous delivery, continuous deployment, trunk-based development

Continuous integration is the practice of every developer merging their work into a shared mainline at least once a day, with an automated build and test run on each merge, so that integration problems surface within minutes of being created rather than weeks later at release time.

Assessment. The practice consists of merging to a shared mainline at least daily and keeping the build passing, with any failure fixed promptly. The pipeline makes this affordable but does not replace it: a team whose feature branches remain unmerged for weeks is not integrating continuously, and the accumulated merge conflicts are what the practice exists to prevent.

Martin Fowler's description, first written in 2000 and revised in 2024, defines the practice as each member of a team merging their changes into the codebase together with their colleagues' changes at least daily. The supporting practices follow from that sentence: everything in a version-controlled mainline, an automated build, a build that tests itself, every push to the mainline triggering a build, a broken build fixed immediately, a fast build, work in progress hidden behind flags rather than branches, testing in a clone of production, visible status and automated deployment. The automation is what organisations purchase; the daily merge is what changes the outcome.

The pipeline itself is a program that runs on every push to the repository. It checks out the commit, installs dependencies, compiles or bundles, runs the linter and the unit tests, often builds a container image, and reports a pass or a fail back to the pull request within minutes. Hosted runners make this a configuration file rather than a server to maintain; the GitHub Foundations exam covers Actions at that level, and the DevOps Engineer Expert exam expects a candidate to design the whole chain. The DevOps and CI/CD courses teach the configuration; a team's own release history demonstrates why the configuration alone is not enough.

  • Continuous integration: merge to the mainline daily; every merge is built and tested automatically.
  • Continuous delivery: every change that passes the pipeline is deployable, and the release to production is a button.
  • Continuous deployment: the button is removed; every passing change goes to production on its own.

Branch strategy decides whether the practice is real. Long-lived feature branches postpone integration by definition, and the merge at the end of three weeks is where conflicting assumptions, renamed functions and duplicated work meet. Trunk-based development keeps branches to hours or a day and hides unfinished features behind flags so that incomplete work can ship dark. The research summarised in Accelerate links this to four measurable outcomes, deployment frequency, lead time for changes, change failure rate and time to restore service, and found that teams which integrate and deploy more often also break production less, which contradicts the common assumption that caution means releasing less often. Git makes short branches cheap; the team's habits decide whether they stay short.

In practice

A six-person team ships a monthly release from a long-lived development branch. Two engineers rename the same module in separate feature branches; the conflict appears on the twenty-eighth and takes a day to resolve, and a regression in the merged result reaches customers because the test suite ran against neither branch in its final form. The same team on trunk-based development would have met the conflict on day two, in a ten-line diff, with the suite running on every push; the rename would have been a brief conversation rather than a release-week incident.

Often confused with

Git
Git is the version-control system that stores the branches and merges; continuous integration is a team practice about how often those merges happen and what runs when they do. Git permits three-week branches as readily as three-hour ones.
Unit Testing
Unit tests are the checks that make a build self-testing; continuous integration is the practice of running them on every merge to a shared mainline. Tests without CI run when someone remembers; CI without tests proves only that the code compiles.

Key takeaways

  • →Merge to the mainline every day and keep the build green: that is the practice. The pipeline is the tool that makes it affordable.
  • →Long-lived feature branches cancel the benefit. Short branches and feature flags keep integration continuous.
  • →Integration, delivery and deployment are three steps on one road; most teams stop at delivery with a manual release step, which is appropriate for many products.

Related concepts

  • Learn firstGit

    Daily merges to a mainline presuppose version control.

  • IncludesUnit Testing

    The test suite is what makes a continuous-integration build self-testing.

Where this concept sits in the field

Certifications that test this

Vendor exams whose syllabus covers this concept: facts, cost and a preparation path on each page.

More courses from these categories

Courses from the categories where this concept is taught. Details, price and the provider link are on each course page.

AI for Business: Transforming Strategy & Operations

Udemy

6 Live Sentiment Analysis Trading Bots using Python

Udemy

The Ultimate React Js Responsive Portfolio Website (2025)

Udemy

UI & UX Design, Animation And Material design In Javafx

Udemy

Vue JS Portfolio Project - Vue Training for Beginners

Udemy

Learn programming in Java (Coding, Graphics and Animation).

Udemy

FAQ

Is CI the same as having a pipeline on GitHub Actions or GitLab?
The pipeline is necessary and not sufficient. If branches live for weeks and a red build stays red for days, the pipeline reports problems late and nobody acts on them. The practice is daily merges and immediate fixes; the runner is where the build happens.
How fast should the build be?
Fast enough that a developer waits for it rather than context-switching: ten minutes is the common ceiling. Longer suites move to a second stage that runs after the fast one passes, so that the signal most people need arrives first.
Does continuous integration require continuous deployment?
No. Many regulated or customer-facing products stop at continuous delivery, where every passing change is deployable and a person decides when. Continuous deployment removes that decision and suits products with strong automated checks and quick rollback.

Sources

The primary text this definition rests on. Read it before relying on this one.

  • Fowler, M., Continuous Integration (revised edition) (2024)
  • Forsgren, N., Humble, J. and Kim, G., Accelerate: The Science of Lean Software and DevOps (2018)
  • Humble, J. and Farley, D., Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (2010)

Last reviewed 3 October 2026 · Getting Digital