Continuous Integration

Rarely does a single person work on a larger program; instead, entire teams do. Everyone writes a different part, and at some point all the parts have to be brought back together into one working whole. This bringing-together is exactly what is called integration. Continuous Integration means: you don’t do this just once at the end, but constantly, often several times a day. Each time, a computer automatically checks whether the overall program still starts up afterward and still does the right thing. The English term has also become established in German usage, abbreviated as CI.

Why late merging becomes so expensive

It used to be common to work separately for months and only throw everything together shortly before the deadline. This phase even had its own name: integration hell. Two people had rebuilt the same spot in different ways, names no longer matched up, nothing worked anymore. Nobody knew which of the thousand changes from the past weeks had caused the problem.

The core idea of CI is simple: the earlier you find a bug, the cheaper it is. If only the changes from the last two hours have been added, the cause is quickly narrowed down. The developer also still has the code fresh in mind. If you go looking after four weeks, though, they first have to familiarize themselves with it again.

For companies, this translates directly into money. A team that integrates constantly can deliver a working version at any time. A team without CI often doesn’t know for weeks whether its program even runs at all. That’s why CI is now standard, from small web projects all the way to software in cars or airplanes.

What happens during the automated run

The written code sits in a shared storage location, the repository. As soon as someone sends their change there, a server springs into action. It downloads the current state of the entire project and builds a runnable program from it. This step is called the build. Already at this point, things fail if two changes contradict each other.

After that, the tests run. These are small check programs that call other parts of the program and compare the result against the expected value. A test might check whether a discount function actually returns 80 euros for 100 euros and 20 percent. Large projects have tens of thousands of such tests, which run through in just a few minutes. If a wrong value comes out anywhere, the run is considered red.

On red, the team is notified immediately, usually via chat or email. The rule in many teams is: a broken build takes priority over everything else. This entire chain of downloading, building, testing, and reporting is called the pipeline. It’s important to distinguish this from Continuous Deployment: CI only checks whether everything fits together. Continuous Deployment additionally sends a version that has passed automatically on to the users.

CI in projects, job postings, and AI development

Anyone looking at a project on GitHub often sees a green checkmark or a red cross next to the changes. That’s the result of the latest CI run. Well-known tools for this are called GitHub Actions, GitLab CI, or Jenkins. They’re usually free for small projects, but noticeable computing costs arise for large companies.

In job postings, the formula CI/CD almost always shows up. It refers to the combination of automatic checking and automatic delivery. The fact that apps on your phone sometimes get weekly updates is practically impossible without this kind of automation.

The principle has also arrived in AI development, there under the name MLOps. In addition to the program code, training data and finished models are also checked automatically. A typical test measures whether a newly trained model still performs at least as well as the previous one on a fixed set of example tasks. A common misconception, by the way, is that CI is simply just a tool. It is above all a work habit: small changes, often, and a team that doesn’t ignore red runs.