0

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.)

Improve this question
1
  • The definition according to who? Merriam-Webster doesn't have an entry. Commented Jul 16, 2021 at 11:58

2 Answers 2

Reset to default
6

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.

Improve this answer
6
  • 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? Commented 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. Commented 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? Commented 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. Commented Jul 16, 2021 at 16:41
  • 1
    Remember that semantic versioning is only applicable for products that expose an API to be used in other products. It is intended to allow dependency managers to select a compatible version automatically. Semantic versioning is not relevant for products that have no external API, or whose dependants don't get to choose a version. Commented Feb 2, 2023 at 17:33
2

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.

Improve this answer
0

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.