--- title: "Was ist CI/CD? Continuous Integration und Deployment einfach erklärt" description: "Was ist CI/CD? Ich erkläre Continuous Integration und Continuous Deployment verständlich mit Praxis-Beispielen. Pipeline-Aufbau, GitHub Actions und warum CI/CD dein Projekt besser macht." canonical_url: "https://robocitrus.com/blog/was-ist-ci-cd" last_updated: "2026-07-19T00:13:39.875Z" --- Du pushst Code, und ein paar Minuten später ist das Update live in der App. Kein manuelles Hochladen, kein "Moment, ich muss noch schnell deployen". Das ist CI/CD -- und wenn du einmal damit gearbeitet hast, willst du nie wieder zurück. Ich erinnere mich noch an die Zeiten, als ich Builds manuell erstellt und per Hand auf den Server geschoben habe. Freitagabend, 23 Uhr, ein Fix muss raus. Heute drücke ich auf "Merge" und der Rest passiert automatisch. --- ## Kurz zusammengefasst - **CI (Continuous Integration):** Jeder Code-Commit wird automatisch gebaut und getestet - **CD (Continuous Deployment):** Erfolgreich getesteter Code wird automatisch ausgeliefert - Eine CI/CD-Pipeline besteht aus den Stufen Build, Test und Deploy - Beliebte Tools: GitHub Actions, GitLab CI, Codemagic (für Flutter), Bitrise - CI/CD spart Zeit, fängt Bugs früh ab und gibt dir Vertrauen beim Deployen --- ## Die Fabrik-Analogie Stell dir eine Autofabrik vor. Jede Station am Fließband hat eine Aufgabe: Karosserie schweißen, Motor einbauen, Lack auftragen, Qualitätskontrolle. Wenn bei der Qualitätskontrolle ein Fehler auffällt, wird das Auto zurückgeschickt -- bevor es beim Kunden landet. CI/CD funktioniert genauso. Dein Code durchläuft automatisch mehrere Stationen (Build, Test, Deploy). Jede Station prüft, ob alles in Ordnung ist. Nur wenn alle Stationen grünes Licht geben, landet das Update beim Nutzer. Ohne Fließband? Dann baust du jedes Auto von Hand. Mal vergisst du die Qualitätskontrolle, mal landest du mit einem Kratzer beim Kunden. Genau so fühlt sich Softwareentwicklung ohne CI/CD an. ## Was ist Continuous Integration (CI)? Continuous Integration bedeutet: **Jedes Mal, wenn du Code in dein Repository pushst, wird er automatisch gebaut und getestet.** Kein manuelles "npm run build", kein "hoffentlich geht der Test noch durch". Das passiert bei CI: 1. Du pushst deinen Code (z.B. in einen Feature-Branch auf [GitHub](/blog/was-ist-git)) 2. Ein Server (der CI-Server) erkennt den neuen Code 3. Er baut das Projekt automatisch 4. Er führt alle Tests aus 5. Du bekommst Feedback: grün (alles gut) oder rot (etwas ist kaputt) **Der Clou:** Das passiert bei **jedem einzelnen Commit**. Nicht erst am Ende des Sprints, nicht erst vor dem Release. Sofort. Damit fängst du Fehler in dem Moment, wo sie entstehen -- nicht drei Wochen später, wenn niemand mehr weiß, was der Code eigentlich tun sollte. Das ist wie ein Rechtschreibprüfungs-Tool, das jedes Wort prüft, während du tippst. Statt erst am Ende den ganzen Text durchzugehen und 47 Fehler auf einmal zu finden. ## Was ist Continuous Deployment (CD)? Continuous Deployment geht einen Schritt weiter: **Code, der alle Tests bestanden hat, wird automatisch ausgeliefert.** Je nach Setup entweder auf eine Staging-Umgebung (zum Testen) oder direkt in die Produktion. Es gibt zwei Varianten: - **Continuous Delivery:** Der Code wird automatisch bis zur Staging-Umgebung gebracht. Das Deployment in die Produktion passiert dann per Knopfdruck (manueller Schritt). - **Continuous Deployment:** Alles ist automatisch. Grüne Tests = Code geht live. Kein manueller Schritt. Welche Variante du wählst, hängt von deinem Projekt ab. Für eine kritische Banking-App willst du wahrscheinlich Continuous Delivery (mit manuellem Freigabe-Schritt). Für eine interne Tool-App reicht Continuous Deployment vollkommen aus. ## Die CI/CD-Pipeline: Vom Commit zum Live-Update Eine CI/CD-Pipeline ist die Abfolge von Schritten, die dein Code automatisch durchläuft. Die typischen Stufen: ### 1. Build Der Code wird kompiliert und zu einem lauffähigen Artefakt gebaut. Bei einer Flutter-App heißt das: APK oder IPA erstellen. Bei einer Web-App: Assets bundeln, TypeScript kompilieren, Dependencies installieren. ### 2. Test Automatisierte Tests laufen. Das können sein: - **Unit Tests:** Einzelne Funktionen testen - **Integration Tests:** Zusammenspiel von Komponenten testen - **UI Tests:** Die App wird simuliert gestartet und durchgeklickt Wenn hier ein Test fehlschlägt, stoppt die Pipeline. Kein Deploy mit kaputtem Code. ### 3. Deploy Wenn Build und Tests grün sind, wird der Code ausgeliefert. Das kann bedeuten: - Upload in den App Store / Play Store - Deployment auf einen Server - [Code Push Update](/blog/code-push-updates-ohne-app-store) direkt an die Nutzer Der gesamte Prozess läuft automatisch. Du pushst Code, gehst Kaffee holen, und wenn du zurückkommst, ist das Update live (oder du hast eine Fehlermeldung im Postfach). ## Beliebte CI/CD-Tools Es gibt dutzende CI/CD-Tools. Hier die, die ich regelmäßig nutze: **GitHub Actions:** Direkt in GitHub integriert, kostenlos für Open-Source-Projekte. Mein Go-to für die meisten Projekte. Workflows werden als YAML-Dateien definiert. **GitLab CI:** Ähnlich wie GitHub Actions, aber in GitLab integriert. Besonders beliebt bei Teams, die GitLab als Plattform nutzen. **Codemagic:** Speziell für Flutter und mobile Apps. Übernimmt das komplette Build- und Signing für iOS und Android. Wenn du Flutter-Apps baust, ist Codemagic Gold wert. **Bitrise:** Ebenfalls auf Mobile spezialisiert. Gute Integration mit den App Stores und vielen Testing-Services. ## Praxis-Beispiel: GitHub Actions für eine Flutter-App Damit das Ganze nicht abstrakt bleibt, hier ein echtes Beispiel. Diese GitHub Actions Workflow-Datei baut eine Flutter-App, führt Tests aus und erstellt ein APK: ```yaml name: Flutter CI on: push: branches: [main] pull_request: branches: [main] jobs: build-and-test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Setup Flutter uses: subosito/flutter-action@v2 with: flutter-version: '3.27.0' channel: 'stable' - name: Install dependencies run: flutter pub get - name: Run tests run: flutter test - name: Build APK run: flutter build apk --release - name: Upload APK uses: actions/upload-artifact@v4 with: name: release-apk path: build/app/outputs/flutter-apk/app-release.apk ``` Was passiert hier? 1. Bei jedem Push auf `main` oder bei einem Pull Request startet der Workflow 2. Flutter wird installiert 3. Dependencies werden geladen 4. Alle Tests laufen 5. Ein Release-APK wird gebaut 6. Das APK wird als Artefakt gespeichert (zum Download) Das alles passiert automatisch. Kein manuelles Bauen, kein "Welche Flutter-Version hatte ich nochmal?". Jeder Build ist reproduzierbar. ## Warum CI/CD dein Projekt besser macht Ich habe Projekte mit und ohne CI/CD erlebt. Der Unterschied ist enorm: **Bugs früh finden:** Wenn Tests bei jedem Commit laufen, findest du Fehler sofort. Nicht erst, wenn ein Nutzer sich beschwert. Je früher du einen Bug findest, desto günstiger ist er zu fixen. **Vertrauen beim Deployen:** Freitag-Nachmittag deployen? Mit CI/CD kein Problem. Die Pipeline hat alles getestet, du weißt, dass der Code funktioniert. Ohne CI/CD ist Freitags-Deploy ein Glücksspiel. **Zeit sparen:** Manuelles Bauen, Testen und Deployen frisst Stunden pro Woche. CI/CD erledigt das in Minuten, während du an Features arbeitest. **Konsistenz:** Jeder Build läuft in der gleichen Umgebung. Kein "bei mir funktioniert's" mehr. Der CI-Server ist die Single Source of Truth. **Team-Zusammenarbeit:** Wenn mehrere Entwickler an einem Projekt arbeiten, sorgt CI dafür, dass niemand versehentlich den Code der anderen kaputt macht. Pull Requests werden automatisch getestet, bevor sie gemerged werden. ## CI/CD und Mobile Apps Für Mobile Apps hat CI/CD noch einen besonderen Vorteil: **Code Signing.** Das Signieren von iOS- und Android-Apps ist notorisch nervig. Zertifikate, Provisioning Profiles, Keystores -- ein Albtraum, wenn du es manuell machst. Tools wie Codemagic oder GitHub Actions mit [Fastlane](https://fastlane.tools) übernehmen das automatisch. Du richtest es einmal ein, und ab dann wird jeder Build korrekt signiert. Keine "Signing failed"-Fehler mehr um 23 Uhr. Und wenn du wirklich schnell iterieren willst, kombinierst du CI/CD mit [Code Push Updates](/blog/code-push-updates-ohne-app-store). Pipeline baut den Patch, Shorebird liefert ihn direkt an die Nutzer. Ohne App Store Review. ## Fazit CI/CD klingt erstmal nach DevOps-Magie, ist aber im Kern simpel: Automatisiere alles, was du nicht manuell machen musst. Bauen, Testen, Deployen -- lass das Maschinen erledigen, damit du dich auf den Code konzentrieren kannst. Der Einstieg ist einfacher als du denkst. Erstelle eine GitHub Actions Workflow-Datei, definiere Build und Test, und schon hast du eine CI-Pipeline. Von dort aus kannst du schrittweise erweitern: Deployment, Code Signing, Notifications. Wenn du [Git](/blog/was-ist-git) beherrschst, ist CI/CD der logische nächste Schritt. Und ich verspreche dir: Nach der ersten grünen Pipeline willst du nie wieder manuell deployen. ## Häufig gestellte Fragen Ja, gerade für kleine Projekte ist CI/CD schnell eingerichtet und spart sofort Zeit. Selbst wenn du alleine arbeitest, fängt eine CI-Pipeline Fehler ab, die du beim manuellen Testen übersehen hättest. GitHub Actions ist für öffentliche Repositories kostenlos und in 10 Minuten eingerichtet. GitHub Actions bietet 2.000 Minuten pro Monat kostenlos (für private Repos). Für die meisten kleinen bis mittleren Projekte reicht das. Codemagic hat einen kostenlosen Tier mit 500 Build-Minuten pro Monat. Erst bei großen Teams oder vielen Builds pro Tag entstehen nennenswerte Kosten. Absolut. Du brauchst das Projekt nicht umstrukturieren. Erstelle einfach eine Workflow-Datei (bei GitHub Actions unter `.github/workflows/`), definiere die Build- und Test-Schritte, und committe sie. Ab dem nächsten Push läuft die Pipeline automatisch. Voraussetzung sind allerdings vorhandene Tests -- ohne Tests hat CI wenig Mehrwert.