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).
Teil 1·Erklärung
Diese Lerneinheit wurde für typische Bachelor-Klausuren konzipiert. So prüfen wir · Fehler entdeckt? Melde ihn uns oder markiere die fragliche Stelle direkt im Text oben.
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).
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.
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.
Anmelden, um den Fortschritt zu speichern.
Nächster Schritt
Aktives Abrufen festigt Wissen schneller als nochmal lesen.
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.
CI/CD: Continuous Integration + Continuous Delivery/Deployment — automatisiere alle Schritte von Code-Push bis Production-Release.
| 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".
Push ┌─────┐ ┌──────┐ ┌─────┐ ┌─────────┐ ┌──────────┐
─────→ │ Lint│ → │Tests │ → │Build│ → │ Staging │ → │Production│
└─────┘ └──────┘ └─────┘ └─────────┘ └──────────┘
↓ ↓ ↓ ↓ ↓
(fail) (fail) (fail) (manual (smoke
Stop Stop Stop approval tests +
möglich) rollback)
- 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.
- name: Unit-Tests
run: pnpm test:unit
Was? Alle Unit-Tests laufen. Soll < 5 Minuten dauern.
- name: Integration-Tests
services:
- postgres
run: pnpm test:integration
Was? Tests mit echter DB / Services. ~10-30 Minuten.
- name: Build
run: pnpm build
Was? Produktions-Build erzeugen (Bundle, Optimierung). Wenn das fehlschlägt, ist der Code kaputt.
- name: Deploy to Staging
if: github.ref == 'refs/heads/main'
run: ./deploy.sh staging
Was? Auf Test-Umgebung deployen (z.B. staging.app.com).
- name: E2E-Tests
run: pnpm test:e2e --url=staging.app.com
Was? Komplette User-Flows im Browser testen.
- 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).
- name: Smoke-Tests
run: pnpm test:smoke --url=app.com
Was? Nach Deploy: schnelle Tests, ob die wichtigsten Features funktionieren.
| 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 |
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
| 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 |
Pipeline dauert 2 Stunden → niemand wartet, niemand fixt schnell. Lösung: Parallelisierung, Caching.
"Vor jedem Deploy bitte mit Florian sprechen." Anti-Pattern. Lösung: Automatisieren oder Schritt aus Pipeline raus.
"Tests sind eh flaky, lass uns überspringen." → Production geht kaputt. Lösung: Flaky Tests fixen, nicht ignorieren.
API-Keys, DB-Passwörter im Repo. Lösung: Secrets-Manager (GitHub Secrets, Vault, AWS Secrets Manager).
1× pro Monat alles neu. Hohes Risiko. Lösung: Continuous Deployment, kleine Inkremente.
Strategien für Zero-Downtime-Deploys:
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.
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
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.
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.
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.
6 Aufgaben zu Pipeline-Stages, Tools und Best-Practices.
Klausurfragen mit Lösungen (6)
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.
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!
Zuordnungen:
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
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).
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
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.
6 typische Klausurfragen.
Klausurfragen mit Lösungen (6)
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.
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.
Lösungen pro Lücke:
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
Richtige Reihenfolge:
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
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).
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