Continuous Integration (CI)

Kontinuierliche Integration (CI) bezeichnet das regelmäßige Zusammenführen der Änderungen aller Entwickler in einen gemeinsamen Hauptzweig – mindestens täglich – und das automatische Erstellen und Testen jeder Änderung. So werden Integrationsprobleme innerhalb weniger Minuten statt erst bei der Veröffentlichung sichtbar. Grady Booch schlug den Begriff 1991 vor, Kent Beck machte ihn Ende der 1990er-Jahre zu einer Kernpraxis der Extreme Programming, und Martin Fowlers Artikel Continuous Integration beschreibt den Arbeitsablauf, dem die meisten Teams bis heute folgen. Beim maschinellen Lernen (ML) prüft CI auch Daten, Trainingscode und Modellverhalten, denn eine Änderung kann alle Einheitstests bestehen und dennoch die Genauigkeit eines Modells senken.

So funktioniert eine CI-Pipeline#

Wenn ein Entwickler einen Branch überträgt oder einen Pull Request öffnet, startet ein CI-Dienst wie GitHub Actions, GitLab CI/CD oder Jenkins einen neuen Runner, ruft den Code ab, installiert Abhängigkeiten und führt eine Reihe von Aufträgen aus: Linter und Typprüfungen, Einheitstests, Integrationstests sowie Builds von Paketen oder Container-Images. Jeder Auftrag meldet seinen Status an den Pull Request zurück. Regeln zum Schutz des Branches können das Zusammenführen blockieren, bis alle erforderlichen Prüfungen bestanden sind. Pipelines wiederholen häufig dieselben Tests für verschiedene Betriebssysteme und Python-Versionen und führen nach jedem Zusammenführen die vollständige Testsuite erneut auf dem Hauptzweig aus. Geschwindigkeit gehört zur Praxis: Becks Extreme Programming setzte zehn Minuten als Ziel für den Build des gesamten Systems und die Ausführung aller Tests, denn langsamere Builds werden seltener gestartet.

CI für maschinelles Lernen#

ML-Projekte ergänzen eigene Prüfungen. Datentests bestätigen, dass neue Trainingsdaten dem erwarteten Schema entsprechen, alle Labeldateien korrekt eingelesen werden und kein Bild sowohl im Trainings- als auch im Validierungs-Split auftaucht, was zu Datenlecks führen würde. Ein Schnelltest trainiert eine Epoche lang auf einem winzigen Datensatz, um innerhalb weniger Minuten Fehler bei Tensorformen und Abstürze zu erkennen. Tests zum Modellvergleich legen Zufallsstartwerte fest und erlauben kleine numerische Toleranzen, da GPU-Kernels und die Reihenfolge beim Laden von Daten die Gleitkommaergebnisse von Lauf zu Lauf verändern können. Eine Qualitätsprüfung bewertet das Modell an einem festen Validierungssatz und lässt den Build scheitern, wenn eine Metrik wie der mittlere durchschnittliche Präzisionswert (mAP) unter einen Grenzwert fällt. Exporttests prüfen, ob ONNX- oder TensorRT-Versionen des Modells weiterhin geladen werden und ähnlich wie das Original abschneiden. Vollständiges Training dauert lange, und GPU-Runner sind teuer. Deshalb führen Teams bei jedem Pull Request üblicherweise schnelle Prüfungen aus und überlassen vollständiges Nachtraining und die Modellbereitstellung geplanten Läufen oder Läufen auf dem Hauptzweig. Versionierungswerkzeuge wie DVC ermöglichen es jedem Auftrag, die benötigte exakte Datensatzversion abzurufen.

Der Benchmark-Modus von Ultralytics YOLO eignet sich als solche Qualitätsprüfung: Wenn verbose auf einen Gleitkommawert wie 0.216 gesetzt ist, wird ein Fehler ausgelöst, falls ein Export fehlschlägt oder der mAP_50-95-Wert eines exportierten Formats diesen Grenzwert nicht überschreitet. Die CI des Ultralytics-Repositorys nutzt diesen Modus, um YOLO26-Exporte auf Linux-, macOS- und ARM-Runnern zu testen. Ein minimales GitHub-Actions-Workflow kombiniert Einheitstests mit dieser Prüfung:

name: CI
on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-python@v6
        with:
          python-version: "3.13"
      - run: pip install ultralytics pytest
      - run: pytest tests/
      # Fail if the ONNX export breaks or its mAP50-95 is not above the 0.216 floor
      - run: yolo benchmark model=yolo26n.pt format=onnx imgsz=160 verbose=0.216

Bei jedem Pull Request und jedem Push zu main wird der Auftrag auf einem neuen Ubuntu-Runner ausgeführt. Ein fehlgeschlagener Einheitstest oder ein ONNX-Modell, das auf dem kleinen COCO8-Datensatz höchstens den Grenzwert erreicht, lässt die Prüfung fehlschlagen, bevor die Änderung zusammengeführt werden kann.

CI im Vergleich zu CD, MLOps und kontinuierlichem Training#

• Kontinuierliche Bereitstellung (CD): Übernimmt erfolgreiche CI-Builds und hält sie zur Veröffentlichung bereit, oft indem sie automatisch in einer Staging-Umgebung bereitgestellt werden. Die kontinuierliche Auslieferung geht noch einen Schritt weiter und bringt jede erfolgreiche Änderung in die Produktionsumgebung.
• MLOps: Das umfassendere Fachgebiet, das CI und CD mit Datenversionierung, Modellbereitstellung, Überwachung und erneutem Training über den gesamten ML-Lebenszyklus hinweg verbindet.
• Kontinuierliches Training (CT): Trainiert ein Modell automatisch neu und stellt es erneut bereit, wenn neue Daten eintreffen oder die Überwachung eine Abweichung erkennt. In Googles Reifegradmodell für MLOps liegt automatisches erneutes Training auf Stufe 1 und automatisiertes CI/CD für die Trainingspipeline selbst auf Stufe 2.