Was ist CI/CD? Kontinuierliche Integration und Auslieferung einfach erklärt

CI/CD ist eine Art, Software auszuliefern, bei der jede Code-Änderung automatisch gebaut und getestet wird und – wenn sie besteht – für die Veröffentlichung vorbereitet oder veröffentlicht wird. CI (Continuous Integration) bedeutet, dass Änderungen oft zusammengeführt und bei jedem Mal durch automatisierte Tests geprüft werden. CD (Continuous Delivery oder Deployment) bedeutet, dass die bestandenen Änderungen verpackt und mit wenig oder keiner manuellen Arbeit zu Ihren Nutzern geschoben werden.

Der Sinn ist einfach: Fehler innerhalb von Minuten nach ihrer Entstehung finden, nicht Wochen später, wenn ein Kunde sie entdeckt.

Warum CI/CD wichtig ist, wenn Sie mit KI bauen

KI-Builder ändern Code schnell. Eine einzige Anweisung kann zehn Dateien betreffen. Das ist großartig, bis eine Änderung an der Kasse still die Login-Seite kaputt macht und niemand es merkt, bis ein Nutzer Ihnen eine E-Mail schreibt.

Genau dafür ist CI/CD das Sicherheitsnetz. Statt darauf zu vertrauen, dass jede Änderung in Ordnung ist, führt eine Pipeline jedes Mal dieselben Prüfungen aus:

• Baut die App noch ohne Fehler?
• Bestehen die automatisierten Tests noch?
• Hält der Code die Regeln des Projekts ein (Typen, Formatierung, Sicherheitsprüfungen)?

Schlägt eine Prüfung fehl, wird die Änderung gestoppt, bevor sie Nutzer erreicht. Je schneller sich Ihr Code ändert, desto wertvoller ist eine Prüfung, die nie müde wird und nie einen Schritt auslässt.

Ein Alltagsvergleich

Stellen Sie sich eine Bäckerei vor, die jeden Morgen Brot an Läden verkauft.

• Ohne CI/CD arbeitet jeder Bäcker eine Woche lang an eigenen Rezeptänderungen, dann werden sie am Freitagabend alle zusammengeführt, und man hofft, dass das Brot noch aufgeht. Wenn nicht, weiß niemand, wessen Änderung schuld war.
• Mit CI wird jede kleine Rezeptänderung sofort in einem Probebrot gebacken und geprüft – Geschmack, Gewicht, Form. Eine schlechte Änderung wird noch am selben Tag entdeckt, und man weiß genau, welche es war.
• Mit CD gehen Brote, die die Kontrolle bestehen, direkt auf den Lieferwagen, verpackt und beschriftet immer gleich, statt dass morgens um fünf jemand Kartons von Hand packt.

Die Kontrolle macht die Bäcker nicht besser. Sie macht ihre Fehler billig.

So funktioniert eine CI/CD-Pipeline

Eine Pipeline ist eine Liste von Schritten, die ein CI/CD-Dienst automatisch ausführt, wenn etwas passiert – meist wenn jemand Code in ein Repository wie GitHub hochlädt. Eine typische Pipeline sieht so aus:

Jeder Schritt läuft auf einer sauberen Maschine, nicht auf dem Laptop von jemandem, sodass „bei mir funktioniert es“ keine Ausrede mehr ist. Schlägt ein Schritt fehl, stoppt die Pipeline und meldet es der Person, die die Änderung gemacht hat.

Die Schritte sind in einer Konfigurationsdatei definiert, die im Code liegt. In GitHub Actions ist das zum Beispiel eine YAML-Datei im Ordner .github/workflows des Repositorys.

Continuous Delivery vs. Continuous Deployment

Das „CD“ ist mehrdeutig, und Menschen verwenden es in beide Richtungen:

Continuous Deployment funktioniert nur gut, wenn die Tests gut sind. Deckt Ihr Test den Bezahlvorgang nicht ab, wird Continuous Deployment fröhlich einen kaputten Bezahlvorgang ausliefern.

Ein praktisches Beispiel: eine Buchungs-App mit Pipeline

Angenommen, Sie haben eine Buchungs-App für einen Friseursalon, deren Code in einem GitHub-Repository liegt. Sie bitten einen KI-Builder: „Füge einen Rabatt von 10 % für Erstkunden hinzu.“

1. Die Änderung wird auf einen neuen Branch hochgeladen, und ein Pull Request wird eröffnet.
2. Die Pipeline startet. Sie installiert Pakete und baut die App – das besteht.
3. Sie führt die Tests aus. Ein Test, „ein wiederkehrender Kunde zahlt vollen Preis“, schlägt fehl: Der Rabatt wird allen gewährt.
4. Der Pull Request zeigt ein rotes Kreuz. Die Änderung kann nicht zusammengeführt werden.
5. Sie bitten die KI, es zu beheben. Sie lädt eine Korrektur hoch; die Pipeline läuft erneut und alles besteht.
6. Die Änderung wird zusammengeführt. Die Pipeline veröffentlicht sie auf einer Staging-Umgebung, wo Sie eine Testbuchung machen.
7. Sie geben frei, und sie geht auf die Produktion.

Ohne die Pipeline wäre Schritt 3 mit dem Geld Ihrer Kunden passiert.

Wichtige Begriffe

Häufige Missverständnisse

• „CI/CD heißt, meine App ist getestet.“ Eine Pipeline führt nur die Tests aus, die Sie haben. Gibt es keine Tests, beweist CI nur, dass die App baut – mehr nicht. Bitten Sie Ihre KI, Tests für die wichtigsten Abläufe zu schreiben.
• „CI/CD ist nur für große Unternehmen.“ Gehostete Werkzeuge wie GitHub Actions brauchen eine kurze Konfigurationsdatei und werden von kleinen Teams ständig genutzt. Der Aufwand liegt in den Tests, nicht im Werkzeug.
• „Automatische Veröffentlichung heißt, niemand prüft etwas.“ Gute Pipelines fügen Prüfungen hinzu, statt sie zu entfernen. Viele Teams behalten einen menschlichen Freigabeschritt vor der Produktion.
• „Wenn die Pipeline grün ist, funktioniert die App.“ Das heißt nur, dass die automatisierten Prüfungen bestanden wurden. Sie sollten die Änderung trotzdem selbst ausprobieren, am besten in einer Vorschau oder auf Staging.
• „CI/CD ersetzt Backups.“ Tut es nicht. Eine fehlerhafte Datenbankmigration, die die Tests besteht, kann echte Daten trotzdem beschädigen. Behalten Sie Backups und einen Weg zum Zurückrollen.

Was Sie Ihren KI-App-Builder fragen sollten

• „Schreibe automatisierte Tests für Registrierung, Login und Bezahlvorgang und zeige mir, wie ich sie ausführe.“
• „Richte einen GitHub-Actions-Workflow ein, der bei jedem Pull Request die Abhängigkeiten installiert, die App baut und die Tests ausführt.“
• „Füge der Pipeline eine Typprüfung und einen Linter hinzu und lass sie bei Fehlern scheitern.“
• „Erkläre in einfacher Sprache, was jeder Schritt der Pipeline macht.“
• „Was passiert, wenn ein Deployment halb durchläuft? Wie rolle ich zurück?“
• „Prüfe, dass keine Geheimnisse im Repository fest eingetragen oder in den Pipeline-Logs ausgegeben werden.“

Wenn Ihre App API-Schlüssel nutzt, braucht die Pipeline sie auch – verschlüsselt als Geheimnisse im CI-Werkzeug gespeichert, nie in der Konfigurationsdatei. Siehe Umgebungsvariablen und Geheimnisse.

CI/CD und Mythex

Mythex betreibt keine CI-Pipeline für Sie, deckt aber einige der gleichen Bedürfnisse auf eigene Weise ab:

• Checkpoints. Nach jedem erfolgreichen Schritt des Agenten speichert Mythex einen Git-Checkpoint, und Zu diesem Punkt zurückkehren setzt das Projekt zurück, wenn eine Änderung schiefgelaufen ist. Siehe Chat.
• App-Tests. Tippen Sie /test, und der Agent klickt sich wie ein Nutzer durch Ihre Live-Vorschau und meldet kaputte Abläufe – nützlich vor jeder Veröffentlichung. Siehe App-Tests.
• Veröffentlichen ist ein bewusster Schritt. Änderungen erscheinen zuerst in der privaten Vorschau; Ihre öffentliche App aktualisiert sich erst, wenn Sie erneut veröffentlichen – eher Continuous Delivery als Continuous Deployment.
• GitHub-Synchronisierung (Pro). Synchronisieren Sie das Projekt mit einem GitHub-Repository, und Sie können eigene GitHub-Actions-Workflows hinzufügen, die bei jedem Push Tests ausführen. Siehe GitHub und Export.

Eine Checkliste, was Sie vor dem Livegang von Hand testen sollten, finden Sie unter So testen Sie Ihre App vor dem Start, und zur Arbeit mit Versionskontrolle So nutzen Sie Git mit einer KI-gebauten App.

Fragen