Continuous Integration

An einem größeren Programm arbeiten selten einzelne Personen, sondern ganze Teams. Jeder schreibt an einem anderen Teil, und irgendwann müssen alle Teile wieder zu einem funktionierenden Ganzen zusammengefügt werden. Genau dieses Zusammenfügen heißt Integration. Continuous Integration bedeutet: Man macht das nicht einmal am Ende, sondern ständig, oft mehrmals am Tag. Jedes Mal prüft ein Computer automatisch, ob das Gesamtprogramm danach noch startet und noch das Richtige tut. Der englische Begriff hat sich auch im Deutschen durchgesetzt, abgekürzt als CI.

Warum späte Zusammenführung so teuer wird

Früher war es üblich, monatelang getrennt zu arbeiten und erst kurz vor dem Abgabetermin alles zusammenzuwerfen. Diese Phase hatte einen eigenen Namen: Integrationshölle. Zwei Leute hatten dieselbe Stelle unterschiedlich umgebaut, Namen passten nicht mehr zusammen, nichts lief mehr. Niemand wusste, welche der tausend Änderungen der letzten Wochen das Problem verursacht hatte.

Der Kerngedanke von CI ist einfach: Ein Fehler ist umso billiger, je früher man ihn findet. Wenn nur die Änderungen der letzten zwei Stunden dazugekommen sind, ist die Ursache schnell eingegrenzt. Der Entwickler hat den Code außerdem noch im Kopf. Sucht man dagegen nach vier Wochen, muss er sich erst wieder einlesen.

Für Unternehmen ist das direkt Geld. Ein Team, das ständig integriert, kann jederzeit eine funktionierende Version ausliefern. Ein Team ohne CI weiß oft wochenlang nicht, ob sein Programm überhaupt läuft. Deshalb gehört CI heute zum Standard, von kleinen Web-Projekten bis zu Software in Autos oder Flugzeugen.

Was beim automatischen Durchlauf passiert

Der geschriebene Code liegt in einem gemeinsamen Speicher, dem Repository. Sobald jemand seine Änderung dorthin schickt, springt ein Server an. Er lädt den aktuellen Stand des gesamten Projekts herunter und baut daraus ein lauffähiges Programm. Diesen Schritt nennt man Build. Schon hier scheitert es, wenn zwei Änderungen sich widersprechen.

Danach laufen die Tests. Das sind kleine Prüfprogramme, die andere Programmteile aufrufen und das Ergebnis mit dem erwarteten Wert vergleichen. Ein Test könnte prüfen, ob eine Rabattfunktion bei 100 Euro und 20 Prozent tatsächlich 80 Euro zurückgibt. Große Projekte haben zehntausende solcher Tests, die in wenigen Minuten durchlaufen. Kommt irgendwo ein falscher Wert heraus, gilt der Durchlauf als rot.

Bei Rot bekommt das Team sofort eine Meldung, meist per Chat oder Mail. Die Regel in vielen Teams lautet: Ein kaputter Build hat Vorrang vor allem anderen. Diese ganze Kette aus Herunterladen, Bauen, Testen und Melden heißt Pipeline. Wichtig ist die Abgrenzung zu Continuous Deployment: CI prüft nur, ob alles zusammenpasst. Continuous Deployment schickt eine bestandene Version zusätzlich automatisch zu den Nutzern.

CI in Projekten, Stellenanzeigen und KI-Entwicklung

Wer auf GitHub ein Projekt anschaut, sieht neben Änderungen oft ein grünes Häkchen oder ein rotes Kreuz. Das ist das Ergebnis des letzten CI-Durchlaufs. Bekannte Werkzeuge dafür heißen GitHub Actions, GitLab CI oder Jenkins. Sie kosten für kleine Projekte meist nichts, für große Firmen entstehen spürbare Rechenkosten.

In Stellenanzeigen taucht fast immer die Formel CI/CD auf. Gemeint ist die Kombination aus automatischem Prüfen und automatischem Ausliefern. Dass Apps auf dem Handy manchmal wöchentlich Updates bekommen, ist ohne solche Automatisierung praktisch nicht machbar.

Auch in der KI-Entwicklung ist das Prinzip angekommen, dort unter dem Namen MLOps. Neben dem Programmcode werden zusätzlich Trainingsdaten und fertige Modelle automatisch geprüft. Ein typischer Test misst, ob ein neu trainiertes Modell auf festgelegten Beispielaufgaben noch mindestens so gut abschneidet wie das bisherige. Ein häufiger Irrtum ist übrigens, CI sei einfach nur ein Werkzeug. Es ist vor allem eine Arbeitsgewohnheit: kleine Änderungen, oft, und ein Team, das rote Durchläufe nicht ignoriert.