Azure DevOps is het platform dat Microsoft aanbiedt voor het beheren van de volledige software-ontwikkelketen: versiebeheer, CI/CD-pipelines, projectplanning, package-feeds en documentatie. In dit eerste deel van de serie bouwen we de basis op: een Git-repository, branch-beveiliging en de Pull Request workflow.

Voorbereiding: organisatie en project

Na het inloggen op dev.azure.com is de organisatie mvdboom zichtbaar met één bestaand project.

mvdboom organisatie met test_hello_world project

Bij het openen van dat project bleek het een TFVC-project te zijn — het verouderde gecentraliseerde versiebeheersysteem van Microsoft. TFVC-projecten gebruiken $/projectnaam-paden in plaats van Git-branches en werken met changesets en shelvesets. Voor moderne DevOps-workflows is Git de standaard.

TFVC repo met dollar-teken pad en changesets in de sidebar

TFVC-projecten zijn niet om te zetten naar Git. Daarom is een nieuw project dev-ops-lab01 aangemaakt als Private project met Git als versiebeheersysteem.

Leeg dev-ops-lab01 project met de vijf ADO-services zichtbaar

Azure DevOps Repos

Bij het openen van Repos toont ADO een lege repository met drie opties om te starten: lokaal clonen, een bestaande repo pushen, of direct in de browser initialiseren met een README. De sidebar toont de Git-specifieke onderdelen: Files, Commits, Pushes, Branches, Tags, Pull requests en Advanced Security.

Lege Git repo met clone- en initialisatieopties

Via Initialize (met README aangevinkt) wordt de main-branch aangemaakt. De eerste commit — 924f2a1b: Added README.md — is direct zichtbaar inclusief auteur en tijdstip.

Geïnitialiseerde repo met README.md op main

Branch policies op main

Een productieomgeving staat nooit directe pushes naar main toe. Via Branches → ⋯ → Branch policies op de main-branch opent het policies-scherm.

Branches-overzicht met main als Default branch

Branch policies pagina voor main, alle toggles uit

De vier beschikbare policies:

  • Require a minimum number of reviewers — blokkeert merge zonder approval
  • Check for linked work items — vereist koppeling aan een Board-item voor traceerbaarheid
  • Check for comment resolution — alle review-opmerkingen moeten opgelost zijn
  • Limit merge types — dwingt een specifieke merge-strategie af (squash, rebase, etc.)

Daaronder staan Build Validation (pipeline moet slagen vóór merge), Status Checks (externe tools zoals SonarQube) en Automatically included reviewers.

Na het inschakelen van de eerste policy verschijnen de bijbehorende opties.

Reviewer-policy ingeschakeld met de detailopties zichtbaar

Voor de lab-omgeving is de policy ingesteld op minimum 1 reviewer met “Allow requestors to approve their own changes” aangevinkt — zodat de volledige workflow doorlopen kan worden zonder een tweede account.

Reviewer-policy ingesteld op 1, eigen approval toegestaan

Zodra een required policy actief is, geldt automatisch: directe push naar main is geblokkeerd, alles gaat via een Pull Request.

Feature branch en eerste commit

Vanuit de Files-weergave is via de branch-selector een nieuwe branch feature/add-pipeline aangemaakt. De naam volgt de gangbare conventie: feature/ als prefix gevolgd door een beschrijvende naam.

Repo op feature/add-pipeline branch

Via + New → File is het bestand azure-pipelines.yml aangemaakt en direct in de browser ingetypt.

Lege bestandseditor voor azure-pipelines.yml

 1trigger:
 2  - main
 3
 4pool:
 5  vmImage: 'windows-latest'
 6
 7steps:
 8  - task: PowerShell@2
 9    displayName: 'Systeeminformatie'
10    inputs:
11      targetType: 'inline'
12      script: |
13        Write-Host "Hostname: $env:COMPUTERNAME"
14        Write-Host "OS: $env:OS"
15        Write-Host "Build nummer: $(Build.BuildNumber)"
16        Write-Host "Branch: $(Build.SourceBranchName)"

Na het opslaan via Commit staat de wijziging op de feature branch. ADO suggereert direct bovenaan: “Create a pull request”.

azure-pipelines.yml gecommit op feature/add-pipeline

Pull Request workflow

Bij het aanmaken van de Pull Request toont ADO automatisch de juiste richting: feature/add-pipeline → main. De tabs Files 1 en Commits 1 bevestigen de omvang van de wijziging.

Nieuw PR-formulier met titel, beschrijving en reviewervelden

Na het aanmaken staat de PR in de Active status. De branch policy is direct zichtbaar als blokkerende check:

  • 🔵 At least 1 reviewer must approve — merge geblokkeerd
  • ✅ No merge conflicts — branch is schoon

PR open met reviewer-check geblokkeerd

Via Approve wordt de PR goedgekeurd. Beide checks worden groen en de Complete-knop wordt actief.

PR approved, beide checks groen, Complete-knop actief

Bij Complete verschijnt het merge-dialoog met de keuze uit vier merge-typen:

TypeGedrag
Merge (no fast forward)Altijd een merge-commit, branch-history blijft zichtbaar in de grafiek
Squash commitAlle commits samengeperst tot één commit op main
Rebase and fast forwardCommits lineair bovenop main, geen merge-commit
Semi-linear mergeEerst rebase, dan merge-commit

De standaardkeuze Merge (no fast forward) is in de meeste omgevingen de juiste keuze. Delete feature/add-pipeline after merging staat standaard aangevinkt — goede praktijk om de repository opgeruimd te houden.

Complete merge dialoog met merge-type dropdown

Na Complete merge toont de PR de status Completed met de volledige audit trail: aangemaakt → reviewer toegevoegd → approved → completed.

Completed PR met volledige audit trail

Wat is bereikt

Na dit eerste deel staat de volgende basis:

  • Een Git-repository in Azure DevOps (niet TFVC)
  • Branch policy op main: directe push geblokkeerd, alles via PR
  • Feature branch workflow: feature/add-pipeline aangemaakt, bestand gecommit
  • Volledige Pull Request doorlopen: aanmaken → reviewen → approven → mergen

Het bestand azure-pipelines.yml staat nu in main. In deel 2 koppelen we hier een pipeline aan en laten we de YAML daadwerkelijk draaien op een Microsoft-hosted agent.