Aufgaben Software Deployment
Die finale Lektion von K56: 10 IHK-typische Aufgaben zu Software Deployment. Themen decken alle vorherigen Lektionen ab – von Grundbegriffen über Strategien, Paketformate, Windows/Linux-Verteilung, Environments bis hin zu Rollback. Manche sind Wissensfragen, manche Praxis-Szenarien.
Deployment-Themen kommen in IHK-Prüfungen besonders im FISI-Bereich häufig vor (Software-Verteilung in Unternehmen), aber auch FIAE bekommen Fragen zu Strategien und Rollback. Versuch jede Aufgabe erst selbst, bevor du die Lösung aufklappst.
1) Cheat-Sheet zur Vorbereitung
Hier die wichtigsten Begriffe aus K56 als kompakte Übersicht. Falls einer davon unklar ist, geh in die entsprechende Lektion zurück:
Software-Deployment-Cheat-Sheet
Grundbegriffe
Deployment
Software auf Zielsystem bringen
Release
Software für Nutzer verfügbar machen
Installation
Software auf einzelnem Gerät einrichten
Rollback
Rückkehr zu vorheriger Version
Forward Fix
Hotfix statt Rollback
MTTR
Mean Time to Recovery
Deployment-Strategien
Big Bang
Alle Server gleichzeitig, Downtime
Rolling Update
Server für Server, K8s-Standard
Blue-Green
Zwei Umgebungen, schneller Switch
Canary
Schrittweise Traffic-Verlagerung
Feature Flag
Code deployed, Feature schaltbar
A/B Test
Geschäftliche Variante (nicht technisch)
Paketformate
MSI
Windows klassisch, msiexec
MSIX
Windows modern, Container-isoliert
DEB
Debian/Ubuntu, dpkg/apt
RPM
RHEL/Fedora/SUSE, rpm/dnf/zypper
Snap/Flatpak
Universelle Linux-Formate
AppImage
Standalone-Executable Linux
Tools
WSUS
Microsoft Windows Update Server
Intune
Microsoft Cloud-Endpoint-Mgmt
PDQ Deploy
Drittanbieter Windows, einfach
SCCM/MECM
Microsoft Enterprise-Lösung
Ansible
Configuration Management
Terraform
Infrastructure as Code
Umgebungen
Dev
Entwicklungsumgebung
Test
CI-Tests, automatisiert
Staging
Prod-ähnlich, UAT
Production
Live, echte Nutzer
12-Factor App
Methodik für Cloud-native Apps
Promotion
Code wandert durch Stufen
Diese Übersicht ist ein guter Startpunkt für die Klausur-Vorbereitung. Die Aufgaben unten setzen das Wissen voraus.
2) Aufgabe 1: Deployment vs. Release vs. Installation
Klassische Einstiegsfrage. Die drei Begriffe werden oft verwechselt – die Unterscheidung ist Pflichtwissen.
AUFGABE #1
EASY
Erkläre die Begriffe Deployment, Release und Installation. Was unterscheidet sie? Gib ein Beispiel.
✓ Lösung
Definitionen:
- Deployment: Software wird auf das Zielsystem gebracht. Dateien liegen bereit, Dienst kann gestartet werden – aber für Nutzer noch nicht aktiv.
- Release: Software wird für Nutzer verfügbar gemacht. Routing auf neue Version, Feature-Flag aktivieren. Oft Geschäftsentscheidung.
- Installation: Software wird auf einem einzelnen Endgerät eingerichtet – meist von einem Benutzer oder Admin.
Mehr in L1 Was ist Deployment?
3) Aufgabe 2: Deployment-Strategien benennen
Eine typische Wissensabfrage. Du sollst die vier Hauptstrategien erklären können. Das wird in Bewerbungsgesprächen sehr oft gefragt.
AUFGABE #2
EASY
Nenne die vier wichtigsten Deployment-Strategien und erkläre kurz wie sie funktionieren. Welche ist für ein hochkritisches System mit Zero-Downtime-Anforderung am besten geeignet?
✓ Lösung
Die vier Strategien:
- Big Bang: Alle Server gleichzeitig umgestellt. Einfach, aber mit Downtime. Geeignet für kleine Setups oder Wartungsfenster.
- Rolling Update: Server werden nacheinander umgestellt. Keine Downtime, zwei Versionen laufen kurz parallel. Kubernetes-Default.
- Blue-Green Deployment: Zwei komplette Umgebungen. Neue Version auf „Green" deployen, dann Load-Balancer-Switch. Sofortiger Rollback möglich.
- Canary Release: Neue Version bekommt erst kleinen Traffic-Anteil (5%). Bei Erfolg ausweiten (25%, 50%, 100%). Minimales Risiko.
Mehr in L2 Deployment-Strategien.
4) Aufgabe 3: Paketformate zuordnen
Eine Wissensfrage zu Paketformaten und ihren Tools. Du musst wissen, was für welches Betriebssystem gilt.
AUFGABE #3
EASY
Ordne die folgenden Paketformate den passenden Betriebssystemen und Tools zu: MSI, MSIX, DEB, RPM. Welches Tool nutzt man jeweils für die Installation?
✓ Lösung
| Format | OS | Tools |
|---|---|---|
| MSI | Windows (klassisch) | msiexec /i setup.msi |
| MSIX | Windows 10+ (modern) | PowerShell Add-AppPackage, Microsoft Store |
| DEB | Debian, Ubuntu, Mint | dpkg -i / apt install |
| RPM | RHEL, Fedora, CentOS, SUSE | rpm -i / dnf install / zypper in |
dpkg und rpm sind low-level (installieren das Paket direkt, ohne Dependencies aufzulösen). apt, dnf und zypper sind die höhere Ebene mit automatischer Dependency-Auflösung aus Online-Repositories.Mehr in L3 Pakete.
5) Aufgabe 4: Windows-Verteilungs-Tools wählen
Ein Praxis-Szenario. In Klausuren oft als „Du bist Admin..."-Aufgabe formuliert. Hier musst du die richtigen Tools auswählen können.
AUFGABE #4
MEDIUM
Du bist Admin in einem Unternehmen mit 800 Windows-Arbeitsplätzen. Es soll eine neue Version von Adobe Acrobat auf alle Geräte ausgerollt werden. Welche Tools stehen dir zur Verfügung, welches würdest du wählen und warum? Was bedeutet „Detection Rule" in diesem Kontext?
✓ Lösung
Verfügbare Tools:
- WSUS: primär für Windows-Updates, nicht ideal für Drittanbieter-Software
- Intune: Cloud-basiert, modern, ideal für moderne Umgebungen
- PDQ Deploy: speziell für Software-Verteilung, einfach, beliebt im Mittelstand
- SCCM/MECM: Microsoft Enterprise-Lösung, mächtig aber komplex
- Group Policy (GPO): klassisch, nur MSI-Pakete, älter
- PowerShell-Skripte: ad-hoc-Lösung, kein Reporting
Vorgehen:
- Adobe Acrobat als MSI-Paket besorgen (oder Intunewin-Format für Intune)
- Test-Gruppe definieren (~10-20 Geräte)
- Ausrollen mit Silent Install (
/quiet /norestart) - Reporting prüfen, dann breit ausrollen
C:\Program Files\Adobe\Acrobat\acrobat.exe), Datei-Version (>= 24.0), Registry-Key, MSI Product Code (GUID). Detection Rules implementieren das Prinzip der Idempotenz – mehrfaches Ausrollen ist sicher.Mehr in L4 Windows-Verteilung.
6) Aufgabe 5: Linux-Befehle
Eine praktische Aufgabe. Du sollst die Befehle der wichtigsten Linux-Paketmanager kennen.
AUFGABE #5
MEDIUM
Schreibe für jeden der folgenden Befehle das Äquivalent in den anderen Paketmanagern: apt (Ubuntu), dnf (Fedora), zypper (SUSE). Befehle: (a) Nginx installieren, (b) alle Pakete updaten, (c) ein Paket suchen, (d) Paket entfernen.
✓ Lösung
| Aktion | apt | dnf | zypper |
|---|---|---|---|
| Nginx installieren | apt install nginx | dnf install nginx | zypper install nginx |
| Alle Pakete updaten | apt update && apt upgrade |
dnf upgrade | zypper refresh && zypper update |
| Paket suchen | apt search docker | dnf search docker | zypper search docker |
| Paket entfernen | apt remove nginx | dnf remove nginx | zypper remove nginx |
apt update (Listen aktualisieren) und apt upgrade (Pakete aktualisieren). Bei dnf macht dnf upgrade beides automatisch. Klassische Verwechslung im Anfänger-Bereich.Mehr in L5 Linux-Verteilung.
7) Aufgabe 6: Umgebungen begründen
Eine konzeptionelle Frage. Du musst erklären können warum mehrere Umgebungen sinnvoll sind und was sie unterscheidet.
AUFGABE #6
MEDIUM
Ein Praktikant fragt dich: „Warum brauchen wir denn Dev, Test, Staging UND Production? Können wir nicht direkt von der Entwicklung auf Production deployen?" Erkläre die vier Umgebungen und warum die Trennung wichtig ist. Was bedeutet „Promotion"?
✓ Lösung
Die vier Umgebungen:
- DEV (Development): Entwicklungsumgebung, lokal oder auf geteilten Dev-Servern. Entwickler können kaputte Stände haben, experimentieren. Test-Daten, niemals Echt-Daten.
- TEST: Automatisierte Tests laufen hier durch (CI). Kontrollierte Test-Daten. Oft pro Build neu aufgesetzt.
- STAGING: Production-ähnliche Umgebung. Letzter Stopp vor Live. Sollte Production möglichst genau widerspiegeln. UAT (User Acceptance Tests).
- PROD (Production): Live-System mit echten Nutzern, echten Daten. Alle Änderungen sind kritisch.
- Sicherheit für Production: Bugs sollen nicht bei echten Kunden landen
- Realistische Tests: Lokale Dev-Umgebung simuliert nicht alles
- Isolation: Entwickler-Experimente beeinflussen nicht Tester oder Kunden
- Lasttests: Performance prüfen ohne echte Nutzer zu beeinträchtigen
- Abnahme: Stakeholder können Features testen vor Release
- Compliance: DSGVO – echte Daten dürfen nicht überall sein
Mehr in L8 Umgebungen.
8) Aufgabe 7: Rollback-Szenario
Eine Praxisaufgabe zum Krisenmanagement. Du musst eine Entscheidung treffen und begründen.
AUFGABE #7
HARD
Du hast gerade Version v3.0 deiner Webanwendung auf Production deployed. Die Version enthält eine Datenbank-Migration, die eine Spalte
user.address in zwei neue Spalten user.street und user.city aufgesplittet hat. Nach 20 Minuten meldet das Monitoring: 30% Error-Rate, viele Nutzer können sich nicht einloggen. Was tust du? Begründe deine Entscheidung.✓ Lösung
Erste Analyse: Wir haben eine DB-Migration durchgeführt, die nicht rückwärtskompatibel ist. Die alte Spalte address wurde aufgesplittet und vermutlich entfernt. Klassisches Problem.Optionen:
- Sofortiger Rollback: ❌ Schwierig! Wenn wir auf v2.x zurückrollen, fehlt der Code die
street/city-Spalten kennt. Aber: wenn die alteaddress-Spalte gelöscht wurde, hat v2 auch keine Daten dort. Datenverlust droht. - Forward Fix: ✓ Wahrscheinlich besser. Wir verstehen das Problem vermutlich (Login funktioniert nicht → wahrscheinlich Adress-Code defekt). Schneller Hotfix möglich.
- DB-Rollback aus Backup: ⚠ Letzter Ausweg. Datenverlust aller in den letzten 20 Min eingetragenen User.
Was hätte man besser machen sollen:
- Expand-and-Contract-Pattern: Erst neue Spalten hinzufügen, beide Versionen können arbeiten. Dann Daten migrieren. App auf neue Spalten umstellen. Erst nach Tagen Stabilität alte Spalte entfernen.
- So wäre Rollback jederzeit trivial gewesen – die alte
address-Spalte wäre noch da. - Canary-Deploy: nur 5% Traffic zur neuen Version → 30% Errors wären sofort bei 5% sichtbar geworden, ohne dass alle User betroffen sind.
8) Aufgabe 8: 12-Factor App
Eine moderne Software-Engineering-Frage. Wird in DevOps-Bewerbungsgesprächen oft abgefragt.
AUFGABE #8
HARD
Was ist die „Twelve-Factor App"? Nenne mindestens 3 der Faktoren und erkläre, warum diese Methodik für moderne Software-Deployment wichtig ist.
✓ Lösung
Twelve-Factor App: Methodik, die 2011 von Heroku-Mitgründer Adam Wiggins veröffentlicht wurde. 12 Best Practices für Cloud-native Apps. Ziel: Software so bauen, dass sie portabel, skalierbar und deploybar ist.Wichtige Faktoren (Auswahl):
- I. Codebase: Eine Codebase, in Versionsverwaltung (Git). Mehrere Deployments aus derselben Codebase.
- II. Dependencies: Abhängigkeiten explizit deklarieren (package.json, requirements.txt). Keine impliziten System-Libraries.
- III. Config: Konfiguration in Umgebungsvariablen, nicht im Code. Gleicher Code, andere Configs pro Umgebung.
- IV. Backing Services: Datenbanken, Caches als „Attached Resources" behandeln. Per URL austauschbar.
- V. Build, Release, Run: Drei strikt getrennte Phasen. Build erstellt Artefakt, Release kombiniert mit Config, Run startet.
- VI. Processes: App läuft als zustandslose Prozesse. State in Backing Services.
- X. Dev/Prod Parity: Dev und Prod ähnlich halten. Gleiche Versionen, gleiche Tools.
- XI. Logs: App schreibt Logs als Stream nach stdout. Umgebung entscheidet was damit passiert.
- Portabilität: gleiche App läuft auf Heroku, AWS, Kubernetes – ohne Code-Änderung
- Skalierbarkeit: zustandslose Prozesse können einfach repliziert werden
- Dev/Prod-Konsistenz: weniger „bei mir lief's"-Probleme
- Konfig-Management: Env-Variablen pro Umgebung sind Standard
- CI/CD-freundlich: klare Trennung Build/Release/Run
9) Aufgabe 9: Strategien-Vergleich
Eine vergleichende Aufgabe. Du musst Eigenschaften der Strategien gegenüberstellen können.
AUFGABE #9
HARD
Vergleiche Blue-Green Deployment und Canary Release hinsichtlich: (a) Infrastruktur-Kosten, (b) Rollback-Speed, (c) Risiko bei Bugs, (d) Komplexität. Wann würdest du jeweils welches wählen?
✓ Lösung
| Aspekt | Blue-Green | Canary |
|---|---|---|
| Infrastruktur-Kosten | Hoch (2× komplette Umgebung parallel) | Mittel (nur kleiner Teil der Infra zusätzlich) |
| Rollback-Speed | Sofort (Load-Balancer-Switch) | Sofort (Traffic auf 0% setzen) |
| Risiko bei Bugs | Hoch wenn schon geswitcht (alle User betroffen) | Niedrig (nur Anteil der User betroffen) |
| Komplexität | Mittel (Load Balancer, parallele Umgebungen) | Hoch (Traffic-Splitting, Monitoring, Routing) |
| Deploy-Dauer | Schnell (alles auf Green, dann Switch) | Lang (Tage bis vollständig ausgerollt) |
| Test-Möglichkeit | Volltest auf Green vor Switch möglich | Echtes Production-Feedback unter Last |
- Blue-Green wenn: Budget für 2× Infra vorhanden, kritisches System mit Anforderung an sofortigen Rollback (Banking, E-Commerce), Volltest vor Switch wichtig
- Canary wenn: Sehr große User-Mengen wo schon 5% statistisch aussagekräftig sind (Netflix, Spotify, Facebook), Risiko minimieren ist oberste Priorität, Performance-Verhalten unter echter Last entscheidend
Mehr in L2 Strategien.
10) Aufgabe 10: Praxis-Szenario komplett
Die finale Aufgabe – ein realistisches Szenario das alle Aspekte abprüft. Könnte als Hauptaufgabe in einer Abschlussklausur stehen.
AUFGABE #10
HARD
Du bist als FISI in einem E-Commerce-Unternehmen (300 Mitarbeiter, eigener Webshop mit 100.000 täglichen Besuchern) verantwortlich für das Software-Deployment der Webanwendung. Beschreibe ein modernes Deployment-Setup: welche Umgebungen, welche Strategie, welche Tools, welche Sicherheitsmaßnahmen?
✓ Lösung
Umgebungen:
- DEV: Lokal auf Entwickler-Laptops mit Docker Compose
- TEST: Automatisierte CI-Tests pro Pull Request (ephemere Container-Umgebung)
- Preview Environments: Pro PR eigene URL für Reviewer (z.B.
pr-1234.preview.shop.de) - STAGING: Production-ähnliche Umgebung mit anonymisierter Daten-Kopie
- PRODUCTION: Cluster mit mehreren App-Servern, Load Balancer, Replicated DB
Tool-Stack:
- Source Control: GitLab oder GitHub mit Branch-Protection
- CI/CD: GitHub Actions oder GitLab CI für Pipelines
- Container-Registry: GitHub Container Registry oder Harbor
- Orchestrierung: Kubernetes mit Helm Charts
- IaC: Terraform für AWS/Azure-Infrastruktur
- Configuration Management: Ansible für Server-Setup
- Secrets-Management: HashiCorp Vault oder AWS Secrets Manager
- Feature Flags: LaunchDarkly oder Unleash
- Monitoring: Prometheus + Grafana, Sentry für Error-Tracking
- Logging: ELK-Stack oder Loki
- Auto-Rollback: Argo Rollouts oder Flagger
- Developer pusht Feature-Branch, eröffnet PR
- CI baut Docker-Image, läuft Tests, deployt automatisch in Preview-Umgebung
- Code-Review, QA-Tests in Preview-Umgebung
- Merge nach
main→ automatisches Deploy nach Staging - Smoke-Tests in Staging, ggf. Product Owner Approval
- Production-Deploy als Canary: 5% → 25% → 50% → 100% mit Monitoring
- Bei Problemen: Auto-Rollback durch Argo Rollouts
- Nach erfolgreichem Deploy: Slack-Benachrichtigung, Postmortem bei Incidents
- Secrets nicht in Git: Vault oder Secret-Manager nutzen
- Branch-Protection: main nur via PR änderbar, Reviews zwingend
- Image-Scanning: Trivy/Snyk für CVE-Scan der Docker-Images
- SAST/DAST: SonarQube, OWASP ZAP in Pipeline
- DSGVO: Daten in Staging anonymisiert (siehe K05)
- Multi-Region-Backup: für Disaster Recovery (siehe K58)
- HTTPS überall: auch intern zwischen Services
- Rate-Limiting: gegen DDoS
- Penetration-Tests: regelmäßig vor Major Releases
- Audit-Logs: wer hat wann was deployed
Disaster Recovery: Multi-Region-Setup mit automatischem Failover. RTO < 1h, RPO < 15 Min.
Diese Aufgabe verbindet quasi den ganzen Kurs – wenn du das alles sauber beantworten kannst, hast du K56 gemeistert.
11) Begriffs-Tabelle
Übersicht aller wichtigen Begriffe mit Lektions-Verweis:
| Begriff | Bedeutung | Lektion |
|---|---|---|
| Deployment / Release / Installation | Drei verwandte aber unterschiedliche Konzepte | L1 |
| Big Bang | Alle Server gleichzeitig, mit Downtime | L2 |
| Rolling Update | Server für Server, kein Downtime | L2 |
| Blue-Green | Zwei Umgebungen, Load-Balancer-Switch | L2 |
| Canary | Schrittweise Traffic-Verlagerung | L2 |
| Feature Flag | Code deployed, Feature schaltbar | L2 |
| MSI / MSIX | Windows-Paketformate (klassisch/modern) | L3 |
| DEB / RPM | Linux-Paketformate (Debian/Red-Hat) | L3 |
| Snap / Flatpak / AppImage | Universelle Linux-Formate | L3 |
| WSUS | Microsoft Windows Update Server | L4 |
| Intune | Microsoft Cloud-Endpoint-Management | L4 |
| PDQ Deploy | Drittanbieter-Tool für Windows | L4 |
| Group Policy | Klassische AD-basierte Verteilung | L4 |
| Detection Rule | Prüft ob Software schon installiert ist | L4 |
| apt / dnf / zypper | Linux-Paketmanager der drei Familien | L5 |
| Repository | Server-Sammlung von Paketen | L5 |
| Unattended Upgrades | Automatische Sicherheits-Patches | L5 |
| Ansible | Configuration Management Tool | L6 |
| Infrastructure as Code | Infra als Code-Datei beschreiben | L7 |
| Terraform | Marktführer IaC, multi-cloud | L7 |
| Dev / Test / Staging / Prod | Die vier klassischen Umgebungen | L8 |
| Promotion | Code wandert durch Umgebungen | L8 |
| 12-Factor App | Best-Practices-Methodik für Cloud-Apps | L8 |
| Rollback | Zurück zur vorherigen Version | L9 |
| Forward Fix | Hotfix statt Rollback | L9 |
| Expand-and-Contract | Pattern für sichere DB-Migrationen | L9 |
| MTTR | Mean Time to Recovery | L9 |
12) Prüfungs-Tipps
Prüfungs-Checkliste Software Deployment
- Deployment vs. Release vs. Installation: Unterschiede sicher beherrschen
- Die 4 Strategien: Big Bang, Rolling, Blue-Green, Canary – mit Vor- und Nachteilen
- Paketformate: MSI/MSIX (Windows), DEB/RPM (Linux), Snap/Flatpak/AppImage
- Windows-Tools: WSUS, Intune, PDQ, SCCM – wann was?
- Linux-Paketmanager: apt/dnf/zypper Befehle
- Umgebungen: Dev/Test/Staging/Prod und Promotion
- 12-Factor App: zumindest 3-4 Faktoren kennen
- Konfiguration: Env-Variablen, niemals Secrets in Git
- Rollback: Strategien, DB-Problem, Expand-and-Contract
- IaC und Ansible: zumindest die Konzepte (Vertiefung in K55)
13) Wie geht's weiter?
Mit K56 hast du die Deployment-Grundlagen gemeistert. Was du als nächstes vertiefen kannst:
- CI/CD vertiefen: K55 – Pipelines, GitHub Actions, Jenkins, Ansible-Playbooks, Terraform
- Docker und Container: K32 – wichtige Grundlage für moderne Deployments
- Kubernetes: Container-Orchestrierung im großen Stil
- Cloud Computing: K31 – AWS, Azure, GCP
- DevOps-Grundlagen: K53 – die Kultur hinter den Tools
- Hochverfügbarkeit & Disaster Recovery: K59
- Backup-Strategien: K58
- Eigene Pipeline bauen: bestes Lernmittel ist Praxis. Eigenes Projekt mit Deployment-Pipeline ausstatten.
Zusammenfassung
10 IHK-typische Aufgaben zu Software Deployment durchgegangen: von EASY (Definitionen, Strategien benennen) bis HARD (Rollback-Szenario, Praxis-Setup, 12-Factor). Wichtigste Lehren: Begriffe sauber trennen – Deployment, Release, Installation. Vier Strategien mit Trade-offs verstehen: Big Bang (einfach, Downtime), Rolling (K8s-Standard), Blue-Green (schneller Rollback), Canary (minimales Risiko). Paketformate nach OS zuordnen: MSI/MSIX/DEB/RPM. Windows-Tools: WSUS klassisch, Intune modern, PDQ einfach. Linux-Paketmanager: apt/dnf/zypper Befehle. Mehrere Umgebungen (Dev/Test/Staging/Prod) mit Promotion. 12-Factor App für moderne Cloud-Apps. Rollback-Strategien mit DB-Migration als Hauptproblem (Expand-and-Contract). Realistisches Praxis-Setup mit allen Komponenten skizzieren können. Übung schlägt Theorie – eigene Deployment-Pipeline bauen ist der beste Weg.