Home

02 Quiz: Automation und CI/CD

October 2025 (2378 Words, 14 Minutes)

exercises quiz chapter-02 ci-cd github-actions automation

Kapitel 02 Quiz: Automation und CI/CD

Anleitung

Dieses Quiz testet dein Verständnis der Kernkonzepte aus Kapitel 02 (Feature-Entwicklung)
Jede Frage hat 4 Optionen mit genau einer korrekten Antwort
Versuche zu antworten, ohne die Vorlesungsmaterialien zu Rate zu ziehen
Konzentriere dich auf das Verständnis von Konzepten, nicht auf das Auswendiglernen von Details

Frage 1: Das Kernproblem, das CI/CD löst

Welches grundlegende Problem adressiert Continuous Integration (CI) in der Softwareentwicklung?

A) Es lässt Code schneller laufen, indem es die Kompilierung optimiert
B) Es verhindert “funktioniert auf meiner Maschine”-Probleme durch Testen von Code in einer standardisierten Umgebung
C) Es schreibt automatisch Dokumentation für deinen Code
D) Es reduziert die Kosten für Cloud-Hosting durch die Nutzung weniger Server

Antwort anzeigen

Richtige Antwort: B

CI adressiert das klassische “Integration Hell”-Problem, bei dem Code auf individuellen Entwicklermaschinen einwandfrei funktioniert, aber beim Zusammenführen fehlschlägt. Durch automatisches Testen jeder Änderung in einer sauberen, standardisierten Umgebung erkennt CI Integrationsprobleme Minuten nach ihrer Einführung und nicht erst Tage oder Wochen später. Optionen A, C und D beschreiben unzusammenhängende Vorteile oder sind einfach nicht das, wofür CI konzipiert ist.

Frage 2: Continuous Delivery vs. Continuous Deployment verstehen

Was ist der wesentliche Unterschied zwischen Continuous Delivery und Continuous Deployment?

A) Continuous Delivery ist schneller als Continuous Deployment
B) Continuous Deployment erfordert manuelle Genehmigung vor der Produktion, Continuous Delivery ist vollautomatisiert
C) Continuous Delivery bereitet Code für das Deployment mit manueller Genehmigung vor, Continuous Deployment deployed automatisch in die Produktion
D) Sie sind dasselbe mit unterschiedlichen Namen

Antwort anzeigen

Richtige Antwort: C

Continuous Delivery bereitet Code automatisch für das Deployment vor, erfordert aber eine manuelle Genehmigung vor der Freigabe in die Produktion (üblich in Unternehmen), während Continuous Deployment noch weiter geht, indem es jede Änderung, die alle Tests besteht, automatisch direkt in die Produktion deployed, ohne manuelle Intervention. Option B hat es vertauscht, und Optionen A und D sind falsche Charakterisierungen dieser Praktiken.

Frage 3: GitHub Actions Workflow-Struktur

Welche Beziehung besteht in einem GitHub Actions Workflow zwischen Workflows, Jobs und Steps?

A) Workflows enthalten mehrere Jobs, die mehrere Steps enthalten
B) Jobs enthalten mehrere Workflows, die mehrere Steps enthalten
C) Steps enthalten mehrere Jobs, die mehrere Workflows enthalten
D) Sie sind alle unabhängige Komponenten, die getrennt laufen

Antwort anzeigen

Richtige Antwort: A

Ein Workflow ist der oberste automatisierte Prozess, der in einer YAML-Datei definiert ist. Jeder Workflow enthält einen oder mehrere Jobs, und jeder Job enthält einen oder mehrere Steps. Diese hierarchische Struktur ermöglicht es dir, komplexe Automation-Pipelines zu organisieren. Jobs laufen standardmäßig parallel (es sei denn, du spezifizierst Abhängigkeiten), und Steps innerhalb eines Jobs laufen sequenziell.

Frage 4: Action-Versionen wählen

Warum wird empfohlen, Major-Version-Tags (wie @v4) anstelle von exakten Versions-Tags (wie @v4.1.1) für GitHub Actions zu verwenden?

A) Major-Version-Tags lassen Workflows schneller laufen
B) Exakte Versionen sind veraltet und funktionieren nicht mehr
C) Major-Version-Tags erhalten automatisch Sicherheits-Patches und nicht-brechende Updates
D) Major-Version-Tags verwenden weniger Festplattenspeicher

Antwort anzeigen

Richtige Antwort: C

Die Verwendung von Major-Version-Tags (z.B. @v4) bedeutet, dass du automatisch Sicherheits-Patches, Bugfixes und neue Features innerhalb dieser Major-Version erhältst, ohne manuelle Updates. Die Major-Version wird keine brechenden Änderungen einführen (dafür gibt es Major-Version-Inkremente), sodass du die Vorteile der laufenden Wartung erhältst und gleichzeitig Stabilität bewahrst. Dies ist dem Festlegen auf exakte Versionen überlegen, die manuelle Updates für jeden Patch erfordern.

Frage 5: Action-Qualität bewerten

Welches der folgenden ist der stärkste Indikator dafür, dass eine GitHub Action vertrauenswürdig und gut gepflegt ist?

A) Sie hat ein buntes Logo und professionell aussehende Dokumentation
B) Sie wird von einem verifizierten Ersteller (wie GitHub, Docker oder AWS) veröffentlicht, mit aktuellen Updates und aktiver Issue-Verwaltung
C) Sie hat die meisten Sterne auf GitHub
D) Sie hat die kürzeste Code-Implementierung

Antwort anzeigen

Richtige Antwort: B

Verifizierte Ersteller mit blauen Häkchen (besonders offizielle Organisationen wie actions/*, docker/*, aws-actions/*) in Kombination mit aktuellen Updates und aktiver Wartung sind die stärksten Qualitätsindikatoren. Während Sterne (Option C) nützlich sind, können sie aufgebläht sein und garantieren keine aktuelle Wartung. Hübsche Dokumentation (A) und kurzer Code (D) sagen nichts über Sicherheit, Zuverlässigkeit oder laufende Unterstützung aus.

Frage 6: Der Zweck von Pre-commit Hooks

Was ist der Hauptvorteil der Verwendung von Pre-commit Hooks im Vergleich zur ausschließlichen Durchführung von Checks in CI/CD?

A) Pre-commit Hooks sind gründlicher als CI-Checks
B) Pre-commit Hooks erkennen Probleme sofort vor dem Commit, bieten sofortiges Feedback und sparen CI-Minuten
C) Pre-commit Hooks funktionieren ohne Internetverbindung zu GitHub
D) Pre-commit Hooks beheben automatisch alle Code-Probleme ohne Entwicklereingriff

Antwort anzeigen

Richtige Antwort: B

Der Hauptvorteil von Pre-commit Hooks ist die Geschwindigkeit des Feedbacks. Anstatt zu committen, zu pushen und 2+ Minuten zu warten, bis CI fehlschlägt, erkennen Pre-commit Hooks Probleme in Sekunden, bevor der Commit überhaupt passiert. Dies spart Zeit, spart CI-Minuten und verhindert, dass fehlerhafter Code das Repository erreicht. Während Option C technisch wahr ist, ist es nicht der Hauptvorteil. Optionen A und D sind falsch - Pre-commit Hooks führen die gleichen Checks wie CI aus (nicht gründlicher) und blockieren typischerweise Commits, anstatt alles automatisch zu beheben.

Frage 7: GitHub Actions Workflow-Trigger

Wann würdest du den workflow_dispatch-Trigger in einem GitHub Actions Workflow verwenden?

A) Um den Workflow automatisch auszuführen, wenn Code gepusht wird
B) Um eine manuelle Auslösung des Workflows aus der GitHub-UI zu ermöglichen
C) Um den Workflow auf geplanter Basis (wie täglich oder wöchentlich) auszuführen
D) Um den Workflow auszulösen, wenn Issues geöffnet werden

Antwort anzeigen

Richtige Antwort: B

Der workflow_dispatch-Trigger fügt einen “Run workflow”-Button in der GitHub Actions UI hinzu, der es dir ermöglicht, den Workflow manuell bei Bedarf auszulösen. Dies ist nützlich für Deployment-Workflows, Wartungsaufgaben oder jeden Prozess, der auf Abruf und nicht automatisch laufen muss. Option A beschreibt den push-Trigger, Option C beschreibt schedule, und Option D beschreibt den issues-Trigger.

Frage 8: Zweck des Branch-Schutzes

Was ist der Hauptzweck der Implementierung von Branch-Protection-Regeln auf dem main-Branch?

A) Das Repository schneller laufen zu lassen
B) Direkte Pushes zu verhindern und Qualitätsanforderungen (wie bestandene CI und Code Review) vor dem Mergen durchzusetzen
C) Alte Branches automatisch zu löschen
D) Den Code im Main-Branch zu verschlüsseln

Antwort anzeigen

Richtige Antwort: B

Branch-Protection-Regeln setzen Quality Gates durch, indem sie direkte Pushes auf wichtige Branches verhindern und Pull Requests, bestandene CI-Checks und Code Reviews erfordern, bevor Änderungen gemergt werden können. Dies schafft ein Sicherheitsnetz, das verhindert, dass fehlerhafter Code die Produktion erreicht, und fördert die Zusammenarbeit durch Code Review. Optionen A, C und D sind nicht mit der Branch-Protection-Funktionalität verbunden.

Frage 9: Die Rolle von uv in CI/CD

Warum empfiehlt dieser Kurs die Verwendung von astral-sh/setup-uv anstelle von actions/setup-python in GitHub Actions Workflows?

A) uv ist schneller zu installieren als Python
B) uv verwaltet sowohl Python-Versionen als auch Abhängigkeiten, bietet integriertes Caching und entspricht dem lokalen Development-Workflow
C) actions/setup-python ist veraltet und wird nicht mehr gewartet
D) uv-Actions sind kostenlos, während setup-python Bezahlung erfordert

Antwort anzeigen

Richtige Antwort: B

Die Verwendung von astral-sh/setup-uv bietet ein einheitliches Tool, das Python-Versionsverwaltung, Abhängigkeitsinstallation und Caching übernimmt - und genau dem entspricht, was wir in der lokalen Entwicklung mit uv python pin und uv sync tun. Diese Konsistenz zwischen lokalen und CI-Umgebungen reduziert “funktioniert lokal, schlägt aber in CI fehl”-Probleme. Option A ist irreführend (beide sind schnell), Option C ist falsch (setup-python wird aktiv gewartet), und Option D ist falsch (beide sind kostenlos für öffentliche Repos).

Frage 10: Matrix-Testing-Strategie

Was ist der Hauptvorteil der Verwendung einer Matrix-Strategie in GitHub Actions?

A) Sie lässt deine Workflow-Datei professioneller aussehen
B) Sie ermöglicht es dir, deinen Code parallel gegen mehrere Konfigurationen (wie verschiedene Python-Versionen) zu testen
C) Sie behebt automatisch Bugs, die während des Testens gefunden werden
D) Sie reduziert die Gesamtzahl der Zeilen in deiner Workflow-Datei

Antwort anzeigen

Richtige Antwort: B

Matrix-Strategien ermöglichen es dir, denselben Code gleichzeitig gegen mehrere Konfigurationen zu testen - zum Beispiel das Testen gegen Python 3.12 und 3.13 zur gleichen Zeit. Dies stellt sicher, dass dein Code in verschiedenen Umgebungen funktioniert, ohne separate Workflows für jede Konfiguration zu schreiben. Die Jobs laufen parallel und geben dir schnelles Feedback über alle Konfigurationen hinweg. Optionen A, C und D sind keine Vorteile von Matrix-Strategien.

Frage 11: Entscheidung für Custom Actions

Wann solltest du laut der Vorlesung in Erwägung ziehen, eine eigene GitHub Action zu erstellen?

A) Immer wenn du einen Workflow schreibst, erstelle immer zuerst eine Custom Action
B) Wenn du komplexe Logik hast, die sich über mehrere Workflows wiederholt, oder organisationsspezifische Anforderungen
C) Niemals - du solltest nur offizielle GitHub-Actions verwenden
D) Nur wenn du deine Action auf dem Marketplace verkaufen möchtest

Antwort anzeigen

Richtige Antwort: B

Custom Actions sind sinnvoll, wenn du wiederverwendbare Logik hast, die in mehreren Workflows erscheint, oder wenn du organisationsspezifische Automatisierung benötigst, die bestehende Actions nicht bieten. Wenn jedoch ein einfacher run:-Befehl oder eine bestehende Action ausreicht, ist das Erstellen einer Custom Action unnötiger Overhead. Die Vorlesung betont, zuerst bestehende Actions zu verwenden und nur Custom Actions zu erstellen, wenn du einen spezifischen Bedarf hast, der von verfügbaren Actions nicht erfüllt wird.

Frage 12: GitHub Copilot für Workflows verwenden

Was ist laut den Empfehlungen der Vorlesung zur Verwendung von GitHub Copilot zum Erstellen von Workflows der beste Ansatz?

A) Immer Copilot Workflows generieren lassen, ohne sie zu überprüfen, da KI perfekt ist
B) Zuerst die Grundlagen von Workflows lernen, dann Copilot verwenden, um die Erstellung zu beschleunigen, während man die Ausgabe sorgfältig überprüft
C) Niemals KI-Tools verwenden - nur Workflows manuell schreiben
D) Copilot nur zum Kommentieren deines Codes verwenden, nicht zum Generieren von Workflows

Antwort anzeigen

Richtige Antwort: B

Die Vorlesung betont einen ausgewogenen Ansatz: Zuerst lerne die Grundlagen (Teile 3-4), dann nutze KI-Tools wie Copilot, um deine Arbeit zu beschleunigen, während du dein Grundlagenwissen verwendest, um das zu überprüfen und zu validieren, was KI generiert. Dieser “KI verstärkt deine Fähigkeiten”-Ansatz kombiniert das Beste aus beiden Welten - menschliches Verständnis mit KI-Effizienz. Optionen A und C repräsentieren Extreme, die diesen ausgewogenen Ansatz verfehlen.

Frage 13: Effektives AI-Prompting für Workflows

Was macht einen GitHub Copilot-Prompt effektiv beim Erstellen eines Workflows?

A) So wenige Wörter wie möglich verwenden
B) In Großbuchstaben schreiben, um Wichtigkeit zu betonen
C) Spezifisch über Anforderungen sein (Trigger, Actions, Abhängigkeiten, Runner, etc.)
D) Copilot bitten, es “zum Laufen zu bringen” ohne Details

Antwort anzeigen

Richtige Antwort: C

Effektive Prompts sind spezifisch und detailliert. Anstatt vager Anfragen wie “erstelle einen Workflow”, spezifiziere genau, was du brauchst: welche Events ihn auslösen, welche Actions zu verwenden sind (wie astral-sh/setup-uv@v4), welche Abhängigkeiten zu installieren sind, welche Qualitätschecks auszuführen sind und welcher Runner zu verwenden ist. Je mehr Kontext du gibst, desto besser passt die Ausgabe von Copilot zu deinen Bedürfnissen. Generische Prompts führen zu generischen (oft falschen) Ergebnissen.

Frage 14: Geschichtete Quality Gates

Warum empfiehlt die Vorlesung einen “geschichteten” Ansatz für Qualitätschecks (IDE → Pre-commit → CI → Code Review)?

A) Weil mehr Schichten immer bessere Qualität bedeuten, unabhängig davon, was sie prüfen
B) Jede Schicht fängt verschiedene Arten von Problemen in verschiedenen Stadien ab und schafft einen Qualitätstrichter, der Bugs davon abhält, die Produktion zu erreichen
C) Um die Entwicklung langsamer und bürokratischer zu machen
D) Weil GitHub erfordert, dass alle vier Schichten vorhanden sind

Antwort anzeigen

Richtige Antwort: B

Der geschichtete Ansatz schafft einen Qualitätstrichter, bei dem jede Schicht verschiedene Probleme abfängt: Die IDE fängt Syntaxfehler sofort ab, Pre-commit fängt Linting-Probleme vor dem Commit ab, CI fängt umgebungsspezifische Probleme ab, und Code Review fängt logische Probleme ab. Diese “Defense in Depth”-Strategie bedeutet, dass die meisten Probleme früh abgefangen werden (schnelles Feedback) und nur seltene Randfälle alle Schichten durchdringen. Es geht nicht um Bürokratie (C), sondern um strategische Platzierung automatisierter Checks.

Frage 15: CI/CD für Studentenprojekte

Warum empfiehlt die Vorlesung die Verwendung öffentlicher Repositories für Studentenprojekte in Bezug auf CI/CD?

A) Öffentliche Repositories sind von der Universität erforderlich
B) Private Repositories unterstützen GitHub Actions nicht
C) Öffentliche Repositories erhalten unbegrenzte kostenlose GitHub Actions-Minuten und bieten Portfolio-Vorteile
D) Öffentliche Repositories bekommen automatisch bessere Noten

Antwort anzeigen

Richtige Antwort: C

Öffentliche Repositories auf GitHub erhalten unbegrenzte kostenlose CI/CD-Minuten, was sie perfekt für Studentenprojekte macht, bei denen du professionelle Praktiken ohne Kostenbedenken implementieren möchtest. Zusätzlich dienen öffentliche Repositories als Portfolio-Stücke, die zukünftige Arbeitgeber überprüfen können. Private Repositories haben begrenzte kostenlose Minuten, was das Lernen einschränken könnte. Optionen A, B und D sind falsch - es gibt keine Universitätsanforderung, private Repos unterstützen Actions, und Sichtbarkeit beeinflusst keine Noten.

Bewertungsleitfaden

13-15 richtig: Ausgezeichnet! Du hast ein starkes Verständnis von CI/CD- und Automatisierungskonzepten
10-12 richtig: Gutes Verständnis! Überprüfe die Bereiche, die du verpasst hast, um dein Wissen zu festigen
7-9 richtig: Ausreichendes Verständnis. Gehe die Vorlesungsmaterialien für Schlüsselkonzepte noch einmal durch, besonders Workflow-Struktur und Quality Gates
Unter 7: Bitte überprüfe die Vorlesung sorgfältig und melde dich in den Sprechstunden, wenn du Klärung benötigst

Wichtigste Erkenntnisse zum Merken

CI/CD verhindert Integration Hell - Automatisiertes Testen in standardisierten Umgebungen fängt Probleme Minuten nach ihrer Einführung ab, nicht Wochen später
Workflows enthalten Jobs enthalten Steps - Das Verständnis dieser Hierarchie ist grundlegend für den Aufbau effektiver GitHub Actions Workflows
Verwende Major-Version-Tags (@v4) - Erhalte automatische Sicherheits-Patches und Updates ohne brechende Änderungen
Überprüfe die Action-Qualität vor der Verwendung - Suche nach offiziellen/verifizierten Erstellern, aktuellen Updates und aktiver Wartung
Pre-commit Hooks bieten sofortiges Feedback - Fange Probleme in Sekunden ab, bevor sie GitHub erreichen, spare Zeit und CI-Minuten
uv vereinheitlicht deinen Development-Workflow - Die Verwendung von astral-sh/setup-uv in CI entspricht exakt deiner lokalen Entwicklungsumgebung
Matrix-Strategien testen mehrere Konfigurationen - Führe parallele Tests gegen verschiedene Python-Versionen oder Umgebungen effizient aus
Erstelle Custom Actions nur bei Bedarf - Beginne mit bestehenden Actions; erstelle Custom Actions für wiederholte komplexe Logik
KI verstärkt Grundlagenwissen - Lerne Workflows zuerst manuell, verwende dann Copilot zur Beschleunigung während sorgfältiger Überprüfung
Schichte deine Quality Gates - IDE → Pre-commit → CI → Code Review schafft einen Trichter, der verschiedene Problem-Typen in optimalen Stadien abfängt
Branch-Schutz setzt Standards durch - Verhindere direkte Pushes zu main und erfordere bestandene CI + Code Review vor dem Mergen
Spezifische Prompts liefern bessere KI-Ergebnisse - Detailliere deine Anforderungen (Trigger, Actions, Checks, Runner) für Copilot, um genaue Workflows zu generieren
Öffentliche Repos erhalten unbegrenztes CI/CD - Perfekt für Studentenprojekte, die sowohl als Lernerfahrungen als auch als Portfolio-Stücke dienen
Schnelles Feedback ist entscheidend - Je früher du Probleme abfängst, desto günstiger sind sie zu beheben (erinnere dich an die 1x/10x/100x/1000x-Kosteneskala)
Automatisiere, was Menschen vergessen - Wenn es Erinnern erfordert, wird es nicht konsequent geschehen - automatisiere Qualitätschecks stattdessen