Software Product Mastering / Inhaltsverzeichnis / Produkt & Projekt / Methoden
Pull requests¶
Zusammenfassung¶
Pull Request (PR) / Merge Request (MR) – Kurz erklärt:¶
- Definition: Werkzeug in Versionskontrollsystemen (z. B. Git), um Änderungen aus einem Branch in den Hauptbranch zu integrieren.
- Funktionen:
- Diskussion, Feedback und Code-Reviews.
- Sichtbarmachung von Änderungen (Diffs).
- Integration automatischer Tests und Checks (CI/CD).
- Frühzeitige Fehler- und Qualitätskontrolle.
Beitrag zum "Shift Left" – Stichpunkte:¶
Frühe Qualitätssicherung:
- Code-Reviews erkennen Probleme (Bugs, ineffizienter Code) vor dem Merge.
- Verbesserte Zusammenarbeit und Wissenstransfer.
Automatisierte Prüfungen:
- CI/CD-Tools führen Tests, Codeanalysen und Sicherheits-Checks frühzeitig aus.
- Fehler und Sicherheitsprobleme werden direkt im Entwicklungsprozess gefunden.
Kultur der Qualität:
- Entwickler erhalten direktes Feedback und lernen Best Practices.
- Förderung von Verantwortung und Qualitätsbewusstsein im Team.
Fehlerprävention:
- Reduziert Kosten durch frühzeitiges Finden und Beheben von Problemen.
- Minimiert Risiken in späteren Entwicklungsphasen und der Produktion.
Kontinuierliche Verbesserung:
- Feedback im PR fördert Lernprozesse und Iterationen.
- Bessere Codequalität für zukünftige Projekte.
Nochmal zum Nachlesen...
Was ist ein Pull Request (Merge Request)?¶
Ein Pull Request (PR), oft auch als Merge Request (MR) bezeichnet, ist ein Workflow-Werkzeug in Versionskontrollsystemen wie Git, das von Entwicklern verwendet wird, um Änderungen, die in einem separaten Branch vorgenommen wurden, in den Hauptbranch (z. B. main oder develop) eines Repositories zu integrieren.
Wichtige Merkmale eines Pull Requests:¶
Zweck:
- Er dient dazu, Code-Änderungen zu diskutieren, zu überprüfen (Code Review) und schrittweise in den Hauptbranch zu integrieren.
- Ziel ist die Verbesserung der Codequalität, das Finden von Fehlern und die Sicherstellung der Einhaltung von Entwicklungsrichtlinien.
Bestandteile eines Pull Requests:
- Titel und Beschreibung: Zusammenfassung der Änderungen und ggf. Details zur Implementierung.
- Änderungen (Diffs): Zeigt die Unterschiede zwischen den Branches auf Datei- und Zeilenebene.
- Reviewer und Assignees: Personen, die für die Prüfung und Genehmigung zuständig sind.
- Kommentare und Diskussionen: Ermöglicht Feedback, Diskussionen und Klärungen.
- Automatische Checks: Integration von CI/CD-Tools (z. B. Unit-Tests, statische Codeanalyse).
Workflow:
- Entwickler erstellt einen neuen Feature-Branch.
- Änderungen werden implementiert, getestet und in den Branch gepusht.
- Ein Pull Request wird eröffnet, um die Änderungen zur Integration vorzuschlagen.
- Andere Teammitglieder überprüfen den PR, geben Feedback und genehmigen ihn.
- Nach erfolgreichem Review und automatisierten Tests wird der PR in den Zielbranch gemergt.
Wie hilft ein Pull Request beim "Shift Left"?¶
Der Begriff Shift Left beschreibt die Idee, Qualitäts- und Sicherheitsprüfungen früher im Entwicklungsprozess durchzuführen, um Kosten und Aufwand für die Behebung von Problemen zu reduzieren. Pull Requests unterstützen dieses Prinzip in mehrfacher Hinsicht:
1. Frühe Qualitätssicherung durch Code Reviews¶
- Pull Requests fördern den Austausch und die Zusammenarbeit zwischen Entwicklern.
- Probleme wie fehlerhafte Implementierungen, ineffizienter Code oder Verstöße gegen Coding Standards werden frühzeitig entdeckt.
- Dies verhindert, dass fehlerhafter Code in den Hauptbranch gelangt, wo er potenziell größere Probleme verursachen könnte.
2. Integration von Automatisierung¶
- Tools wie Continuous Integration (CI) führen bei jedem PR automatische Tests, Codeanalysen und Sicherheitsprüfungen durch.
- Beispiele:
- Unit-Tests stellen sicher, dass neue Funktionen korrekt funktionieren.
- Statische Codeanalyse findet potenzielle Bugs und Verstöße gegen Codierungsrichtlinien.
- Sicherheits-Scans identifizieren Schwachstellen wie unsichere Abhängigkeiten.
Durch diese automatisierten Prüfungen wird sichergestellt, dass Probleme früh im Entwicklungszyklus entdeckt und behoben werden.
3. Erhöhung des Bewusstseins für Qualität¶
- Durch das Feedback im Pull Request lernen Entwickler Best Practices und verbessern ihre Fähigkeiten.
- Pull Requests fördern eine Kultur der Qualität und Verantwortung, was das gesamte Team leistungsfähiger macht.
4. Verhinderung von Fehlern in der Produktion¶
- Shift Left bedeutet, Fehler und Sicherheitsprobleme möglichst nah an der Code-Quelle zu identifizieren.
- Mit Pull Requests und frühzeitiger Überprüfung wird sichergestellt, dass Probleme gar nicht erst in die späten Phasen wie Integrationstests oder die Produktionsumgebung gelangen.
5. Kontinuierliche Verbesserung¶
- Diskussionen und Feedback in Pull Requests fördern die Iteration und kontinuierliche Verbesserung des Codes.
- Entwickler können direkt aus der Kritik lernen, wodurch zukünftige Probleme reduziert werden.
Fazit¶
Pull Requests sind ein zentraler Bestandteil des Shift-Left-Ansatzes, da sie Qualitätssicherung und Kollaboration in die frühesten Phasen des Entwicklungsprozesses integrieren. Sie tragen dazu bei, Fehler frühzeitig zu erkennen, die Codequalität zu erhöhen, Sicherheitslücken zu vermeiden und den Entwicklungsprozess insgesamt effizienter zu gestalten.
Pull Requests (PR) und ihre Bedeutung für "Shift Left"¶
Definition und Funktion¶
- Werkzeug in Versionskontrollsystemen wie Git zur Integration von Code-Änderungen.
- Ermöglicht Code Reviews, Diskussionen und Feedback vor dem Merge.
- Integriert automatisierte Tests und Qualitätssicherungs-Tools.
Vorteile im Shift-Left-Kontext¶
- Frühe Qualitätsprüfung:
- Fehler und Verstöße gegen Standards werden früh erkannt.
- Automatisierung:
- CI/CD-Tools testen Code auf Funktionalität, Qualität und Sicherheit.
- Kollaboration und Wissenstransfer:
- Teamarbeit und Feedback fördern bessere Lösungen und Lernmöglichkeiten.
- Iterative Integration:
- Verhindert große, fehleranfällige Änderungen („Big Bang Merges“).
Weitere Vorteile¶
- Dokumentation:
- PRs dokumentieren Code-Änderungen und ihre Hintergründe.
- Compliance:
- Nachvollziehbare Genehmigungsketten für Audits und Sicherheitsanforderungen.
- Vermeidung technischer Schulden:
- Durch Reviews und kontinuierliche Verbesserungen.
- DevOps-Kultur:
- Fördert Transparenz, Ownership und schnelle Feedback-Zyklen.
Herausforderungen¶
- Langsame Reviews:
- Lösung: Klare Prozesse und Priorisierung.
- Merge-Konflikte:
- Lösung: Regelmäßiges Rebasen und kleine PRs.
- Overhead für kleine Teams:
- Lösung: Automatisierte Checks und Pair Programming.
Fazit¶
Pull Requests sind essenziell für Shift Left, da sie frühe Qualitäts- und Sicherheitsprüfungen ermöglichen, Teamarbeit stärken und den Entwicklungsprozess optimieren.
Nochmal zum Nachlesen...
Erweiterte Betrachtung von Pull Requests¶
Es gibt mehrere weitere Aspekte, die Pull Requests (PRs) als wertvolles Werkzeug im Entwicklungsprozess auszeichnen, insbesondere in Bezug auf den Shift-Left-Ansatz. Diese reichen von kulturellen Veränderungen in Teams bis hin zu technischen Details, die den Entwicklungsprozess optimieren.
1. Kollaboration und Wissensaustausch¶
- Teamzusammenarbeit:
- PRs fördern die Kommunikation und Zusammenarbeit zwischen Teammitgliedern. Selbst in geografisch verteilten Teams können Entwickler ihren Code leicht teilen, Feedback erhalten und gemeinsam Lösungen finden.
- Mentoring und Lernen:
- Erfahrene Entwickler können durch Code Reviews in PRs weniger erfahrene Kollegen coachen.
- PRs dokumentieren Best Practices und fördern so den Wissensaustausch.
2. Dokumentation und Nachvollziehbarkeit¶
- Codehistorie:
- Jeder PR dokumentiert, warum und wie eine Änderung vorgenommen wurde. Dies erleichtert spätere Fehlersuche und Audits.
- PR-Beschreibungen und Diskussionen schaffen eine Art lebendige Dokumentation, die über den Code hinausgeht.
- Compliance und Revision:
- In regulierten Branchen oder sicherheitskritischen Umgebungen bieten PRs eine dokumentierte Genehmigungskette, die den Anforderungen von Audits und Compliance entspricht.
3. Vermeidung von "Big Bang"-Zusammenführungen¶
- Große, monolithische Änderungen sind schwer zu testen und anfällig für Fehler. PRs fördern iteratives Arbeiten, indem sie Änderungen in kleinere, besser handhabbare Stücke aufteilen:
- Feature Branching:
- Entwickler arbeiten isoliert, bis eine Funktion fertig ist.
- PRs stellen sicher, dass der Hauptbranch stabil bleibt.
- Continuous Delivery/Deployment:
- Kleine Änderungen können schneller integriert und in die Produktion gebracht werden, was den Durchsatz erhöht.
- Feature Branching:
4. Shift Left durch frühzeitige Sicherheitsprüfungen¶
- Sicherheit in der Entwicklung:
- PRs ermöglichen die Integration von Sicherheitsprüfungen direkt in die CI/CD-Pipeline:
- Überprüfung auf bekannte Sicherheitslücken in Abhängigkeiten.
- Validierung von sicherheitsrelevanten Codierungsstandards (z. B. Vermeidung von SQL-Injection).
- PRs ermöglichen die Integration von Sicherheitsprüfungen direkt in die CI/CD-Pipeline:
- Prevention-as-a-Service:
- Tools wie Snyk oder GitHub Advanced Security analysieren PRs automatisch auf Sicherheitsrisiken, sodass potenzielle Schwachstellen früh behoben werden können.
5. Förderung der DevOps-Kultur¶
Pull Requests sind ein zentraler Bestandteil einer DevOps-Kultur, die auf kontinuierlicher Integration und Lieferung (CI/CD) basiert:
- Transparenz und Ownership:
- PRs fördern die gemeinsame Verantwortung für die Codebasis. Entwickler fühlen sich für Qualität und Stabilität verantwortlich.
- Feedback-Zyklen:
- Automatisierte Tests und Code-Reviews bieten schnelles Feedback, wodurch Entwickler ihre Arbeit kontinuierlich verbessern können.
6. Automatisierung und Tooling¶
- Linting und Formatting:
- Tools wie ESLint, Prettier oder CodeFormatter prüfen und formatieren den Code automatisch, bevor ein PR gemerged wird.
- Branch Policies:
- Viele Repositories setzen Regeln für PRs (z. B. mindestens zwei Reviewer, grüne CI-Checks), um Qualität zu gewährleisten.
- Integration mit Monitoring und Metriken:
- PRs können mit Tools integriert werden, die Codequalität, Testabdeckung und andere Metriken messen (z. B. SonarQube, CodeClimate).
7. Risikominimierung durch Canary Releases¶
- PRs können mit Canary Releases kombiniert werden, um Änderungen schrittweise auszurollen:
- Änderungen werden zunächst nur für einen kleinen Teil der Benutzer freigeschaltet.
- Feedback wird gesammelt und Fehler werden frühzeitig behoben, bevor der Code vollständig ausgerollt wird.
8. Sozialer und psychologischer Aspekt¶
- Kulturelle Normen:
- PRs setzen implizit Qualitätsstandards und schaffen eine Kultur der kontinuierlichen Verbesserung.
- Motivation und Stolz:
- Der Austausch von Code und der Erhalt von Feedback geben Entwicklern das Gefühl, zur Qualität des gesamten Produkts beizutragen.
- Verhinderung von "Heroismus":
- PRs verhindern, dass einzelne Entwickler ohne Peer-Review große Änderungen umsetzen, was langfristig zu technischen Schulden führen könnte.
9. Herausforderungen bei Pull Requests¶
Trotz ihrer Vorteile gibt es auch potenzielle Schwierigkeiten:
- Langsame Reviews:
- Verzögerungen bei der Bearbeitung von PRs können die Entwicklung ausbremsen.
- Lösung: Klare Prozesse und Prioritäten für Reviews definieren.
- Overhead bei kleinen Teams:
- In sehr kleinen Teams kann der Review-Prozess als zusätzlicher Aufwand empfunden werden. Hier helfen automatisierte Tests und Peer-Reviews im Pair-Programming-Stil.
- Konflikte bei paralleler Arbeit:
- Bei mehreren PRs, die denselben Code betreffen, können Merge-Konflikte entstehen. Lösung: Regelmäßiges Rebasen und kleine, frequentere PRs.
Fazit: Der Pull Request als Schlüsselinstrument¶
Pull Requests sind mehr als nur ein Werkzeug für Code-Integration. Sie sind der Dreh- und Angelpunkt für:
- Shift Left durch frühzeitige Qualitäts- und Sicherheitsprüfungen.
- Förderung von Teamzusammenarbeit, Wissensaustausch und einer Kultur der Verantwortung.
- Automatisierung und Transparenz im gesamten Entwicklungsprozess.
Durch den sinnvollen Einsatz von Pull Requests können Unternehmen sowohl die technische als auch die organisatorische Qualität verbessern, wodurch sie langfristig produktiver, sicherer und agiler werden.
Branching Model, Gitflow und Pull Requests¶
Branching Model¶
- Struktur zur Organisation von Branches in Git.
- Wichtige Branch-Typen:
main: Stabile Produktionsversion.develop: Entwicklungszweig für den nächsten Release.- Feature Branches: Neue Funktionen (
feature/xyz). - Release Branches: Vorbereitung auf Releases (
release/x.y.z). - Hotfix Branches: Dringende Fehlerbehebungen (
hotfix/x.y.z).
Gitflow¶
- Beliebtes Branching Model für strukturierte Entwicklungsprozesse.
- Haupt-Workflow:
- Feature Branches → Merge in
develop. - Release Branches → Stabilisierung, Merge in
mainunddevelop. - Hotfix Branches → Direktfix auf
main, Merge inmainunddevelop.
- Feature Branches → Merge in
gitGraph
commit id: "M1" type: HIGHLIGHT tag: "main"
branch develop
commit id: "D1"
branch feature/login
commit id: "F1"
commit id: "F2"
checkout develop
merge feature/login tag: "feature/login merged"
commit id: "D2"
branch feature/payment
commit id: "P1"
commit id: "P2"
checkout develop
merge feature/payment tag: "feature/payment merged"
commit id: "D3"
branch release/1.0.0
commit id: "R1"
checkout main
merge release/1.0.0 tag: "release/1.0.0 merged"
commit id: "M2"
branch hotfix/1.0.1
commit id: "H1"
checkout main
merge hotfix/1.0.1 tag: "hotfix/1.0.1 merged"
checkout develop
merge hotfix/1.0.1
Pull Requests in Gitflow¶
Feature Entwicklung:
- Branch von
develop. - PR → Code Review → Merge in
develop.
- Branch von
Release Stabilisierung:
- Branch von
develop. - Bugfixes/Anpassungen → PR → Merge in
mainunddevelop.
- Branch von
Hotfix für Produktion:
- Branch von
main. - PR → Fix in
mainunddevelop.
- Branch von
Vorteile von Gitflow mit Pull Requests¶
- Klare Branch-Struktur und Nachvollziehbarkeit.
- Frühzeitige Qualitätssicherung durch Reviews und automatisierte Tests.
- Paralleles Arbeiten an Features, Releases und Hotfixes.
- Dokumentation von Änderungen und Diskussionen.
Fazit¶
Gitflow und Pull Requests ergänzen sich perfekt, um stabile und effiziente Entwicklungsprozesse zu fördern, ideal für größere Teams und Projekte.
Nochmal zum Nachlesen...
Branching Model – Eine Einführung¶
Ein Branching Model beschreibt die Struktur und Regeln, nach denen Branches in einem Versionskontrollsystem wie Git organisiert werden, um die Entwicklung zu erleichtern. Es legt fest, wie Branches erstellt, benannt und zusammengeführt werden, um effiziente Zusammenarbeit, Qualitätssicherung und Versionskontrolle zu gewährleisten.
Wichtige Konzepte im Branching Model¶
Branches:
- Ein Branch ist ein unabhängiger Entwicklungszweig, in dem Änderungen vorgenommen werden können, ohne den Hauptbranch zu beeinflussen.
- Beispiele:
feature,bugfix,release,hotfix.
Branch-Typen:
- Main Branch (z. B.
mainodermaster):- Enthält die stabile, produktionsreife Version des Codes.
- Develop Branch:
- Sammelpunkt für alle Änderungen, bevor sie in den Main Branch integriert werden. Häufig für CI/CD verwendet.
- Feature Branches:
- Kurzlebige Branches für die Implementierung neuer Funktionen.
- Release Branches:
- Vorbereitung einer neuen Version (z. B. Bugfixes, Dokumentation).
- Hotfix Branches:
- Für dringende Fehlerbehebungen direkt am produktiven Code.
- Main Branch (z. B.
Branching-Regeln:
- Klare Namenskonventionen, z. B.
feature/login,bugfix/crash-issue. - Merge-Strategien (z. B. Pull Requests oder direkte Merges).
- Klare Namenskonventionen, z. B.
Was ist Gitflow?¶
Gitflow ist ein beliebtes Branching Model, das von Vincent Driessen entwickelt wurde. Es definiert eine klare Struktur und Workflow für die Arbeit mit Branches in Git. Es eignet sich besonders für Projekte mit regelmäßigen Releases.
Hauptkomponenten von Gitflow¶
Main Branches:
main: Enthält immer den stabilen Produktionscode.develop: Sammelpunkt für alle fertigen Features; repräsentiert den nächsten Release.
Support Branches:
- Feature Branches (
feature/xyz):- Abzweigung von
develop. - Dient zur Implementierung neuer Funktionen.
- Abzweigung von
- Release Branches (
release/x.y.z):- Abzweigung von
develop. - Für abschließende Tests, Bugfixes und die Vorbereitung eines Releases.
- Abzweigung von
- Hotfix Branches (
hotfix/x.y.z):- Abzweigung von
main. - Für dringende Fehlerbehebungen im Produktionscode.
- Abzweigung von
- Feature Branches (
Workflow in Gitflow:
- Feature Workflow:
- Neuer Feature Branch → Entwicklung → Merge in
developvia Pull Request.
- Neuer Feature Branch → Entwicklung → Merge in
- Release Workflow:
- Neuer Release Branch → Stabilisierung → Merge in
mainunddevelop.
- Neuer Release Branch → Stabilisierung → Merge in
- Hotfix Workflow:
- Neuer Hotfix Branch → Bugfix → Merge in
mainunddevelop.
- Neuer Hotfix Branch → Bugfix → Merge in
- Feature Workflow:
Verwendung von Gitflow für Pull Requests¶
Pull Requests sind ein wesentlicher Bestandteil des Gitflow-Workflows, da sie die Qualitätssicherung und Zusammenarbeit unterstützen.
1. Feature Entwicklung mit Pull Requests¶
- Ein Entwickler erstellt einen Feature Branch von
develop. - Nach Abschluss der Arbeit wird ein Pull Request erstellt:
- Zielbranch:
develop. - Automatische Checks (Tests, Linting) werden ausgeführt.
- Reviewer geben Feedback und genehmigen den Pull Request.
- Zielbranch:
- Nach Genehmigung wird der Branch in
developgemergt und gelöscht.
2. Release Branch mit Pull Requests¶
- Wenn alle Features fertig sind, wird ein Release Branch von
developerstellt. - Kleinere Änderungen oder Bugfixes können direkt auf den Release Branch gemerged werden:
- Zielbranch:
release/x.y.z.
- Zielbranch:
- Nach erfolgreicher Stabilisierung wird der Release Branch:
- In
main(für den Release) und - In
develop(um Änderungen zu synchronisieren) gemerged.
- In
3. Hotfix Branch mit Pull Requests¶
- Ein Hotfix Branch wird direkt von
mainerstellt. - Änderungen werden entwickelt, überprüft und per Pull Request gemerged:
- Zielbranches:
main(für den Fix) unddevelop(für die Synchronisation).
- Zielbranches:
- Dies stellt sicher, dass die Produktionsprobleme sofort behoben werden, ohne
developauszulassen.
Vorteile von Gitflow in Verbindung mit Pull Requests¶
- Klare Strukturen:
- Die Trennung von Feature-, Release- und Hotfix-Branches bietet Übersicht und Nachvollziehbarkeit.
- Qualitätssicherung:
- Pull Requests ermöglichen Code Reviews und automatische Prüfungen.
- Parallelität:
- Mehrere Entwickler können gleichzeitig an unterschiedlichen Branches arbeiten.
- Fehlerfreie Releases:
- Release Branches erlauben gezielte Stabilisierung und Tests vor dem Merge in
main.
- Release Branches erlauben gezielte Stabilisierung und Tests vor dem Merge in
- Nachvollziehbarkeit:
- Pull Requests dokumentieren alle Änderungen und Diskussionen.
Beispiel-Workflow für Gitflow mit Pull Requests¶
Feature Entwicklung:
git checkout develop git checkout -b feature/login # Entwicklung git commit -m "Add login feature" git push origin feature/login
- Pull Request → Merge in
develop.
- Pull Request → Merge in
Release Erstellung:
git checkout develop git checkout -b release/1.0.0 # Bugfixes und Dokumentation git commit -m "Prepare release 1.0.0" git push origin release/1.0.0
- Pull Request → Merge in
mainunddevelop.
- Pull Request → Merge in
Hotfix für Produktion:
git checkout main git checkout -b hotfix/1.0.1 # Bugfix git commit -m "Fix critical bug" git push origin hotfix/1.0.1
- Pull Request → Merge in
mainunddevelop.
- Pull Request → Merge in
Fazit¶
Ein Branching Model wie Gitflow bietet eine klare Struktur für die Arbeit mit Branches. Pull Requests ergänzen diese Struktur perfekt, indem sie Qualitätssicherung und Zusammenarbeit ermöglichen. Zusammen fördern sie stabile, nachvollziehbare und effiziente Entwicklungsprozesse, die sich besonders für größere Projekte und Teams eignen.
Quiz¶
Hier ist ein Beispiel für ein kleines Quiz zu Pull Requests und Shift Left, das sich in einem Jupyter Notebook verwenden lässt.
In [5]:
quiz_data = [
{
"question": "Was ist ein Pull Request?",
"options": [
"Ein Werkzeug zur Bearbeitung von Merge-Konflikten",
"Ein Prozess, um Codeänderungen vorzuschlagen und zu prüfen",
"Ein automatisches Testsystem für CI/CD"
],
"correct": 1,
"explanation": "Ein Pull Request ist ein Prozess, um Codeänderungen vorzuschlagen und von anderen überprüfen zu lassen."
},
{
"question": "Wie hilft der Shift-Left-Ansatz bei der Qualitätssicherung?",
"options": [
"Er verschiebt Tests und Reviews in eine spätere Phase",
"Er integriert Tests und Codeprüfungen früh im Entwicklungsprozess",
"Er automatisiert den gesamten Release-Prozess"
],
"correct": 1,
"explanation": "Shift Left bedeutet, Qualitäts- und Sicherheitsprüfungen früh im Entwicklungsprozess durchzuführen, um Probleme frühzeitig zu finden."
},
{
"question": "Warum sind Pull Requests für Teams wichtig?",
"options": [
"Sie ermöglichen Zusammenarbeit und Feedback",
"Sie automatisieren den Deployment-Prozess",
"Sie verhindern Merge-Konflikte"
],
"correct": 0,
"explanation": "Pull Requests fördern Zusammenarbeit und ermöglichen Feedback zwischen Teammitgliedern."
}
]
def run_quiz():
score = 0
for index, question_data in enumerate(quiz_data, start=1):
print(f"\nFrage {index}: {question_data['question']}")
for i, option in enumerate(question_data['options']):
print(f"{i + 1}. {option}")
while True:
try:
answer = int(input("Deine Antwort (1-3): ")) - 1
if answer not in range(len(question_data['options'])):
raise ValueError
break
except ValueError:
print("Bitte gib eine gültige Zahl zwischen 1 und 3 ein.")
if answer == question_data["correct"]:
print("Richtig! 🎉")
score += 1
else:
print("Falsch! 😞")
print("Erklärung:", question_data["explanation"])
print(f"\nQuiz beendet! Deine Punktzahl: {score}/{len(quiz_data)}")
if __name__ == "__main__":
run_quiz()
Frage 1: Was ist ein Pull Request? 1. Ein Werkzeug zur Bearbeitung von Merge-Konflikten 2. Ein Prozess, um Codeänderungen vorzuschlagen und zu prüfen 3. Ein automatisches Testsystem für CI/CD Falsch! 😞 Erklärung: Ein Pull Request ist ein Prozess, um Codeänderungen vorzuschlagen und von anderen überprüfen zu lassen. Frage 2: Wie hilft der Shift-Left-Ansatz bei der Qualitätssicherung? 1. Er verschiebt Tests und Reviews in eine spätere Phase 2. Er integriert Tests und Codeprüfungen früh im Entwicklungsprozess 3. Er automatisiert den gesamten Release-Prozess Richtig! 🎉 Erklärung: Shift Left bedeutet, Qualitäts- und Sicherheitsprüfungen früh im Entwicklungsprozess durchzuführen, um Probleme frühzeitig zu finden. Frage 3: Warum sind Pull Requests für Teams wichtig? 1. Sie ermöglichen Zusammenarbeit und Feedback 2. Sie automatisieren den Deployment-Prozess 3. Sie verhindern Merge-Konflikte Falsch! 😞 Erklärung: Pull Requests fördern Zusammenarbeit und ermöglichen Feedback zwischen Teammitgliedern. Quiz beendet! Deine Punktzahl: 1/3