--- term: 'CI/CD (Continuous Integration und Delivery)' seoTitle: 'CI/CD: Continuous Integration und Delivery erklärt' headline: 'Was ist CI/CD (Continuous Integration und Delivery)?' slug: ci-cd category: cloud-architecture shortDefinition: 'CI/CD ist eine Praxis, die Build, Tests und Auslieferung von Code automatisiert, sodass jede Änderung in kleinen Schritten in die Produktion gelangt.' relatedTerms: - no-ops-development - containerization - kubernetes - backend-boilerplate-code - cloud-code-serverless-functions contrastsWith: - no-ops-development faq: - question: 'Wofür steht CI/CD?' answer: 'Für Continuous Integration und Continuous Delivery – mit einer eingebauten Mehrdeutigkeit, die jeder Praktiker kennen sollte: Das "CD" kann auch Continuous Deployment heißen. Delivery behält eine menschliche Freigabe vor der Produktion; Deployment schafft sie ab. Sagt jemand "wir machen CI/CD", lautet die nützliche Rückfrage immer: welches CD?' - question: 'Was ist Continuous Integration?' answer: 'Die Praxis, kleine Änderungen häufig in einen gemeinsamen Hauptzweig zusammenzuführen – in der kanonischen Definition mindestens täglich –, wobei jedes Zusammenführen einen automatischen Build- und Testlauf auslöst. Der Zweck ist schnelles Feedback: Integrationsprobleme zeigen sich Minuten nach ihrer Entstehung statt Wochen später im Release-Stress.' - question: 'Was ist der Unterschied zwischen Continuous Delivery und Continuous Deployment?' answer: 'Ein manueller Freigabeschritt. Bei Continuous Delivery wird jede Änderung automatisch gebaut, getestet und releasefähig gehalten, aber ein Mensch entscheidet, wann die Produktion tatsächlich aktualisiert wird. Bei Continuous Deployment gibt es kein Tor: Jede Änderung, die die Pipeline besteht, geht automatisch live, und nur ein fehlgeschlagener Test hält sie auf.' - question: 'Was ist eine CI/CD-Pipeline?' answer: 'Der automatisierte Ablauf, den eine Änderung vom Commit bis in die Produktion durchläuft: Auslöser in der Quellverwaltung, Build, automatisierte Tests, Auslieferung in eine Staging-Umgebung und Deployment. Jede Stufe muss bestehen, bevor die nächste läuft, sodass die Pipeline als Qualitätstor wirkt, das jede Änderung auf dieselbe Weise passiert – keine Sonderfälle, keine Deploy-Heldentaten.' - question: 'Was sind die DORA-Metriken?' answer: 'Der Branchenstandard, um Delivery-Leistung zu messen, aus dem DORA-Forschungsprogramm: Deployment-Frequenz, Vorlaufzeit von Änderungen, Fehlerrate von Änderungen, Wiederherstellungszeit nach einem fehlgeschlagenen Deployment und – zuletzt ergänzt – die Nacharbeitsquote bei Deployments. Der zentrale Befund der Forschung: Tempo und Stabilität sind kein Trade-off, Spitzenteams sind in beidem gut.' - question: 'Ist CI/CD dasselbe wie DevOps?' answer: 'Nein – DevOps ist die breitere Kultur, Entwicklung und Betrieb zusammenzuführen; CI/CD ist deren Automatisierungsrückgrat. Sie können CI/CD-Werkzeuge ohne die Kultur einführen (es hilft weniger als erwartet) und die Kultur ohne die Automatisierung predigen (es verändert weniger als versprochen). Die Praktiken verstärken einander, benennen aber Verschiedenes.' - question: 'Welche Tests laufen in einer CI/CD-Pipeline?' answer: 'Nach Geschwindigkeit geschichtet: Unit-Tests und statische Analyse laufen bei jedem Commit, weil sie schnell sind; Integrationstests prüfen Komponenten gegen echte Abhängigkeiten; End-to-End-, Performance- und Sicherheitsprüfungen laufen in späteren Stufen oder nach Zeitplan, weil sie langsam sind. Die Entwurfsregel: Je schneller das Feedback, desto früher die Stufe.' - question: 'Brauchen kleine Teams CI/CD?' answer: 'Sie brauchen die Praxis mehr als die Installation. Schon ein Zweierteam profitiert von automatisierten Tests bei jeder Änderung und Deployments per einzelnem Befehl – das ist CI/CD dem Wesen nach. Vermeiden sollten kleine Teams den Betrieb schwergewichtiger Pipeline-Infrastruktur; gehostete Runner oder Plattformen mit eingebautem Deployment reduzieren die Praxis auf Konfiguration.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'Continuous Integration — Martin Fowler (updated 2024)' url: 'https://martinfowler.com/articles/continuousIntegration.html' - name: 'Continuous Delivery — Martin Fowler' url: 'https://martinfowler.com/bliki/ContinuousDelivery.html' - name: 'DORA metrics guide (dora.dev)' url: 'https://dora.dev/guides/dora-metrics-four-keys/' - name: 'CI/CD (Wikipedia)' url: 'https://en.wikipedia.org/wiki/CI/CD' cta: title: 'Deployment ohne Pipeline-Installation' text: 'Back4app lässt die Delivery-Hälfte von CI/CD zusammenschrumpfen: Cloud-Code-Funktionen werden mit einem einzigen CLI-Befehl oder direkt aus einem Git-Repository deployt, während Datenbank, Authentifizierung und APIs bereits laufen. Behalten Sie Ihre Tests; sparen Sie sich die Runner-Farm.' linkText: 'Kostenlos starten' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-09-27' translationKey: ci-cd --- **CI/CD ist eine Praxis, die Build, Tests und Auslieferung von Code automatisiert, sodass jede Änderung in kleinen Schritten in die Produktion gelangt.** Der Name verdichtet zwei Ideen – Continuous Integration (ständig zusammenführen und prüfen) und Continuous Delivery (jede Änderung releasefähig halten) – plus eine berühmte Mehrdeutigkeit: Das zweite "D" kann auch Continuous *Deployment* bedeuten, wo nichts außer einem fehlgeschlagenen Test zwischen einem Commit und der Produktion steht. ## Das Wichtigste in Kürze | Frage | Antwort | | --- | --- | | Was es ist | Automatisierung, die aus dem "Release-Tag" ein Nicht-Ereignis macht, das ständig stattfindet | | CI | Kleine Änderungen täglich zusammenführen; jeder Merge baut und testet automatisch | | Die zwei CDs | Delivery behält eine menschliche Freigabe vor der Produktion; Deployment schafft sie ab | | Warum es wirkt | Kleine Änderungen scheitern klein; schnelles Feedback findet Fehler Minuten nach ihrer Entstehung | | Wie es gemessen wird | Die fünf DORA-Metriken – und Tempo und Stabilität steigen gemeinsam | ## Wie eine Pipeline tatsächlich aussieht Die ganze Praxis passt in eine Konfigurationsdatei – das Artefakt, das jede Seite "CI/CD erklärt" beschreibt und fast keine zeigt: ```yaml # pipeline.yml — die Automatisierung, die den "Deploy-Tag" ersetzt on: push to main jobs: build: steps: - checkout - run: npm ci && npm run build test: needs: build steps: - run: npm test # Unit + Integration, bei jedem Commit - run: npm run lint # statische Analyse deploy: needs: test approval: manual # diese Zeile löschen → Continuous Deployment steps: - run: npm run deploy ``` Minuten nachdem dieser letzte Schritt gelaufen ist, rufen alle Clients bereits die neue Backend-Version auf – und genau darum geht es: **JavaScript:** ```javascript // JavaScript / Node.js — Back4app JS SDK // Seconds after `b4a deploy`, every client is calling the new version const version = await Parse.Cloud.run('version'); console.log(`API version: ${version}`); // no pipeline YAML, no runners ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK final function = ParseCloudFunction('version'); final response = await function.execute(); if (response.success) { print('API version: ${response.result}'); // fresh from the deploy } ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK ParseCloud.callFunction("version") { result in if case .success(let version) = result { print("API version: \(version)") // fresh from the deploy } } ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK ParseCloud.callFunctionInBackground("version", hashMapOf()) { version, e -> if (e == null) Log.d("API", "version: $version") // fresh from the deploy } ``` ## CI vs. Continuous Delivery vs. Continuous Deployment | Dimension | Continuous Integration | Continuous Delivery | Continuous Deployment | | --- | --- | --- | --- | | Umfang | Merge + Build + Tests | … plus stets releasefähige Artefakte | … plus automatisches Release | | Auslöser | Jeder Commit auf den Hauptzweig | Jeder erfolgreiche Build | Jeder erfolgreiche Build | | Menschliches Tor | Keines (die Tests sind das Tor) | **Ja – eine Release-Freigabe** | **Keines** | | Produktion wird aktualisiert | Wenn jemand ein Release macht | Wenn jemand klickt | Fortlaufend | | Passt am besten zu | Allen | Regulierten Releases, marketinggetakteten Launches | Web-Backends, SaaS, hochverlässlichen Testsuiten | ```mermaid flowchart LR accTitle: Eine CI/CD-Pipeline accDescr: Commits lösen automatisierte Build- und Teststufen aus; bestandene Änderungen erreichen Staging und passieren dann entweder ein manuelles Freigabetor bei Continuous Delivery oder gar kein Tor bei Continuous Deployment auf dem Weg in die Produktion. A[Commit] --> B[Build] --> C[Automatisierte Tests] --> D[Staging] D --> E{Manuelle Freigabe?} E -- "ja – Continuous Delivery" --> F[Produktion] E -- "kein Tor – Continuous Deployment" --> F ``` Die Herkunft ist einen Satz wert: [Martin Fowlers kanonischer Artikel](https://martinfowler.com/articles/continuousIntegration.html) definierte CI im Jahr 2000, das Buch *Continuous Delivery* von 2010 dehnte sie auf den Release-Prozess aus, und DevOps machte das Paar zu seinem Automatisierungsrückgrat. Eine scharfe Kante von Fowler schneidet bis heute: Einen Build-Server gegen langlebige Feature-Branches laufen zu lassen, ist "Halb-Integration" – echtes CI heißt, dass der Hauptzweig die Arbeit aller mindestens täglich integriert. ## Die Pipeline, Stufe für Stufe - **Quelle.** Ein Commit oder Merge löst alles aus. Niemals manuelle Builds – was nicht ausgelöst wird, ist kein CI. - **Build.** Kompilieren, Abhängigkeiten auflösen, das Artefakt erzeugen (Bundle, Container-Image), das jede spätere Stufe wiederverwendet – einmal bauen, überall weiterreichen. - **Test.** Schnelle Prüfungen zuerst: Unit-Tests und Linting bei jedem Commit; danach Integrationstests gegen echte Abhängigkeiten; End-to-End-, Performance- und Sicherheitsprüfungen in späteren oder geplanten Läufen. Die Feedback-Geschwindigkeit bestimmt die Reihenfolge der Stufen. - **Ausliefern.** Das Artefakt landet in einer produktionsnahen Staging-Umgebung. Bei Continuous Delivery wartet es dort – releasefähig – auf ein menschliches Ja. - **Deployen.** Produktion. Ausgereifte Pipelines deployen schrittweise – ein Canary-Anteil oder eine parallele Blue-Green-Umgebung –, damit eine schlechte Änderung ein eingegrenzter Rollback bleibt und kein Ausfall wird. ## Die Messung: die DORA-Metriken "Sind wir gut in der Auslieferung?" hat eine Standardantwort: die [fünf Metriken des DORA-Forschungsprogramms](https://dora.dev/guides/dora-metrics-four-keys/) – Deployment-Frequenz, Vorlaufzeit von Änderungen, Fehlerrate von Änderungen, Wiederherstellungszeit nach einem fehlgeschlagenen Deployment und Nacharbeitsquote bei Deployments. Der meistzitierte Befund der Forschung lautet, dass der klassische Trade-off zwischen Tempo und Stabilität nicht existiert: Teams, die am häufigsten deployen, verursachen auch die wenigsten Defekte, weil kleine häufige Änderungen einzeln risikoarm und schnell zu diagnostizieren sind. Bewegt Ihre Pipeline-Arbeit keine der fünf Zahlen, ist sie Installation, kein Fortschritt. ## Typische Anwendungsfälle - **Web- und API-Backends** – die natürliche Heimat von vollem Continuous Deployment: hohes Änderungsvolumen, sofortiger Rollback, kein Installationsschritt. - **Mobile Apps** – CI plus Continuous *Delivery*: Pipelines bauen, testen und stagen jede Änderung, während die Store-Prüfung den letzten Schritt ohnehin mit einem Tor versieht. - **Teams, die über eine deployende Person hinauswachsen** – die Pipeline ersetzt den einen Menschen, der "weiß, wie man released", durch einen Prozess, den jeder ausführen kann. - **Regulierte Umgebungen** – das Freigabetor wird zum Feature: volle Automatisierung bis zur Linie, eine prüfbare menschliche Entscheidung an ihr. - **Open-Source-Projekte** – jeder automatisch gebaute und getestete Pull Request ist CI als Eingangstür des Projekts. ## Sollten Sie die Produktion mit einem Tor sichern? Eine Entscheidungsmatrix | Wählen Sie Continuous Deployment, wenn … | Behalten Sie das Delivery-Tor, wenn … | | --- | --- | | Die Testsuite der Produktion gewachsen ist | Die Testabdeckung erst in dieses Vertrauen hineinwächst | | Ein Rollback ein einzelner Befehl ist | Ein Rollback ein Projekt ist | | Nutzer unsichtbare, ständige Updates erwarten | Releases auf Marketing- oder Vertragstermine fallen | | Das Produkt ein Web-Backend oder SaaS ist | Das Produkt über eine App-Store-Prüfung ausgeliefert wird | | Ausfälle hinter Feature Flags glimpflich verlaufen | Ein schlechtes Release regulatorische Folgen hat | Die ehrliche Reihenfolge: Verdienen Sie sich Deployment, indem Sie Delivery praktizieren – automatisieren Sie alles bis zum Tor, beobachten Sie die Fehlerrate und entfernen Sie das Tor dann, wenn es ohnehin nichts mehr tut. ## Grenzen und Trade-offs - **Die Pipeline ist Code, der Ihnen gehört.** Runner, YAML, Caches, Secrets – alles will gepflegt werden, und ab einer gewissen Teamgröße wird die Pipeline ein eigenes Produkt mit eigener Rufbereitschaft. - **Instabile Tests vergiften alles.** Eine Suite, die zufällig fehlschlägt, erzieht Menschen dazu, auf "erneut versuchen" zu klicken – und verwandelt Continuous Deployment still zurück in manuelles Deployment mit Zusatzschritten. - **Kultur ist Voraussetzung, nicht Nebenprodukt.** Kleine Merges, Entwicklung am Hauptzweig und rote Builds sofort reparieren sind Gewohnheiten; eine gekaufte Pipeline installiert sie nicht mit. - **Tempo ohne Observability ist Glücksspiel.** Ständiges Deployen ist nur sicher, wenn Sie Fehler schnell sehen – Monitoring und Alarmierung gehören zur Praxis, sie sind kein Zubehör. - **Die letzte Meile ist unterschiedlich.** Datenbanken, Migrationen und zustandsbehaftete Dienste widersetzen sich dem "einfach neu deployen"; die Pipeline braucht Strategien (Expand-Contract-Migrationen, Feature Flags), die kein YAML für Sie schreibt. ## CI/CD mit Back4app Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Die Wirkung der Plattform auf CI/CD ist Subtraktion auf der Delivery-Seite: Cloud Code wird mit einem einzigen CLI-Befehl oder direkt aus einem Git-Repository deployt, und das Standard-Backend – Datenbank, Authentifizierung, APIs – taucht in Ihrer Pipeline überhaupt nicht auf, weil es dort nichts zu bauen oder zu releasen gibt. Übrig bleibt die Hälfte, die Sie behalten sollten: Ihre Tests, bei jedem Commit ausgeführt, vor einem Deploy-Schritt, der jetzt eine Zeile lang ist.