Samenwerken op een semantisch model met Git en Azure DevOps

Power BI is van oorsprong een single-user tool. Je opent een .pbix-bestand, maakt je wijzigingen, en slaat op. Maar zodra je met meerdere ontwikkelaars aan hetzelfde model werkt, loopt dat vast. Wie heeft de laatste versie? Wie heeft wat aangepast? En hoe merge je twee parallelle wijzigingen zonder dat je elkaars werk overschrijft?

Sinds Power BI Desktop het .pbip-formaat ondersteunt, is er een serieus antwoord: versiebeheer met Git. In combinatie met Azure DevOps Repos krijg je branching, pull requests, code reviews en een volledige wijzigingshistorie -- precies zoals software-ontwikkelaars al jaren werken.

Het probleem met .pbix

Een .pbix-bestand is een binair ZIP-archief. Git kan daar niet mee overweg: het ziet het hele bestand als een blob, niet als losse onderdelen. Twee ontwikkelaars die tegelijk aan hetzelfde .pbix werken, kunnen hun wijzigingen niet samenvoegen. Je bent veroordeeld tot "ik was er eerst" of handmatig copy-pasten van measures en tabellen.

Dat is precies waarom Microsoft het .pbip-formaat heeft geïntroduceerd.

Wat is het .pbip-formaat?

Een .pbip (Power BI Project) is geen enkel bestand, maar een mapstructuur met leesbare tekstbestanden. In plaats van een binaire blob krijg je losse JSON- en TMDL-bestanden (Tabular Model Definition Language) per tabel, measure, relatie en expressie.

De structuur ziet er als volgt uit:

MijnProject.pbip
MijnProject.SemanticModel/
  definition/
    model.tmdl
    tables/
      fct_Verkopen.tmdl
      dim_Product.tmdl
      dim_Datum.tmdl
      dim_Klant.tmdl
    relationships.tmdl
    expressions.tmdl
  definition.pbism
MijnProject.Report/
  definition/
    report.json
    pages/
      Pagina1/
        visuals/
          ...
  definition.pbir

Het cruciale verschil: elke tabel, elke measure-groep en elke relatie is een apart bestand. Als jij aan fct_Verkopen.tmdl werkt en je collega aan dim_Product.tmdl, raakt jullie werk elkaar niet.

.pbip inschakelen

Open Power BI Desktop en ga naar File > Options and settings > Options > Preview features. Schakel Power BI project (.pbip) save format in. Herstart Desktop.

Sla je bestand nu op via File > Save as en kies het .pbip-formaat. Je ziet dat Power BI een mapstructuur aanmaakt in plaats van een enkel bestand.

Git en Azure DevOps instellen

Nu je een mapstructuur hebt, kun je Git gebruiken. De setup:

1. Repository aanmaken

Maak een nieuwe Git-repository aan in Azure DevOps (of GitHub). Clone de repo lokaal.

git clone https://dev.azure.com/jouw-org/PowerBI/_git/SalesModel
cd SalesModel

2. .gitignore instellen

Niet alle bestanden in een .pbip-project horen in Git. Voeg een .gitignore toe:

# Power BI lokale cache
.pbi/
*.pbix

# Lokale settings
localSettings.json

# OS bestanden
.DS_Store
Thumbs.db

3. Project toevoegen en committen

Kopieer je .pbip-project naar de repo-map en maak je eerste commit:

git add .
git commit -m "Initieel semantisch model: star schema met 4 dimensies"
git push origin main

Branching-strategie

Met Git kun je parallel werken op branches. Voor Power BI-projecten werkt een eenvoudige strategie het beste:

Een typische workflow:

# Nieuwe feature starten
git checkout develop
git pull origin develop
git checkout -b feature/voortschrijdend-gemiddelde

# Werk doen in Power BI Desktop...
# Wijzigingen committen
git add MijnProject.SemanticModel/
git commit -m "Voeg 3-maands voortschrijdend gemiddelde measure toe"

# Pull request aanmaken naar develop
git push origin feature/voortschrijdend-gemiddelde

In Azure DevOps maak je vervolgens een Pull Request aan. Je collega reviewt de DAX, keurt goed, en merged naar develop.

TMDL: wat zit er in die bestanden?

TMDL (Tabular Model Definition Language) is de tekstrepresentatie van je semantisch model. Elke tabel krijgt een eigen .tmdl-bestand. Hier is een voorbeeld van hoe een measure eruitziet in TMDL:

table fct_Verkopen

  measure 'Totale Omzet' =
    SUM(fct_Verkopen[Bedrag])
    formatString: #,##0
    displayFolder: Financieel

  measure '% Groei MoM' =
    VAR HuidigeMaand = [Totale Omzet]
    VAR VorigeMaand =
      CALCULATE(
        [Totale Omzet],
        DATEADD(dim_Datum[Datum], -1, MONTH)
      )
    RETURN
      DIVIDE(HuidigeMaand - VorigeMaand, VorigeMaand)
    formatString: 0.0%
    displayFolder: Financieel

Omdat dit leesbare tekst is, kan Git precies tonen wat er veranderd is. Een diff laat zien: "Er is een nieuwe measure toegevoegd" of "De formatString van Totale Omzet is gewijzigd van #,##0 naar #,##0.00".

Merge conflicts oplossen

Merge conflicts ontstaan als twee ontwikkelaars tegelijkertijd hetzelfde bestand wijzigen. Met .pbip is de kans kleiner dan met .pbix (omdat onderdelen in aparte bestanden staan), maar het kan nog steeds gebeuren.

Wanneer het misgaat: twee ontwikkelaars passen dezelfde measure aan in fct_Verkopen.tmdl.

<<<<<<< HEAD
  measure 'Totale Omzet' =
    SUM(fct_Verkopen[Bedrag])
    formatString: #,##0.00
=======
  measure 'Totale Omzet' =
    SUMX(fct_Verkopen, fct_Verkopen[Aantal] * fct_Verkopen[Prijs])
    formatString: #,##0
>>>>>>> feature/omzet-herberekening

Omdat TMDL leesbare tekst is, kun je dit handmatig oplossen in VS Code of een andere editor. Kies de juiste versie, verwijder de conflict-markers, en commit het resultaat.

Conflicts voorkomen: werkafspraken

De beste manier om merge conflicts te voorkomen is goede afspraken:

• Verdeel eigenaarschap per tabel: ontwikkelaar A werkt aan fct_Verkopen, ontwikkelaar B aan dim_Product. Zo raken jullie bestanden elkaar niet.
• Houd branches kort: een feature-branch die weken open staat, loopt gegarandeerd uit sync. Merge dagelijks of om de paar dagen naar develop.
• Pull voor je pusht: begin elke werksessie met git pull origin develop zodat je op de laatste versie werkt.
• Communiceer: als je allebei aan dezelfde tabel moet werken, spreek dan af wie eerst gaat. Klinkt ouderwets, werkt het beste.

CI/CD: automatisch deployen

Met Azure DevOps Pipelines kun je het deployment-proces automatiseren. Wanneer een pull request naar main wordt gemerged, kan een pipeline het model automatisch publiceren naar de Power BI Service.

Een basis YAML-pipeline:

trigger:
  branches:
    include:
      - main

pool:
  vmImage: 'windows-latest'

steps:
  - task: PowerShell@2
    displayName: 'Installeer Tabular Editor CLI'
    inputs:
      targetType: 'inline'
      script: |
        # Download Tabular Editor 2 portable (gratis, open source)
        Invoke-WebRequest -Uri "https://github.com/TabularEditor/TabularEditor/releases/latest/download/TabularEditor.Portable.zip" -OutFile "te2.zip"
        Expand-Archive -Path "te2.zip" -DestinationPath "$(Agent.ToolsDirectory)/TabularEditor"

  - task: PowerShell@2
    displayName: 'Deploy semantic model naar Power BI Service'
    inputs:
      targetType: 'inline'
      script: |
        $tePath = "$(Agent.ToolsDirectory)/TabularEditor/TabularEditor.exe"
        $modelPath = "$(Build.SourcesDirectory)/MijnProject.SemanticModel/definition"

        # Deploy via Tabular Editor CLI met service principal
        & $tePath `
          $modelPath `
          -S "powerbi://api.powerbi.com/v1.0/myorg/MijnWorkspace" `
          -D "SalesModel" `
          -U "app:$(SP_APP_ID)@$(TENANT_ID)" `
          -P "$(SP_SECRET)" `
          -O -C -R

Fabric Git Integration

Als je organisatie Microsoft Fabric gebruikt, is er een alternatief: Fabric Git Integration. Hiermee koppel je een Fabric workspace direct aan een Azure DevOps of GitHub repository. Wijzigingen in de workspace worden automatisch gesynchroniseerd met Git, en andersom.

Het voordeel: je hoeft niet lokaal te werken. Ontwikkelaars maken wijzigingen in de Fabric workspace, committen naar een branch, en openen een pull request -- alles vanuit de browser.

Het nadeel: je bent afhankelijk van de Fabric-omgeving en hebt minder controle over het lokale ontwikkelproces. Voor teams die gewend zijn aan lokaal werken in Desktop, is de .pbip + Git-aanpak vaak prettiger.

Recente ontwikkelingen

Het Power BI-ecosysteem rond .pbip en Git ontwikkelt zich snel. Een paar relevante updates:

• PBIR als standaard rapportformaat: sinds januari 2026 gebruiken nieuwe rapporten in de Power BI Service standaard het PBIR-formaat (Power BI Enhanced Report Format). Vanaf de maart 2026-release van Desktop geldt dit ook lokaal. PBIR slaat rapporten op als leesbare JSON-bestanden in plaats van het oude binaire formaat, wat samenwerking via Git verder verbetert.
• TMDL View is GA: de TMDL View in Power BI Desktop is sinds september 2025 Generally Available. Hiermee kun je rechtstreeks in Desktop je semantisch model bekijken en bewerken als TMDL-code, inclusief syntax highlighting voor DAX en Power Query. Sinds maart 2026 is TMDL View on the Web beschikbaar als preview.
• Fabric Git met TMDL: Fabric Git Integration schakelt over van TMSL (JSON) naar TMDL voor het exporteren van semantic model-definities. Dit maakt diffs en merges in Fabric-gekoppelde repositories aanzienlijk leesbaarder.

Best practices

• Gebruik .pbip als standaard: zodra je met meer dan een persoon aan een model werkt, stap over naar .pbip. De overhead is minimaal, het voordeel is groot.
• Schrijf duidelijke commit messages: "Fix" zegt niets. "Corrigeer YTD-berekening in Totale Omzet measure" helpt je collega's en je toekomstige zelf.
• Review DAX in pull requests: behandel measures als code. Een tweede paar ogen vangt fouten vroeg op.
• Scheid model en rapport: het semantisch model en het rapport zijn aparte mappen in .pbip. Overweeg ze in aparte repositories te zetten als ze door verschillende teams worden beheerd.
• Gebruik branch policies: stel in Azure DevOps in dat main alleen via pull requests met minimaal 1 reviewer kan worden gewijzigd. Voorkomt dat iemand per ongeluk direct naar productie pusht.
• Documenteer in de repo: voeg een README.md toe met de modelarchitectuur, naamgevingsconventies en contactpersonen.
• Test na elke merge: open het model in Desktop na een merge om te verifiëren dat alles correct laadt en de measures kloppen.

Veelgemaakte fouten

1. .pbix in Git zetten
Een binair bestand in Git is zinloos. Je krijgt geen diffs, geen merges, en je repo groeit snel naar gigabytes. Gebruik altijd .pbip.

2. Alles op main werken
Zonder branches verlies je het grootste voordeel van Git: parallel werken. Zelfs als je met twee mensen bent, gebruik branches en pull requests.

3. Credentials in de repo
Connection strings, API-keys en service principal secrets horen niet in Git. Gebruik Azure Key Vault of pipeline-variabelen.

4. Conflict-markers niet opruimen
Als je een merge conflict oplost maar de <<<<<< markers laat staan, kan Power BI Desktop het bestand niet openen. Controleer altijd of het model correct laadt na een merge.

5. Geen .gitignore
Zonder .gitignore komen lokale cache-bestanden en .pbix-backups in je repo terecht. Voeg de .gitignore toe voordat je je eerste commit maakt.