The terms CI (continuous integration), CD (continuous delivery), and the umbrella term CI/CD are often misunderstood and misused. Many think that continuous integration is primarily about automation and tooling, i.e., having an automated build pipeline, often evidenced by them referring to their pipeline as “the CI”. They are unaware that continuous integration is primarily about working in small increments and integrating their changes multiple times per day – well, continuously integrating. Continuous roughly means “without a break”.
Most developers never look up these terms – understandably, since they hear the same usage from others as well, more often than the correct one. This semantic diffusion can make communication difficult, because many developers who are convinced that CI/CD is a good thing might think for the wrong reasons that they are already doing it (or rather that they “have CI/CD”). One would hope that knowing what both “continuous” and “integration” means should be enough to question that usage, but too often we humans tend to retrofit the meaning of a term to our current understanding of it, and misunderstandings by non-native speakers might also contribute. However, the technical literature is pretty unanimous, and even most of the tool vendors use the terms correctly in their wikis, blogs, and documentation, if one were to read those. And it’s not just “colloquial usage” either, given how many experts in the field do use the terms correctly; usually I hear/read the terms used incorrectly by developers who are not actively involved with DevOps or might be using the term DevOps in a similarly incorrect way.
If you are in a situation where this misconception makes communication difficult and frustrating, below is a list of sources that explain the concepts and that have some amount of credibility (i.e., not personal opinions by random developers like me). Note that this does not mean that some of the details of the linked articles are not debatable or contradictory, but they all agree on the general concept. You might want to (tactfully) forward these links or even this article as a whole. They include some of the tool vendors of the CI/CD tools you might be familiar with.
JetBrains: What is Continuous Integration?
It’s the practice of having everyone who is working on the same project regularly merge their changes to the codebase into a central repository. […] Ideally, this process should be automated and carried out several times a day.
For everyone to build on the same foundation, you need to be working from the same repository and sharing your changes with each other frequently. A good rule of thumb is to have everyone commit their changes to master/trunk at least once a day.
Interestingly, the search engine preview showed an old, incorrect version of the article that was apparently still in the search engine cache. It said “Continuous Integration (CI) automates the continuation of code changes from contributors within a software project”, which is not just wrong, but is also the kind of explanation I would expect from someone who makes up a definition on the spot by guessing the meaning based on similar words they’ve heard. Fortunately they fixed that mistake.
JetBrains: Continuous Integration with Team City
TeamCity is a continuous integration/continuous delivery (CI/CD) server.
Continuous Integration is a software development practice in which developers commit code changes into a shared repository several times a day.
Note the deliberate use of the terms “CI/CD server” for the tool and “Continuous Integration” for the practice.
GitHub: About continuous integration
Continuous integration (CI) is a software practice that requires frequently committing code to a shared repository. Committing code more often detects errors sooner and reduces the amount of code a developer needs to debug when finding the source of an error.
You can build and test updates locally before pushing code to a repository, or you can use a CI server that checks for new code commits in a repository.
Again, note the distinction between “CI” and a “CI server”, which supports the practice of CI but is not strictly required by definition.
GitLab: Get started with GitLab CI/CD
CI/CD is a continuous method of software development, where you continuously build, test, deploy, and monitor iterative code changes.
This iterative process helps reduce the chance that you develop new code based on buggy or failed previous versions.
A perfect summary of the method of CI/CD and its goals, right before starting to explain how their tool can help enable that way of working.
CircleCI: What is a CI/CD pipeline?
A CI/CD pipeline coordinates all the processes involved in continuous integration and continuous delivery.
Continuous integration (CI) is a process in which developers continually commit code in small increments—sometimes multiple times a day—which is then automatically built and tested before it is merged with the shared repository.
Note the deliberate use of the terms “CI/CD pipeline” for the tool and “Continuous integration (CI)” for the practice.
CircleCI: What is continuous integration?
Developers continually commit changes in small increments (at least daily, or even several times a day), and each change is automatically built and tested by the CI server before it is merged into the product.
The fundamental tenet of continuous integration is quite simple: commit and integrate your code often—daily at a minimum.
Wikipedia: CI/CD
[…] CI/CD or CICD is the combined practices of continuous integration (CI) and continuous delivery (CD) […]
Continuous integration
Frequent merging of several small changes into a main branch.
minimumcd.org: Continuous Integration
While CI depends on tooling, the team workflow and working agreement are more important.
Work committed to version control may not be “feature complete”, but it must not break existing work. All work begins from the trunk and integrates into the trunk at least daily. If the CI server detects an error, the team stops feature work and collaborates to fix the build.
Extreme Programming Explained (Book by Kent Beck, 2nd Edition)
Continuous Integration
Integrate and test changes after no more than a couple of hours.
Continuous Integration: Improving Software Quality and Reducing Risk (Book by Paul Duvall)
Make it continuous—Ensure that the automated process is run with every change applied, using a CI server. If your team has the discipline, you can also choose to manually run the build with every change applied to the version control system.
Continuous Delivery (Book by Jez Humble and Dave Farley)
Continuous integration is a practice, not a tool. It requires a degree of commitment and discipline from your development team. You need everyone to check in small incremental changes frequently to mainline […]
The most important practice for continuous integration to work properly is frequent check-ins to trunk or mainline. You should be checking in your code at least a couple of times a day.
Accelerate (Book by Nicole Forsgren, Jez Humble, Gene Kim)
Continuous integration (CI). Many software development teams are used to developing features on branches for days or even weeks. […] Following our principle of working in small batches and building quality in, high- performing teams keep branches short-lived (less than one day’s work) and integrate them into trunk/master frequently.
Update 20.07.2024: Added JetBrains examples; reworded intro section.
Update 04.08.2024: Added GitHub example.
Raimund Krämer 