Alle Tabs der Lerneinheit (Erklärung · Interaktiv verstehen · Praxis-Übung · Klausur-Quiz) als durchgehender Text. Ideal zum Wiederholen vor der Klausur, und für Suchmaschinen wie Google, Bing und KI-Suche (ChatGPT, Perplexity).
Erklärung
Manuelles Deployment ist 1990er-Software-Entwicklung. Heute pusht jeder Entwickler-Push einer Top-Firma automatisch durch Tests, Build, Staging, Tests, Production. Das ist CI/CD.
Die Idee in einem Satz
CI/CD: Continuous Integration + Continuous Delivery/Deployment, automatisiere alle Schritte von Code-Push bis Production-Release.
CI vs. CD vs. CD
| Akronym | Bedeutung |
|---|---|
| CI | Continuous Integration, bei jedem Push: Build + Tests automatisch |
| CD | Continuous Delivery, Build immer deploy-fähig, manueller Trigger zum Production-Release |
| CD | Continuous Deployment, automatisches Deploy auf Production bei jedem Push |
Continuous Delivery vs. Deployment: Delivery = "kann jederzeit released werden". Deployment = "wird jederzeit released".
Eine typische CI/CD-Pipeline
Push ┌─────┐ ┌──────┐ ┌─────┐ ┌─────────┐ ┌──────────┐
─────→ │ Lint│ → │Tests │ → │Build│ → │ Staging │ → │Production│
└─────┘ └──────┘ └─────┘ └─────────┘ └──────────┘
↓ ↓ ↓ ↓ ↓
(fail) (fail) (fail) (manual (smoke
Stop Stop Stop approval tests +
möglich) rollback)
Die wichtigsten Pipeline-Stages
1. Lint + Format Check
- name: Lint
run: pnpm lint
- name: Type-check
run: pnpm tsc --noEmit
- name: Format-check
run: pnpm format:check
Was? Code-Style + Typen prüfen, schnellste Prüfung.
2. Unit-Tests
- name: Unit-Tests
run: pnpm test:unit
Was? Alle Unit-Tests laufen. Soll < 5 Minuten dauern.
3. Integration-Tests
- name: Integration-Tests
services:
- postgres
run: pnpm test:integration
Was? Tests mit echter DB / Services. ~10-30 Minuten.
4. Build
- name: Build
run: pnpm build
Was? Produktions-Build erzeugen (Bundle, Optimierung). Wenn das fehlschlägt, ist der Code kaputt.
5. Deploy auf Staging
- name: Deploy to Staging
if: github.ref == 'refs/heads/main'
run: ./deploy.sh staging
Was? Auf Test-Umgebung deployen (z.B. staging.app.com).
6. E2E-Tests auf Staging
- name: E2E-Tests
run: pnpm test:e2e --url=staging.app.com
Was? Komplette User-Flows im Browser testen.
7. Deploy auf Production
- name: Deploy to Production
if: needs.staging-tests.result == 'success'
run: ./deploy.sh production
Was? Auf Live-System deployen, automatisch (Continuous Deployment) oder manuell (Continuous Delivery).
8. Smoke-Tests auf Production
- name: Smoke-Tests
run: pnpm test:smoke --url=app.com
Was? Nach Deploy: schnelle Tests, ob die wichtigsten Features funktionieren.
CI/CD-Tools (Übersicht)
| Tool | Stärke |
|---|---|
| GitHub Actions | Standard für GitHub-Projekte, YAML-basiert, einfach |
| GitLab CI | Standard für GitLab, mächtig, integriert |
| Jenkins | Veteran, sehr flexibel, viele Plugins |
| CircleCI | Cloud-Service, schnell |
| Travis CI | War populär, jetzt weniger |
| TeamCity | JetBrains, enterprise |
| ArgoCD | Kubernetes-natives CD |
Beispiel: GitHub Actions Workflow
name: CI/CD Pipeline
on:
push:
branches: [main, develop]
pull_request:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
- run: npm ci
- run: npm run lint
- run: npm test
- run: npm run build
deploy:
needs: test
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
steps:
- run: ./deploy.sh
Vorteile von CI/CD
| Vorteil | Erklärung |
|---|---|
| Schnelles Feedback | Bugs werden sofort entdeckt, nicht erst nach Wochen |
| Konsistente Releases | Immer gleicher Prozess, keine manuellen Fehler |
| Häufige Releases möglich | Tägliche Releases statt monatliche |
| Niedrigere Release-Risiken | Kleine Änderungen statt monatlicher Big-Bang |
| Rollback einfach | Letzten erfolgreichen Build automatisch wieder deployen |
Anti-Patterns
1. Lange Pipelines
Pipeline dauert 2 Stunden → niemand wartet, niemand fixt schnell. Lösung: Parallelisierung, Caching.
2. Manuelle Schritte zurück in die Pipeline
"Vor jedem Deploy bitte mit Florian sprechen." Anti-Pattern. Lösung: Automatisieren oder Schritt aus Pipeline raus.
3. Tests auf Production deaktivieren
"Tests sind eh flaky, lass uns überspringen." → Production geht kaputt. Lösung: Flaky Tests fixen, nicht ignorieren.
4. Secrets im Code
API-Keys, DB-Passwörter im Repo. Lösung: Secrets-Manager (GitHub Secrets, Vault, AWS Secrets Manager).
5. Big-Bang-Deployments
1× pro Monat alles neu. Hohes Risiko. Lösung: Continuous Deployment, kleine Inkremente.
Blue-Green-Deployment + Canary
Strategien für Zero-Downtime-Deploys:
Blue-Green
Blue (alt, läuft) Green (neu, vorbereitet)
● ○
↓ ↓
Nutzer ←── Loadbalancer ──→ (nach Test umschalten)
Neue Version "Green" parallel hoch fahren, testen, dann Loadbalancer umschalten. Falls Bug: zurück zu Blue.
Canary-Release
5 % der Nutzer bekommen neue Version, 95 % alte. Monitoring. Wenn OK: schrittweise auf 100 %.
Production:
v1.0 ──── 95 % der Nutzer
v1.1 ──── 5 % der Nutzer ← Canary
Klausur-Faustregeln
1. CI = Continuous Integration: Bei jedem Push automatisch Build + Tests.
2. CD = Continuous Delivery/Deployment: Auto-Build deploy-fähig (Delivery) oder direkt deploy (Deployment).
3. Typische Pipeline-Stages: Lint → Tests → Build → Staging-Deploy → E2E → Production-Deploy → Smoke-Tests.
4. Tools: GitHub Actions, GitLab CI, Jenkins.
5. Zero-Downtime: Blue-Green oder Canary.
6. Secrets NIE im Code. Immer Secrets-Manager.
Häufige Stolpersteine
1. CI = Tests automatisieren. Stimmt nur teilweise. CI ist mehr: Tests + Build + Style + Integration. Manche denken CI bedeute nur "Tests laufen".
2. CD = Deployment. Falsch, CD ist zweideutig. Continuous Delivery (deploy-bereit) ist nicht Continuous Deployment (immer deployen). Faustregel: meistens ist CD = Continuous Delivery gemeint.
3. Manuelle Schritte in der Pipeline. Wenn Pipeline manuelle Klicks braucht, ist es keine echte CI/CD. Akzeptabel: Production-Deploy mit manuellem Approval bei sensitiven Systemen.
4. Pipeline-Speed nicht beachten. 2-Stunden-Pipeline = niemand wartet, Workflow wird umgangen. Faustregel: max. 15-30 Minuten für die wichtigste Pipeline.
5. CI ist Software-Praxis, nicht Tool. GitHub Actions ist ein Tool, das CI ermöglicht. Aber CI selbst ist die Praxis, alles automatisiert + früh zu integrieren. Tool ohne Praxis = nichts erreicht.
Interaktiv verstehen
CI/CD-Pipeline durchspielen
Sieh, wie ein Code-Push durch die Pipeline läuft, vom Lint bis zum Production-Deploy. Klick durch die Stages.
Interaktive Visualisierung
Interaktive Komponente: probiere sie im Topic-Player oben aus.
Klausur-Tipp: Wenn eine Pipeline gezeichnet werden soll, IMMER Stages benennen: 1) Lint, 2) Unit-Tests, 3) Integration-Tests, 4) Build, 5) Staging-Deploy, 6) E2E, 7) Production-Deploy, 8) Smoke-Tests. Pfeile nach unten, "Fail = Stop" als Hinweis.
Praxis-Übung
CI/CD, Praxis-Übung
6 Aufgaben zu Pipeline-Stages, Tools und Best-Practices.
Klausurfragen mit Lösungen (6)
- F1.Wofür steht CI/CD?
Antwort: Continuous Integration / Continuous Delivery (oder Deployment)
Erklärung: CI = Continuous Integration (kontinuierliche Integration aller Code-Änderungen mit Build + Tests). CD = Continuous Delivery ODER Continuous Deployment (deploy-bereit halten vs. automatisch deployen). Beide Begriffe sind im Use, meistens ist 'Continuous Delivery' gemeint, wenn nicht spezifiziert.
- F2.Was sollte die ERSTE Stage einer typischen Pipeline sein?
Antwort: Lint + Type-Check (schnellste Prüfung)
Erklärung: Lint + Type-Check als erste Stage, sie sind die SCHNELLSTEN (Sekunden). Wenn der Code stilistisch oder typmäßig kaputt ist, kann man sich die teureren Tests sparen. Standard-Reihenfolge nach Schnelligkeit: Lint → Unit → Integration → Build → E2E → Deploy. Schnellste Prüfungen zuerst!
- F3.Ordne die CI/CD-Begriffe ihrer Bedeutung zu.
Zuordnungen:
- Continuous Integration (CI) → Bei jedem Push: Build + Tests automatisch
- Continuous Delivery → Build immer deploy-bereit, manueller Trigger
- Continuous Deployment → Automatisches Deploy auf Production bei jedem Push
- Pipeline → Sequenz automatisierter Stages (Lint→Tests→Build→Deploy)
Erklärung: Die 4 wichtigsten CI/CD-Begriffe: CI (Integration), Continuous Delivery (deploy-bereit), Continuous Deployment (immer deploy), Pipeline (die Stages). Klausur-Klassiker, diese 4 müssen sitzen.
Typ: Zuordnung
- F4.Was ist KEIN typisches CI/CD-Tool?
Antwort: PostgreSQL
Erklärung: PostgreSQL ist eine RELATIONALE DATENBANK, kein CI/CD-Tool. Die anderen 3 sind alle CI/CD-Plattformen: GitHub Actions (mit GitHub integriert), GitLab CI (mit GitLab integriert), Jenkins (Open-Source, sehr alt + flexibel).
- F5.Bei Blue-Green-Deployment laufen alte und neue Version PARALLEL, der Loadbalancer schaltet bei Erfolg um.
Antwort: Wahr
Erklärung: RICHTIG. Blue-Green: 'Blue' ist die aktuelle Production-Version, 'Green' wird parallel mit der neuen Version hochgefahren. Wenn Green stabil läuft, wird der Loadbalancer von Blue auf Green umgeschaltet. Vorteil: Zero Downtime, Rollback super-einfach (LB zurück auf Blue). Alternative: Canary (% der Nutzer bekommen neue Version).
Typ: Wahr/Falsch
- F6.Was ist der HAUPT-Unterschied zwischen Continuous Delivery und Continuous Deployment?
Antwort: Delivery = deploy-bereit + manueller Trigger; Deployment = automatisch deployen
Erklärung: Continuous DELIVERY: Code ist nach Pipeline-Erfolg deploy-BEREIT, aber Deploy auf Production wird MANUELL ausgelöst (z.B. Klick auf Button, Approval). Continuous DEPLOYMENT: Code wird nach Pipeline-Erfolg AUTOMATISCH auf Production deployt, keine manuelle Aktion. Continuous Delivery ist sicherer (Mensch im Loop), Continuous Deployment ist schneller. Wahl je nach Risiko.
Klausur-Quiz
CI/CD, Klausur-Quiz
6 typische Klausurfragen.
Klausurfragen mit Lösungen (6)
- F1.Was passiert, wenn ein Test in der CI-Pipeline fehlschlägt?
Antwort: Die Pipeline stoppt, weiterer Code-Push wird blockiert
Erklärung: Fehlschlagende Tests STOPPEN die Pipeline. Weitere Stages werden nicht ausgeführt, der Build wird als FAILED markiert. PR kann nicht gemerged werden (in den meisten Setups). Dieses 'Fail Fast'-Prinzip ist essentiell, sonst geht kaputter Code auf Production.
- F2.Welches ist ein typisches CI/CD-Tool?
Antwort: GitHub Actions
Erklärung: GitHub Actions ist DAS Standard-CI/CD-Tool für GitHub-Projekte. Die anderen: Docker = Container-Tool, Webpack = Bundler, JIRA = Issue-Tracker. Alle wichtig in der DevOps-Welt, aber nicht CI/CD-Tools im engeren Sinn.
- F3.CI steht für {{1}} Integration, das CD-Akronym kann sowohl Continuous {{2}} (deploy-bereit) als auch Continuous {{3}} (auto-deploy) bedeuten. Bei {{4}}-Green-Deployment laufen alte und neue Version parallel.
Lösungen pro Lücke:
- {{1}}: Continuous / continuous
- {{2}}: Delivery / delivery
- {{3}}: Deployment / deployment
- {{4}}: Blue / blue
Erklärung: CI = Continuous Integration. CD ist zweideutig: Continuous Delivery (deploy-bereit, manuell triggern) vs. Continuous Deployment (auto-deploy). Blue-Green: parallel laufende Versionen, Loadbalancer-Umschalten. Klausur-Klassiker, alle 4 Begriffe sitzen.
Typ: Lückentext
- F4.Bringe die typischen Pipeline-Stages in die richtige Reihenfolge.
Richtige Reihenfolge:
- Lint + Type-Check
- Unit-Tests
- Build (Bundle erzeugen)
- E2E-Tests auf Staging
- Deploy auf Production
- Smoke-Tests auf Production
Erklärung: Standard-Pipeline: 1) Lint+Type (schnellste Prüfung), 2) Unit-Tests, 3) Build, 4) Staging-Deploy + E2E, 5) Production-Deploy, 6) Smoke-Tests. Logik: schnelle Prüfungen zuerst, deploy nur nach allen Tests, Smoke-Tests nach Production-Deploy als letzte Verifikation.
Typ: Reihenfolge
- F5.Was ist ein 'Canary Release'?
Antwort: 5 % der Nutzer bekommen die neue Version, 95 % die alte, schrittweise Erhöhung
Erklärung: Canary Release (Name: 'Kanarienvogel im Bergwerk'): die neue Version wird zuerst nur einem kleinen Teil der Nutzer (z.B. 5 %) ausgespielt. Monitoring prüft, ob alles OK ist. Bei Erfolg: Rollout schrittweise auf 100 %. Bei Problemen: Rollback ohne große Auswirkung. Anders als Blue-Green (alle Nutzer schalten gleichzeitig um).
- F6.Eine Pipeline-Dauer von 2 Stunden ist ideal, das zeigt, dass viele Tests laufen.
Antwort: Falsch
Erklärung: FALSCH. 2 Stunden ist ZU LANG. Niemand wartet so lange, Entwickler springen zwischen Tasks, Bugs werden spät entdeckt. Faustregel: max. 15-30 Minuten für die wichtigste Pipeline. Optimierungen: 1) Parallelisierung (Stages parallel laufen), 2) Caching (Dependencies wiederverwenden), 3) Test-Aufteilung (nur betroffene Tests bei kleinen Changes), 4) E2E-Tests nicht in jedem PR, sondern nightly.
Typ: Wahr/Falsch
