Sofortantwort
CI/CD einfach erklärt
Automatisierte Prozesse für kontinuierliche Software-Entwicklung.
- Kurz gesagt
- CI: Automatisches Testen und Bauen bei jeder Code-Änderung
- Typischer Einsatz
- Web-Deployment, ML-Pipelines, Qualitätssicherung
- Wichtig zu wissen
- Reduziert Fehler, beschleunigt Releases und erhöht die Codequalität
Continuous Integration / Continuous Deployment im Überblick
CI/CD (Continuous Integration / Continuous Deployment) ist die Praxis, Software-Änderungen automatisch zu testen und in Produktion zu bringen. Jeder Commit löst eine Pipeline aus: Tests laufen automatisch, und wenn alles grün ist, wird die neue Version deployed – ohne manuelle Eingriffe. Für KI-Projekte bedeutet das: Auch Modell-Updates, Daten-Pipelines und Prompt-Änderungen werden automatisch getestet und ausgerollt. ML-CI/CD erweitert klassisches CI/CD um Modell-Evaluation: Ein neues Modell wird nur deployed, wenn es auf dem Holdout-Testset besser ist als das aktuelle Produktionsmodell. Tools wie GitHub Actions, GitLab CI und Jenkins bilden die Basis, ergänzt durch MLflow oder W&B für Modell-Tracking.
CI/CD automatisiert den Weg von einer Code-Änderung bis zur Produktion.
Die Pipeline:
Code Push → Build → Test → (Review) → Deploy → Monitor
CI ─────────────────┘ CD ──────────────────┘
Typische CI/CD-Pipeline:
| Schritt | Was passiert | Bei Fehler |
|---|---|---|
| Lint | Code-Stil prüfen | Pipeline stoppt |
| Unit Tests | Einzelne Funktionen testen | Pipeline stoppt |
| Build | Anwendung bauen | Pipeline stoppt |
| Integration Tests | Zusammenspiel testen | Pipeline stoppt |
| Deploy Staging | Auf Testumgebung deployen | Pipeline stoppt |
| Deploy Production | Live schalten | Rollback |
Technisch betrachtet
GitHub Actions Beispiel
name: CI/CD
on: [push]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm install
- run: npm test
deploy:
needs: test
runs-on: ubuntu-latest
steps:
- run: npm run build
- run: npm run deploy
CI/CD für ML (CT - Continuous Training)
- Data Validation: Neue Daten auf Schema und Qualität prüfen
- Model Training: Automatisches Training bei neuen Daten
- Model Evaluation: Performance gegen Baseline vergleichen
- Model Registry: Neue Version registrieren
- Deployment: Bei besserer Performance automatisch deployen
Schritt für Schritt
Änderungen sicher bis zum Betrieb führen
Eine Pipeline ersetzt keine Verantwortung, sie macht Qualitätsprüfungen und Freigaben wiederholbar und sichtbar.
Änderung integrieren
Integration
Eine nachvollziehbare Änderung wird mit der gemeinsamen Codebasis zusammengeführt und löst die vereinbarten Prüfungen aus.
aenderung -> versionierte pipelineQualität automatisiert prüfen
Prüfung
Build, Tests und passende Sicherheits- oder Datenprüfungen verhindern, dass bekannte Fehler weiterlaufen.
build + tests + checks -> kandidatVersion freigeben
Freigabe
Erfolgreiche Ergebnisse ergeben eine eindeutig identifizierbare Version, die bei Bedarf noch menschlich freigegeben wird.
gepruefter kandidat -> releaseKontrolliert ausrollen
Release
Die Version wird bereitgestellt, beobachtet und kann bei unerwarteter Wirkung auf einen stabilen Stand zurückgesetzt werden.
release -> rollout -> monitoring oder rollback
Konkretes Beispiel
Eine Prompt-Änderung kontrolliert ausliefern
Ein Team verbessert den System-Prompt einer produktiven Assistenzfunktion.
Direkt in Produktion ändern
Die Wirkung wird erst nach dem Ausrollen sichtbar. Bei Problemen fehlt ein klarer geprüfter vorheriger Stand.
Änderung durch die Pipeline führen
Tests und festgelegte Beispielausgaben prüfen die Änderung. Eine versionierte Freigabe wird schrittweise ausgerollt und beobachtet.
CI/CD verkürzt nicht nur Lieferzeit, sondern verbessert die Rückverfolgbarkeit jeder produktiven Änderung.
Einordnung
Vorteile und Grenzen
Das spricht dafür
- Wiederholbare Qualität: Gleiche Prüfungen gelten für jede Änderung statt nur bei einzelnen manuellen Releases.
- Schnelleres Feedback: Fehler werden früh sichtbar, wenn ihr Kontext und die Korrektur noch klein sind.
- Nachvollziehbare Versionen: Build, Tests und Auslieferung lassen sich auf eine konkrete Änderung zurückführen.
- Sicherere Releases: Automatisierung ermöglicht kleine, häufige und kontrollierbare Schritte.
Das solltest du beachten
- Pipelines brauchen Pflege: Tests, Abhängigkeiten und Laufzeiten müssen dauerhaft sinnvoll gehalten werden.
- Grün ist nicht automatisch gut: Automatisierte Checks erfassen nur Kriterien, die bewusst definiert wurden.
- Fehlende Testabdeckung bleibt Risiko: Ungetestete Integrationen oder Fachfälle können trotz Pipeline ausfallen.
- Zugangsdaten brauchen Schutz: Build- und Deployment-Systeme benötigen eigene minimal berechtigte Identitäten.
Vertiefung · für FortgeschritteneDer Weg einer Änderung
Die Pipeline verbindet eine Änderung mit den Nachweisen, die für eine kontrollierte Auslieferung nötig sind.
automatisierte Integrations- und Lieferkette