It seems that there are at least two possible definitions of continuous integration:

  1. Frequent merging of a codebase to a common codebase (e.g. daily merge to the main branch of a VCS server).
  2. Frequent building and testing of a codebase (e.g. build and test at each push to a VCS server).

Both 1 and 2 can be automated. 1 does not imply 2, and 2 does not imply 1.

What is the current definition of continuous integration? (Please back up your claim with a reference.)

  • The definition according to who? Merriam-Webster doesn't have an entry.
    – user253751
    Jul 16, 2021 at 11:58

2 Answers 2


There is no singular current definition of continuous integration.

In Extreme Programming Explained, 2nd edition, Kent Beck wrote:

Integrate and build a complete product. If the goal is to burn a CD, burn a CD. If the goal is to deploy a web site, deploy a web site, even if it is to a test environment. Continuous integration should be complete enough that the eventual first deployment of the system is no big deal.

Since continuous integration is a core practice of Extreme Programming and Kent Beck is one of the originators of Extreme Programming, I'd consider this to be the "correct" definition of what continuous integration is.

This is much further than either of your definitions since it not only requires developers to merge their changes to a common codebase as well as building and testing that codebase but also deploying or preparing to deploy that codebase to something - creating an installer, deploying to a dev or test environment, pushing to a simulator. Beck's definition is inclusive of what some people consider continuous delivery.

However, at least in my experience, many people do not use the term "continuous integration" in a way that is consistent with the description from Extreme Programming Explained. In my experience, most people separate continuous integration (merging, building, and testing) from continuous delivery (continuous integration plus packaging for release and possibly deployment to test environment).

For completeness, I also checked the IEEE Software and Systems Engineering Vocabulary, which pulls in definitions from various IEEE standards. IEEE 2675:2021 (the IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment) defines "continuous integration" as a "technique that continually merges artifacts, including source code updates from all developers on a team, into a shared mainline to build and test the developed system". Without reading the whole standard, my impression is that the IEEE also separates continuous integration from continuous delivery, which is defined as "software engineering practices that allow for frequent releases of new systems (including software) to staging or various test environments through the use of automated tools".

Which definition is correct? I'm not sure that it matters. Unfortunately, there are many terms and concepts in software engineering that have varying meanings to different people, teams, and organizations. It's important to ask questions. If someone uses a term that is unclear or you find yourself not able to effectively communicate, take a few minutes to define the term. Teams and organizations should take a little bit of time to normalize their terms and definitions for effective communication.

  • Awesome answer Thomas (discussion and references), thanks! You and the IEEE 2675 standard puts building and testing after merging. Yet on GitHub repositories building and testing happen before merging (you cannot usually merge before the test suite passes), for instance see this pull request in the CPython repository. So is it an error in the standard? If not, what is the point of building and testing after merging if it has already been done before merging? Does the CPython repository also build and test after merging?
    – Géry Ogam
    Jul 16, 2021 at 14:55
  • 1
    @Maggyero Why not both? It depends on your build pipeline, what types of tests you have, and how long they take. You want pre-merge (and perhaps post-merge) tests to be relatively quick (with post-merge perhaps taking a little longer) to get rapid feedback. Longer tests may be run less frequently on the head of the integration branch. There's no one right answer here, but I'd suggest that the common approach is to take the development branch, merge in the latest integration branch, run tests, and merge if tests pass increases the chance of a successful merge that doesn't introduce errors.
    – Thomas Owens
    Jul 16, 2021 at 15:04
  • I see. Since Kent Beck’s continuous integration (or continuous delivery) includes packaging (after merging, building, and testing), it implies that the version number is increased daily. With semantic versioning I guess that you should increase the build number (e.g. 1.0.0+20130313144700), shouldn’t you?
    – Géry Ogam
    Jul 16, 2021 at 16:31
  • 1
    @Maggyero How you handle versioning is independent of this. But I would expect that a build number is always increasing, yes, and ideally at least once a day. How frequently you merge and build depends on the situation you are in and the branching strategies, but if a working day goes by and nothing has been merged into the integration branch, that would raise some questions.
    – Thomas Owens
    Jul 16, 2021 at 16:41
  • I judge every continuous, whichever, implementation with what I consider the most significant metric. How well it passes #2 on the Joel test: "Can you make a build in one step?" Jul 17, 2021 at 18:38

Originally, it was # 1. Here's an excerpt from the definition on the C2 wiki.

Each time your code improves, you should send each refactor & addition that improved it to all your colleagues' computers.

But that was the early 90s. Since build servers, or continuous integration pipelines became a thing, the term is often used as a shorthand for that.

Here's how AWS explains their "AWS Continuous Integration" offering under the heading How does Continuous Integration Work?

Continuous integration refers to the build and unit testing stages of the software release process. Every revision that is committed triggers an automated build and test.

So I would say it's context-specific whether it's # 1 or # 2. I think # 2 is more common these days because, while both practices are usually aspired to, # 2 is more salient.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.