Microsoft AZ-400: Broncodebeheer en Repositorybeheer — Studiegids

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

Onderdeel van de Microsoft DevOps Engineer Expert AZ-400 — Studiegids. Oefen met geverifieerde antwoorden in het Microsoft-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Moderne DevOps-praktijken zijn afhankelijk van voorspelbaar, collaboratief broncodebeheer en gedisciplineerd repository-beheer. Azure Repos en GitHub bieden complementaire mogelijkheden voor versiebeheer, beleidshandhaving, samenwerking en beveiliging. Beheersing van branching-strategieën, pull request-workflows, permissies, hooks, de omgang met grote bestanden, migratiepatronen, beveiligingsscans en versiebeheer is essentieel voor veerkrachtige delivery pipelines en auditeerbaarheid. Het doel is niet alleen om code op te slaan, maar om een afdwingbaar, geautomatiseerd systeem van controles te creëren dat de doorvoercapaciteit van het team schaalt zonder in te boeten aan kwaliteit.

Fundamenten van Broncodebeheer in Azure Repos en GitHub

Azure Repos ondersteunt Git en Team Foundation Version Control (TFVC). Git is gedistribueerd, maakt lokale commits, eenvoudig branchen en gedecentraliseerde workflows mogelijk. TFVC is gecentraliseerd met server-side versiebeheer, ’locked check-outs’ (optioneel), en is zeer geschikt voor legacy-oplossingen met zeer grote binaire assets of voor teams die getraind zijn in gecentraliseerde workflows. Nieuwe ontwikkeling zou standaard Git moeten gebruiken; TFVC blijft een haalbare optie wanneer incrementele wijzigingscontrole en centrale permissies van het grootste belang zijn en de migratiekosten onbetaalbaar zijn.

Kies bewust een branching-strategie:

Trunk-based development geeft de voorkeur aan één langlevende ‘main’-branch met zeer kortlevende feature-branches en continue integratie. Dit versnelt de doorstroom, vermindert ‘merge debt’ en is ideaal voor teams met een hoge cadans en sterke testautomatisering.
GitFlow gebruikt langlevende ‘develop’- en ‘main’ (release)-branches, met feature-, release- en hotfix-branches. Het is geschikt voor producten met formele ‘release trains’ en de noodzaak voor ‘backporting’, maar voegt coördinatie-overhead toe.
GitHub Flow is een vereenvoudigd model met één ‘main’-branch, kortlevende topic-branches, continue deployment en frequente releases. Het is effectief voor services die continu worden uitgeleverd.

Monorepo versus multi-repo is voornamelijk een organisatorische en tooling-keuze:

Monorepo consolideert vele componenten in één repository, wat atomische cross-service wijzigingen, uniforme refactoring en gedeelde tooling vergemakkelijkt. Het kan Git-operaties belasten naarmate de geschiedenis groeit. Mitigatietechnieken omvatten ‘sparse checkout’, ‘partial clone’ en CI-padfilters om builds en tests af te bakenen.
Multi-repo isoleert eigenaarschap, geschiedenis en permissiegrenzen, wat onafhankelijke versiebeheer en retentie vergemakkelijkt. Het kan de coördinatie tussen repo’s en ‘dependency drift’ vergroten; submodules of dependency managers en release-orkestratie zijn cruciaal.

Eigenaarschap en het routeren van wijzigingen profiteren van declaraties voor code-eigenaarschap. Het CODEOWNERS-bestand van GitHub wijst paden automatisch toe aan verplichte reviewers. Gebruik in Azure Repos pad-gebaseerde vereiste reviewers in branch-beleid (en CODEOWNERS waar ingeschakeld) om reviews naar componentteams te routeren. Vul eigenaarschap aan met naamgevingsconventies voor branches, duidelijke commit-berichten (bijv. Conventional Commits) en repository-sjablonen voor consistentie.

Governance: Beleid, Permissies en Pull Requests

Branch-beleid in Azure Repos codificeert kwaliteitspoorten:

Vereiste reviewers dwingen een minimumaantal reviewers af en kunnen specifieke personen/groepen of pad-gebaseerde auto-reviewers omvatten. Vereis dat opmerkingen zijn opgelost om ervoor te zorgen dat inhoudelijke feedback wordt verwerkt vóór de merge.
Build-validatie vereist dat een of meer CI-pipelines slagen vóór de merge. Gebruik padfilters om onnodige builds te vermijden en stel automatische triggering in bij nieuwe updates. Integreer externe controles via statusbeleid voor beveiligingsscans of prestatietests.
Merge-strategieën kunnen worden beperkt: Merge (no fast-forward) legt de merge-geschiedenis vast; Squash voegt wijzigingen samen tot één commit, waardoor de geschiedenis lineair blijft; Rebase and fast-forward herschrijft de topic-branch bovenop ‘main’ voor een rechte geschiedenislijn; Rebase and merge speelt commits opnieuw af en behoudt afzonderlijke commits zonder een merge-commit. Stem de strategie af op auditbehoeften en downstream tooling.
Aanvullende controles omvatten vereiste gekoppelde werkitems, een minimumaantal succesvolle stemmen en blokkeren als er actieve opmerkingen of wachtende reviewers zijn.

Pull requests orkestreren het integratiegesprek:

Concept-PR’s signaleren werk in uitvoering en blokkeren voltooiing totdat ze als gereed zijn gemarkeerd. Moedig vroege feedback aan zonder beleid voortijdig te activeren.
Automatisch voltooien merget automatisch zodra al het beleid is goedgekeurd, wat de coördinatielatentie vermindert en de doorstroom verhoogt.
De optie om beleid te omzeilen bestaat voor noodsituaties of automation-accounts. Beperk dit met de permissie “Bypass policies when completing pull requests” en auditeer via goedkeuringen en change management.
PR-sjablonen standaardiseren de context: bewijs van testen, risiconotities, deployment-stappen en een roll-back plan. Plaats in Azure Repos pull_request_template.md in de root van de repo of in .azuredevops/. Zorg voor checklists voor beveiliging, prestaties en documentatie.

Permissies en beschermde branches zijn je laatste verdedigingslinie:

Gebruik Azure DevOps RBAC-groepen (Project Administrators, Contributors, Readers) en fijnmazige repo-permissies (Create branch, Create tag, Contribute, Force push, Manage permissions, Bypass policies). Geef de voorkeur aan ‘allow’/‘deny’ op groepen in plaats van op individuen.
Bescherm ‘main’- en release-branches door Force push en Delete te weigeren, Contribute te beperken tot alleen PR-merges, en branch-beleid in te schakelen dat builds en reviews vereist. Overweeg “Lock” om wijzigingen tijdelijk te bevriezen.
Gebruik permissies op branch-niveau om te beperken wie PR’s kan aanmaken of voltooien voor gevoelige branches, en scheid de taken tussen ontwikkelaars en release managers.

Automatisering, Hooks, Grote Bestanden en Beveiliging

Git hooks verhogen de kwaliteit aan de randen van het proces:

Pre-commit hooks dwingen lokaal linting, formattering, secret checks en unit tests af voordat een ontwikkelaar een commit vastlegt. Houd ze snel en deterministisch.
Pre-push hooks blokkeren het pushen van code die niet door integratietests of beleidscontroles komt. Lever team-brede hook-scripts aan via tooling (bijv. Husky voor JavaScript) en documenteer de opt-in.
Server-side hooks in beheerde services verschillen: GitHub ondersteunt server-webhooks en vereiste statuscontroles; Azure DevOps Services staat geen aangepaste server-side hooks toe, maar ondersteunt branch policies, build validations, service hooks en statuscontroles van externe systemen. In Azure DevOps Server (on-prem) zijn server-hooks wel mogelijk.

Large File Storage (Git LFS) slaat grote binaire bestanden op buiten de Git object database, waardoor de repo performant blijft:

Volg patronen met git lfs track “*.psd” of specifieke binaire bestandstypen. Commit het .gitattributes-bestand zodat alle bijdragers LFS consistent toepassen.
Migreer de geschiedenis door git lfs migrate import uit te voeren met padfilters om grote binaire bestanden te herschrijven naar pointers. Coördineer met het team en pauzeer pushes; gebruik force-push voorzichtig en update de klonen.
Beheer bandbreedte door onnodig ‘smudging’ te vermijden. Gebruik GIT_LFS_SKIP_SMUDGE=1 en voer git lfs fetch/pull selectief uit. Cache LFS in CI en overweeg artifact repositories voor binaire bestanden die niet in Git hoeven te staan.

Beveiligingsgarantie moet ‘shift-left’ en beleidsgestuurd zijn:

GitHub Advanced Security (GHAS) biedt secret scanning (inclusief push protection), code scanning met CodeQL en dependency review om blootgestelde credentials, kwetsbaarheden in code en supply-chain risico’s te ondervangen. Dwing dit af als vereiste controles op PR’s. Gebruik voor Azure Repos Advanced Security for Azure DevOps om vergelijkbare secret scanning, SAST via CodeQL en dependency inzichten te realiseren.
Secret scanning moet geconfigureerd worden om pushes met ‘high-confidence secrets’ te blokkeren en security responders te waarschuwen. Ondersteun aangepaste detectoren voor organisatiespecifieke patronen.
CodeQL code scanning moet draaien op pull_request en schedule triggers, en SARIF-resultaten uploaden als statuscontroles. Stem query packs af om ruis te verminderen en dekking op kritieke paden af te dwingen.
Dependency review toont versiewijzigingen en bekende adviezen tijdens de PR-review; gebruik dit voor remediation SLA’s en licentiebeheer.

Migratie, Versiebeheer en Release Management

Migreren van TFVC naar Git vereist een strategie en tooling die zijn afgestemd op de risicotolerantie:

Voor een migratie met volledige getrouwheid (‘full-fidelity’) met diepgaande geschiedenis en koppeling van work items, gebruik git-tfs om TFVC-paden te klonen naar Git, waarbij changesets behouden blijven en gebruikers worden gemapt. Partitioneer per applicatie of branch om Git-repo’s beheersbaar te houden. Ruim grote binaire bestanden op met LFS tijdens of na de migratie.
Voor een lichtgewicht migratie van de huidige staat, gebruik de Azure DevOps Import-tool om een nieuwe Git-repo te ‘seeden’ vanuit TFVC (of een andere Git-host), waarbij de geschiedenis optioneel beperkt kan worden. Dit vermindert de doorlooptijd en het risico, maar offert diepgaande historische granulariteit op.
Behoud traceerbaarheid door tags/labels te migreren, TFVC-branches te mappen naar Git-branches en een read-only TFVC-mirror te behouden voor auditdoeleinden. Valideer met een pilot, bevries de broncode tijdens de overgang (‘cutover’), en voer een verificatiematrix uit (builds, tests en deployment).

Adopteer semantisch versiebeheer (semantic versioning) voor duidelijkheid en automatisering:

Gebruik SemVer 2.0.0: MAJOR.MINOR.PATCH met optionele pre-release (bijv. -rc.1) en build-metadata (+build.45). Tag releases met geannoteerde tags (git tag -a v1.4.2 -m “Release 1.4.2”) en onderteken tags voor auditdoeleinden.
Automatiseer versie-ophogingen in CI/CD:
- Stuur de versie aan vanuit commits met Conventional Commits en een release-tool (bijv. GitVersion of semantic-release) om de volgende versie te berekenen op basis van commit-types en scopes.
- Werk build-nummers en pakketversies automatisch bij; laat de build falen als er versie-afwijkingen (‘version drift’) of tag-conflicten optreden.
Lijn versiebeheer uit met branching-strategieën:
- Trunk-based: main is altijd releasebaar; maak release-tags aan vanuit main; gebruik kortlevende release-branches alleen voor stabilisatie.
- GitFlow: release/-branches bevatten een bevroren minor-versie; hotfix/-branch vanuit main voor urgente patches; merge terug naar zowel develop als main en tag na voltooiing van de merge.
- GitHub Flow: tag main bij deployment; gebruik pre-release tags voor canaries.

Integreer release-automatisering met repository-beleid (‘policies’): vereis ‘groene’ builds met release-pipelines, blokkeer merges zonder bijgewerkte changelogs die zijn gegenereerd uit commits, en vereis ondertekende commits/tags in gereguleerde omgevingen.

Praktijkscenario

Starbucks moet meerdere legacy-applicaties die in TFVC worden beheerd, consolideren naar Azure Repos Git. Tegelijkertijd moeten ze uniforme governance, security scanning en schaalbare workflows opzetten voor zowel services als mobiele apps.

Kies branching- en repository-topologie

Actie: Adopteer trunk-based development met een monorepo voor gedeelde libraries en enkele gefocuste service-repo’s voor onafhankelijk gereleasete services. Schakel sparse checkout in voor de monorepo in onboarding-scripts voor ontwikkelaars.
Waarom: Trunk-based vermindert ‘merge debt’ en versnelt integratie; een monorepo centraliseert gedeelde code en maakt atomische refactors mogelijk, terwijl sparse checkout de overhead van volledige geschiedenis en working tree vermijdt voor teams die slechts aan subsets werken.

Migreer TFVC-projecten naar Git met behoud van geschiedenis waar dit waarde toevoegt

Actie: Gebruik git-tfs om de belangrijkste web- en mobiele codebases met volledige geschiedenis te migreren, waarbij paden naar grote assets tijdens de migratie worden gemapt naar Git LFS. Gebruik voor kleine utilities de Azure DevOps Import-tool om alleen de huidige staat over te zetten.
Waarom: git-tfs behoudt kritieke traceerbaarheid voor de belangrijkste applicaties (‘flagship apps’); selectief gebruik van de Import-tool versnelt migraties met een laag risico en verkort de projectduur.

Stel beveiligde branches en branch-beleid in

Actie: Beveilig main en release/* met een verbod op Force push/Delete; vereis twee reviewers, het oplossen van alle opmerkingen, het koppelen van een work item en een geslaagde build-validatie met padfilters. Beperk merges tot Squash voor service-repo’s en Rebase en fast-forward voor de monorepo om een lineaire geschiedenis te behouden. Schakel ‘Bypass policies’ uit, behalve voor een kleine release-engineering groep.
Waarom: Policy-as-code versterkt kwaliteitscontroles (‘quality gates’) en auditeerbaarheid. Merge-strategieën weerspiegelen teamvoorkeuren: Squash vereenvoudigt revert en cherry-pick voor services; een lineaire geschiedenis in de monorepo versnelt blame- en bisect-operaties.

Standaardiseer de werkwijze voor pull requests

Actie: Voeg pull_request_template.md toe onder .azuredevops/ met secties voor risico, testbewijs, performance-impact en rollback. Moedig het vroege gebruik van Draft PR’s aan; schakel Auto-complete in voor alle PR’s. Configureer pad-gebaseerde verplichte reviewers om code-eigenaarschap na te bootsen, en voeg CODEOWNERS toe voor repo’s die op GitHub worden gehost.
Waarom: Templates verhogen de basiskwaliteit van reviews; Draft PR’s bevorderen vroege samenwerking; Auto-complete elimineert wachttijd; routering op basis van eigenaarschap zorgt ervoor dat de juiste reviewers naar de juiste diffs kijken.

Implementeer hooks en CI-gates

Actie: Distribueer pre-commit/pre-push hooks via repo-tooling om linting, secrets-controles en unit tests af te dwingen; houd de uitvoering snel. Gebruik Azure Pipelines build-validatie als de canonieke handhaving en voeg statuscontroles van security scanners toe. Vermijd custom server-side hooks; gebruik service hooks om externe systemen te notificeren.
Waarom: Lokale hooks vangen problemen vroegtijdig op zonder de samenwerking te blokkeren; server-side handhaving in Azure DevOps wordt het best bereikt met branch-beleid en statuscontroles voor betrouwbaarheid en audit.

Beheer grote assets met Git LFS

Actie: Volg binaire patronen (afbeeldingen, design-assets, testmedia) met git lfs track; migreer legacy binaire bestanden met git lfs migrate import. Configureer CI om GIT_LFS_SKIP_SMUDGE=1 in te stellen en selectief te fetchen om bandbreedte te verminderen; cache LFS-artefacten op build agents.
Waarom: Houdt repo’s snel en voorkomt overmatig netwerkgebruik, terwijl reproduceerbare builds behouden blijven.

Integreer Advanced Security

Actie: Schakel GitHub Advanced Security in op GitHub-repo’s en Advanced Security for Azure DevOps op Azure Repos. Activeer secret scanning met push protection, voer CodeQL uit op PR’s en ’s nachts, en schakel dependency review-controles in. Blokkeer de voltooiing van PR’s bij bevindingen met een hoge ernstgraad (‘high-severity’).
Waarom: Verschuift security naar links in het proces (‘shifts security left’), waardoor het lekken van credentials en kwetsbare patronen in de main-branch wordt voorkomen, met bruikbare inzichten tijdens de review.

Automatiseer semantisch versiebeheer en tagging

Actie: Gebruik GitVersion in Azure Pipelines om SemVer te berekenen op basis van de branch- en commit-geschiedenis; onderteken en push geannoteerde tags in release-pipelines; genereer release notes vanuit Conventional Commits. Gebruik release/*-branches alleen voor stabilisatie; maak hotfixes vanuit een getagde main-branch.
Waarom: Deterministische, geautomatiseerde versies verbeteren de traceerbaarheid en de reproduceerbaarheid van deployments, en ondertekende tags ondersteunen compliance.

Deze volgorde verlaagt het migratierisico, dwingt consistente kwaliteit en security af, en stroomlijnt de levering — waardoor repository management nauwkeurig wordt afgestemd op schaalbare DevOps-operaties.

Alle domeinen · CI →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →