Microsoft AZ-400: Quellcodeverwaltung und Repository-Verwaltung — Lernleitfaden

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Teil des Microsoft DevOps Engineer Expert AZ-400 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Moderne DevOps-Praktiken basieren auf vorhersagbarer, kollaborativer Quellcodeverwaltung und diszipliniertem Repository-Management. Azure Repos und GitHub bieten komplementäre Funktionen für Versionskontrolle, Richtliniendurchsetzung, Zusammenarbeit und Sicherheit. Die Beherrschung von Branching-Strategien, Pull-Request-Workflows, Berechtigungen, Hooks, dem Umgang mit großen Dateien, Migrationsmustern, Sicherheitsscans und Versionierung ist für resiliente Delivery-Pipelines und Auditierbarkeit unerlässlich. Das Ziel ist nicht nur, Code zu speichern, sondern ein durchsetzbares, automatisiertes Kontrollsystem zu schaffen, das den Durchsatz des Teams skaliert, ohne die Qualität zu beeinträchtigen.

Grundlagen der Quellcodeverwaltung in Azure Repos und GitHub

Azure Repos unterstützt Git und Team Foundation Version Control (TFVC). Git ist verteilt, ermöglicht lokale Commits, einfaches Branching und dezentrale Workflows. TFVC ist zentralisiert mit serverseitiger Versionierung, gesperrten Check-outs (optional) und eignet sich gut für Legacy-Lösungen mit sehr großen binären Assets oder für Teams, die auf zentralisierte Workflows geschult sind. Für neue Entwicklungen sollte standardmäßig Git verwendet werden; TFVC bleibt eine praktikable Option, wenn eine inkrementelle Änderungskontrolle und zentrale Berechtigungen von größter Bedeutung sind und die Migrationskosten zu hoch sind.

Wählen Sie eine Branching-Strategie bewusst aus:

Trunk-based Development bevorzugt einen einzigen langlebigen main-Branch mit sehr kurzlebigen Feature-Branches und Continuous Integration. Dies beschleunigt den Flow, reduziert den Merge-Aufwand und ist ideal für Teams mit hoher Taktung und starker Testautomatisierung.
GitFlow verwendet langlebige develop- und main- (Release-) Branches, ergänzt durch Feature-, Release- und Hotfix-Branches. Es eignet sich für Produkte mit formalen Release-Zyklen (Release Trains) und Backporting-Anforderungen, erhöht aber den Koordinationsaufwand.
GitHub Flow ist ein vereinfachtes Modell mit einem einzigen main-Branch, kurzlebigen Topic-Branches, Continuous Deployment und häufigen Releases. Es ist effektiv für Dienste, die kontinuierlich ausgeliefert werden.

Monorepo versus Multi-Repo ist primär eine organisatorische und toolbasierte Entscheidung:

Ein Monorepo konsolidiert viele Komponenten in einem einzigen Repository, was atomare, serviceübergreifende Änderungen, einheitliches Refactoring und gemeinsam genutzte Tools erleichtert. Mit wachsender Historie kann es Git-Operationen belasten. Abhilfemaßnahmen umfassen Sparse Checkout, Partial Clone und CI-Pfadfilter, um den Umfang von Builds und Tests zu begrenzen.
Multi-Repo isoliert Zuständigkeiten, Historie und Berechtigungsgrenzen, was eine unabhängige Versionierung und Aufbewahrung erleichtert. Es kann die repo-übergreifende Koordination und den Drift von Abhängigkeiten erhöhen; Submodule oder Dependency Manager und Release-Orchestrierung sind hierbei entscheidend.

Zuständigkeiten und das Routing von Änderungen profitieren von Deklarationen der Code-Verantwortlichkeit (Code Ownership). Die CODEOWNERS-Datei von GitHub weist Pfade automatisch verpflichtenden Reviewern zu. In Azure Repos verwenden Sie pfadbasierte erforderliche Reviewer in Branch-Richtlinien (und CODEOWNERS, falls aktiviert), um Reviews an die zuständigen Komponententeams weiterzuleiten. Ergänzen Sie die Zuständigkeiten durch Konventionen für Branch-Namen, klare Commit-Nachrichten (z. B. Conventional Commits) und Repository-Vorlagen für mehr Konsistenz.

Governance: Richtlinien, Berechtigungen und Pull Requests

Branch-Richtlinien in Azure Repos kodifizieren Quality Gates:

Erforderliche Reviewer erzwingen eine Mindestanzahl an Prüfern und können bestimmte Personen/Gruppen oder pfadbasierte, automatisch zugewiesene Reviewer umfassen. Fordern Sie die Lösung von Kommentaren, um sicherzustellen, dass substanzielles Feedback vor dem Merge berücksichtigt wird.
Die Build-Validierung erfordert, dass eine oder mehrere CI-Pipelines vor dem Merge erfolgreich durchlaufen werden. Verwenden Sie Pfadfilter, um unnötige Builds zu vermeiden, und richten Sie automatisches Auslösen bei neuen Updates ein. Integrieren Sie externe Prüfungen über Status-Richtlinien für Sicherheitsscans oder Performancetests.
Merge-Strategien können eingeschränkt werden: Merge (no fast-forward) zeichnet die Merge-Historie auf; Squash fasst Änderungen zu einem einzigen Commit zusammen und hält die Historie linear; Rebase and fast-forward schreibt den Topic-Branch auf main neu für eine geradlinige Historie; Rebase and merge wiederholt die Commits und behält separate Commits ohne einen Merge-Commit bei. Richten Sie die Strategie an Audit-Anforderungen und nachgelagerten Tools aus.
Zusätzliche Prüfungen umfassen erforderliche verknüpfte Arbeitselemente, eine Mindestanzahl erfolgreicher Abstimmungen und das Blockieren bei aktiven Kommentaren oder ausstehenden Reviewern.

Pull Requests orchestrieren die Integrations-Konversation:

Draft-PRs signalisieren laufende Arbeit (Work-in-Progress) und blockieren den Abschluss, bis sie als bereit markiert werden. Ermutigen Sie zu frühem Feedback, ohne die Richtlinien vorzeitig auszulösen.
Auto-Complete führt den Merge automatisch durch, sobald alle Richtlinien erfüllt sind, was die Koordinationslatenz reduziert und den Flow erhöht.
Die Umgehung von Richtlinien (Bypass Policies) existiert für Notfallsituationen oder Automatisierungs-Konten. Sichern Sie dies mit der Berechtigung „Bypass policies when completing pull requests“ ab und auditieren Sie dies durch Genehmigungen und Change Management.
PR-Vorlagen standardisieren den Kontext: Nachweise für Tests, Risikohinweise, Deployment-Schritte und einen Rollback-Plan. Platzieren Sie in Azure Repos die Datei pull_request_template.md im Stammverzeichnis des Repos oder in .azuredevops/. Stellen Sie Checklisten für Sicherheit, Performance und Dokumentation bereit.

Berechtigungen und geschützte Branches sind Ihre letzte Verteidigungslinie:

Verwenden Sie Azure DevOps RBAC-Gruppen (Project Administrators, Contributors, Readers) und granulare Repo-Berechtigungen (Create branch, Create tag, Contribute, Force push, Manage permissions, Bypass policies). Bevorzugen Sie die Zuweisung von Zulassen/Verweigern (Allow/Deny) auf Gruppenebene anstatt für einzelne Benutzer.
Schützen Sie main- und Release-Branches, indem Sie Force Push und Delete verweigern, Contribute nur auf PR-Merges beschränken und Branch-Richtlinien aktivieren, die Builds und Reviews erfordern. Erwägen Sie die „Sperren“-Funktion (Lock), um Änderungen vorübergehend einzufrieren.
Verwenden Sie Berechtigungen auf Branch-Ebene, um einzuschränken, wer PRs für sensible Branches erstellen oder abschließen darf, und trennen Sie die Aufgaben zwischen Entwicklern und Release Managern.

Automatisierung, Hooks, große Dateien und Sicherheit

Git-Hooks erhöhen die Qualität an den Rändern des Entwicklungsprozesses:

Pre-Commit-Hooks erzwingen lokal Linting, Formatierung, die Überprüfung auf Secrets und Unit-Tests, bevor ein Entwickler einen Commit erstellt. Halten Sie diese schnell und deterministisch.
Pre-Push-Hooks blockieren das Pushen von Code, der Integrations- oder Richtlinientests nicht besteht. Stellen Sie teamweite Hook-Skripte über Tools (z. B. Husky für JavaScript) bereit und dokumentieren Sie die optionale Teilnahme (Opt-in).
Serverseitige Hooks in Managed Services unterscheiden sich: GitHub unterstützt serverseitige Webhooks und erforderliche Statusprüfungen; Azure DevOps Services erlaubt keine benutzerdefinierten serverseitigen Hooks, unterstützt aber Branch-Richtlinien, Build-Validierungen, Service-Hooks und Statusprüfen von externen Systemen. In Azure DevOps Server (On-Premise) sind serverseitige Hooks möglich.

Large File Storage (Git LFS) speichert große Binärdateien außerhalb der Git-Objektdatenbank, um die Performance des Repositories zu erhalten:

Verfolgen Sie Muster mit

undefined

oder bestimmte Typen von Binärdateien. Committen Sie die .gitattributes-Datei, damit alle Mitwirkenden LFS konsistent anwenden.

Migrieren Sie den Verlauf, indem Sie

undefined

mit Pfadfiltern ausführen, um große Binärdateien in Pointer umzuschreiben. Stimmen Sie sich mit dem Team ab und pausieren Sie Pushes; führen Sie Force-Pushes vorsichtig durch und aktualisieren Sie die Klone.

Verwalten Sie die Bandbreite, indem Sie unnötiges „Smudging“ (das Ersetzen von Pointern durch die eigentlichen Dateiinhalte) vermeiden. Verwenden Sie

undefined

und führen Sie

undefined

selektiv aus. Cachen Sie LFS in der CI und ziehen Sie Artefakt-Repositories für Binärdateien in Betracht, die nicht in Git gespeichert werden müssen.

Die Gewährleistung der Sicherheit sollte nach dem Shift-Left-Prinzip erfolgen und richtlinienbasiert sein:

GitHub Advanced Security (GHAS) bietet Secret-Scanning (einschließlich Push-Schutz), Code-Scanning mit CodeQL und Dependency-Review, um offengelegte Anmeldeinformationen, Code-Schwachstellen und Supply-Chain-Risiken zu erkennen. Erzwingen Sie diese als erforderliche Prüfungen für PRs. Für Azure Repos verwenden Sie Advanced Security for Azure DevOps, um ähnliches Secret-Scanning, SAST über CodeQL und Einblicke in Abhängigkeiten zu erhalten.
Das Secret-Scanning sollte so konfiguriert sein, dass es Pushes mit Secrets hoher Konfidenz blockiert und die zuständigen Sicherheitsteams benachrichtigt. Unterstützen Sie benutzerdefinierte Detektoren für unternehmensspezifische Muster.
Das CodeQL Code-Scanning sollte bei pull_request- und schedule-Triggern ausgeführt werden und die SARIF-Ergebnisse als Statusprüfungen hochladen. Passen Sie die Query-Packs an, um das Rauschen zu reduzieren und die Abdeckung kritischer Codepfade zu erzwingen.
Der Dependency-Review macht Versionsänderungen und bekannte Sicherheitshinweise während des PR-Reviews sichtbar; nutzen Sie dies für SLAs zur Problembehebung und für die Lizenz-Governance.

Migration, Versionierung und Release-Management

Die Migration von TFVC zu Git erfordert eine Strategie und Werkzeuge, die auf die Risikotoleranz abgestimmt sind:

Für eine originalgetreue Migration mit tiefem Verlauf und Verknüpfung von Arbeitselementen verwenden Sie git-tfs, um TFVC-Pfade nach Git zu klonen, wobei Changesets erhalten und Benutzer zugeordnet werden. Partitionieren Sie nach Anwendung oder Branch, um die Git-Repos handhabbar zu halten. Bereinigen Sie große Binärdateien mit LFS während oder nach der Migration.
Für eine schlanke Migration des aktuellen Zustands verwenden Sie das Azure DevOps Import-Tool, um ein neues Git-Repo aus TFVC (oder einem anderen Git-Host) zu initialisieren, wobei der Verlauf optional begrenzt wird. Dies reduziert die Dauer und das Risiko, verzichtet aber auf eine tiefe historische Granularität.
Behalten Sie die Nachverfolgbarkeit bei, indem Sie Tags/Labels migrieren, TFVC-Branches auf Git-Branches abbilden und einen schreibgeschützten TFVC-Spiegel für Audits beibehalten. Validieren Sie mit einem Pilotprojekt, frieren Sie den Quellcode während der Umstellung ein und führen Sie eine Verifizierungsmatrix (Builds, Tests und Deployment) durch.

Übernehmen Sie die semantische Versionierung für Klarheit und Automatisierung:

Verwenden Sie SemVer 2.0.0: MAJOR.MINOR.PATCH mit optionaler Vorabversion (z. B. -rc.1) und Build-Metadaten (+build.45). Kennzeichnen Sie Releases mit annotierten Tags (

undefined

) und signieren Sie Tags für Audits.

Automatisieren Sie Versionserhöhungen in CI/CD:
- Leiten Sie die Version aus Commits mit Conventional Commits und einem Release-Tool (z. B. GitVersion oder semantic-release) ab, um die nächste Version basierend auf Commit-Typen und -Scopes zu berechnen.
- Aktualisieren Sie Build-Nummern und Paketversionen automatisch; lassen Sie den Build fehlschlagen, wenn Versionsabweichungen oder Tag-Konflikte auftreten.
Gleichen Sie die Versionierung mit dem Branching-Modell ab:
- Trunk-basierte Entwicklung: main ist immer releasefähig; erstellen Sie Release-Tags von main; verwenden Sie kurzlebige Release-Branches nur zur Stabilisierung.
- GitFlow: release/*-Branches tragen eine eingefrorene Minor-Version; hotfix/*-Branch von main für dringende Patches; zurück in develop und main mergen und bei Abschluss des Merges taggen.
- GitHub Flow: main beim Deployment taggen; Vorabversions-Tags für Canaries verwenden.

Integrieren Sie die Release-Automatisierung mit Repository-Richtlinien: Fordern Sie erfolgreiche Builds mit Release-Pipelines, blockieren Sie Merges ohne aktualisierte, aus Commits generierte Changelogs und verlangen Sie signierte Commits/Tags in regulierten Umgebungen.

Praktisches Problemszenario

Starbucks muss mehrere in TFVC verwaltete Altanwendungen in Azure Repos Git konsolidieren und dabei einheitliche Governance, Sicherheitsscans und skalierbare Workflows für Dienste und mobile Apps etablieren.

Branching- und Repository-Topologie auswählen

Aktion: Trunk-basierte Entwicklung mit einem Monorepo für gemeinsam genutzte Bibliotheken und einigen fokussierten Service-Repos für unabhängig veröffentlichte Dienste einführen. Sparse Checkout für das Monorepo in den Onboarding-Skripten für Entwickler aktivieren.
Warum: Trunk-basierte Entwicklung reduziert den Merge-Aufwand und beschleunigt die Integration; das Monorepo zentralisiert gemeinsam genutzten Code und ermöglicht atomare Refactorings, während Sparse Checkout den Overhead des vollständigen Verlaufs und des Arbeitsverzeichnisses für Teams vermeidet, die nur Teilbereiche bearbeiten.

TFVC-Projekte nach Git migrieren und den Verlauf dort beibehalten, wo er einen Mehrwert bietet

Aktion: Verwenden Sie git-tfs, um die Haupt-Codebasen für Web und Mobile mit vollständigem Verlauf zu migrieren und dabei große Asset-Pfade während der Migration auf Git LFS abzubilden. Für kleine Hilfsprogramme verwenden Sie das Azure DevOps Import-Tool, um nur den aktuellen Zustand zu übernehmen.
Warum: git-tfs bewahrt die kritische Nachverfolgbarkeit für Flaggschiff-Anwendungen; die selektive Nutzung des Import-Tools beschleunigt risikoarme Migrationen und reduziert die Projektdauer.

Geschützte Branches und Branch-Richtlinien einrichten

Aktion: Schützen Sie main und release/* mit einem Verbot von Force Push/Löschen; fordern Sie zwei Reviewer, die Auflösung aller Kommentare, die Verknüpfung eines Arbeitselements und die Validierung durch einen erfolgreichen Build mit Pfadfiltern. Beschränken Sie Merges auf Squash für Service-Repos und auf Rebase mit Fast-Forward für das Monorepo, um einen linearen Verlauf beizubehalten. Deaktivieren Sie „Richtlinien umgehen“ außer für eine kleine Release-Engineering-Gruppe.
Warum: Policy-as-Code härtet Qualitäts-Gates und die Auditierbarkeit. Merge-Strategien spiegeln die Präferenzen des Teams wider: Squash vereinfacht das Rückgängigmachen und Cherry-Picking für Dienste; ein linearer Verlauf im Monorepo beschleunigt blame- und bisect-Operationen.

Pull-Request-Praxis standardisieren

Aktion: Fügen Sie pull_request_template.md unter .azuredevops/ mit Abschnitten für Risiko, Testnachweise, Leistungsauswirkungen und Rollback hinzu. Fördern Sie frühzeitig Draft-PRs; aktivieren Sie die Auto-Vervollständigung für alle PRs. Konfigurieren Sie pfadbasierte erforderliche Reviewer, um Code-Eigentümerschaft nachzubilden, und fügen Sie CODEOWNERS für auf GitHub gehostete Repos hinzu.
Warum: Vorlagen heben das Mindestniveau für die Review-Qualität an; Draft-PRs fördern die frühzeitige Zusammenarbeit; die Auto-Vervollständigung eliminiert Leerlaufzeiten; Ownership-Routing leitet die richtigen Reviewer zu den richtigen Diffs.

Hooks und CI-Gates implementieren

Aktion: Verteilen Sie pre-commit/pre-push-Hooks über Repo-Tools, um Linting, Überprüfungen auf Secrets und Unit-Tests zu erzwingen; halten Sie die Ausführung schnell. Verwenden Sie die Build-Validierung von Azure Pipelines als kanonische Durchsetzung und fügen Sie Statusprüfungen von Sicherheitsscannern hinzu. Vermeiden Sie benutzerdefinierte serverseitige Hooks; verwenden Sie Service-Hooks, um externe Systeme zu benachrichtigen.
Warum: Lokale Hooks fangen Probleme frühzeitig ab, ohne die Zusammenarbeit zu blockieren; die serverseitige Durchsetzung in Azure DevOps wird am besten mit Branch-Richtlinien und Statusprüfungen für Zuverlässigkeit und Auditierbarkeit erreicht.

Große Assets mit Git LFS verwalten

Aktion: Verfolgen Sie binäre Muster (Bilder, Design-Assets, Testmedien) mit

undefined

; migrieren Sie ältere Binärdateien mit

undefined

. Konfigurieren Sie die CI so, dass

undefined

gesetzt wird und selektiv abgerufen wird, um die Bandbreite zu reduzieren; cachen Sie LFS-Artefakte auf Build-Agents.

Warum: Hält Repos schnell und vermeidet übermäßige Netzwerknutzung, während reproduzierbare Builds erhalten bleiben.

Advanced Security integrieren

Aktion: Aktivieren Sie GitHub Advanced Security für GitHub-Repos und Advanced Security for Azure DevOps für Azure Repos. Schalten Sie das Secret-Scanning mit Push-Schutz ein, führen Sie CodeQL bei PRs und nächtlich aus und aktivieren Sie Überprüfungen der Abhängigkeiten. Blockieren Sie den Abschluss von PRs bei Ergebnissen mit hohem Schweregrad.
Warum: Verlagert die Sicherheit nach links („Shift Left“), verhindert den Abfluss von Anmeldeinformationen und das Einchecken ausnutzbarer Muster in main und liefert umsetzbare Einblicke während des Reviews.

Semantische Versionierung und Tagging automatisieren

Aktion: Verwenden Sie GitVersion in Azure Pipelines, um SemVer aus dem Branch- und Commit-Verlauf zu berechnen; signieren und pushen Sie annotierte Tags in Release-Pipelines; generieren Sie Release Notes aus Conventional Commits. Verwenden Sie release/*-Branches nur zur Stabilisierung; Hotfixes von einem getaggten main-Branch.
Warum: Deterministische, automatisierte Versionen verbessern die Nachverfolgbarkeit und die Reproduzierbarkeit von Deployments, und signierte Tags unterstützen die Compliance.

Diese Abfolge senkt das Migrationsrisiko, erzwingt konsistente Qualität und Sicherheit und optimiert die Auslieferung – und bringt so das Repository-Management präzise mit skalierbaren DevOps-Operationen in Einklang.

Alle Domänen · CI →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →