Versiebeheer met Git voor Power BI-projecten: Tijd voor een nieuwe aanpak!

Power BI wordt steeds populairder voor data-rapportage, maar de versies van die rapporten bijhouden is voor teams vaak een ander paar mouwen. Het oude vertrouwde Power BI-bestandsformaat (.PBIX) is simpelweg niet gemaakt voor samenwerking of versiebeheer. Logisch dus dat er problemen van komen wanneer meerdere developers aan hetzelfde rapport proberen werken.

Gelukkig is er een betere optie: Power BI Project Files (.PBIP) en Git-integratie. Op deze manier kunnen Power BI-ontwikkelaars eindelijk soepel samenwerken met moderne source control systemen zoals Git. In deze blog leggen we je haarfijn uit hoe je Git gebruikt voor Power BI-projecten, hoe je de workflows kan opzetten, en hoe je enkele veelvoorkomende problemen kan aanpakken.

Vaarwel PBIX, Hallo PBIP

Vroeger betekende versioneren van Power BI-rapporten dat je moest werken met logge, onoverzichtelijke PBIX-bestanden. Alle onderdelen van een rapport – datamodellen, visualisaties, query’s – zaten in één groot binair bestand. Probeer daar maar eens kleine wijzigingen in te traceren, zoals aanpassingen aan losse query’s of elementen van je rapport…

Gelukkig introduceerde Microsoft Power BI Project-bestanden (.PBIP). Die splitsen het PBIX-bestand op in afzonderlijke tekstbestanden. Deze bestanden bevatten metadata over het rapport en datamodel in JSON- en TMDL-formaat. Dat maakt ze veel makkelijker te beheren en te versioneren met Git of andere systemen voor source control.

Dit is er allemaal nieuw aan de PBIP-bestanden:

Elk element van je rapport en semantisch model krijgt zijn eigen, leesbaar JSON-bestand.
Deze JSON-bestanden kun je tracken in Git. Zo kunnen ontwikkelaars versies beheren, samenwerken via branching en merging, en wijzigingen bekijken via pull requests.
Je kan externe tools zoals Visual Studio Code gebruiken om de structuur van het rapport te bekijken en bewerken. Handig, want je kan wijzigingen beheren zonder Power BI Desktop te moeten openen!

Git instellen voor Power BI-projecten

In dit deel leggen we je stap voor stap uit hoe je Git kan integreren met je Power BI-project, van het maken van een branch tot het samenvoegen van wijzigingen in de hoofdrepository.

Voordat je aan de slag gaat met versiebeheer en samenwerking, is het belangrijk om je Power BI Project-bestand (PBIP) goed op te zetten. Werk je aan een nieuw project, of converteer je een bestaand Power BI-bestand (PBIX)? Volg dan deze stappen om je project op te slaan in het nieuwe Power BI Project-formaat en klaar te maken voor Git-integratie.

Stap 1: Schakel de Power BI Project File-feature in

Power BI Project-bestanden (.PBIP) zijn momenteel nog een preview-feature in Power BI Desktop. Je moet deze feature dus eerst inschakelen voordat je je werk als project kunt opslaan:

Ga naar Bestand > Opties en instellingen > Opties > Preview-features.
Vink het vakje naast de optie ‘opslaan als Power BI Project (.pbip)’ aan om de feature te activeren.

Nu kun je je Power BI-rapport en datamodel opslaan als een projectbestand, opgesplitst in losse tekstbestanden. Dat maakt versiebeheer een stuk eenvoudiger.

Stap 2: Sla je Power BI-bestand op als een project

Zodra de feature is ingeschakeld, kan je je werk opslaan als project:

Open je Power BI Desktop-bestand (PBIX) of begin een nieuw Power BI-project.
Om het op te slaan als project, ga je naar Bestand > Opslaan als en kies je ‘Power BI Project (.PBIP)’ als bestandstype.

Wanneer je het bestand opslaat, maakt Power BI Desktop automatisch een mappenstructuur aan met alle tekstbestanden die de verschillende onderdelen van je rapport vertegenwoordigen. Denk bijvoorbeeld aan:

<projectnaam>.SemanticModel bevat bestanden die horen bij het semantische model.
<projectnaam>.Report bevat bestanden die horen bij het Power BI-rapport.

Power BI Desktop maakt ook automatisch een .gitignore-bestand aan. Dit bestand zorgt ervoor dat overbodige bestanden, zoals localSettings.json en cache.abf, automatisch worden uitgesloten van Git-tracking.

Stap 3: Bekijk je Power BI-projectstructuur

Nadat je je Power BI-bestand als project hebt opgeslagen, zul je een aantal veranderingen zien:

De titelbalk van Power BI Desktop laat nu zien dat je aan een projectbestand werkt. Je kan erop klikken om een menu te openen met opties om projectbestanden te zoeken of de map te openen in Verkenner.
In Verkenner zie je nu de mappenstructuur die Power BI Desktop heeft gemaakt. De rapportelementen zijn opgesplitst in meerdere mappen en bestanden. Elk bestand bevat JSON- of andere metadata-indelingen die je eventueel extern kan bewerken.

Stap 4: Stel je Git-repository in

Je Power BI-project staat nu in z’n nieuwe structuur en is klaar om te tracken in Git. Zo stel je Git in:

Start een Git-repository: Wordt je project nog niet getrackt door Git? Open dan de terminal of Git Bash en ga naar je projectmap. Voer vervolgens het volgende commando uit om een repository te starten:
git init
Kloon je repository: Staat je project al in een externe Git-repository? Kloon de repository dan naar je lokale machine met dit commando:
git clone https://jouw-repository-url
Commit je projectbestanden: Nadat je je Power BI-project hebt opgeslagen en de Git-repository hebt ingesteld, is het tijd om de relevante projectbestanden te committen naar Git. Controleer wel even het .gitignore-bestand om er zeker van te zijn dat onnodige bestanden worden uitgesloten:
git add .
git commit -m “Eerste commit van Power BI-project”

Stap 5: Maak een feature branch aan

Ga je aan de slag met een nieuwe feature of wil je een rapport aanpassen? Maak dan altijd eerst een nieuwe branch aan:

Zorg dat je in Visual Studio Code de laatste versie van de main branch hebt door de laatste wijzigingen te pullen.
Maak een nieuwe branch aan met een duidelijke naam via dit commando:
git checkout -b feature/nieuwe-rapport-sectie
Open het Power BI Project-bestand in Power BI Desktop en maak de gewenste aanpassingen aan je rapport.

Stap 6: Commit en push je wijzigingen

Heb je alle gewenste wijzigingen aangebracht in Power BI? Sla je werk op en ga terug naar Visual Studio Code:

Zet de gewijzigde bestanden klaar voor staging via het tabblad Git Source Control in VS Code.
Schrijf een duidelijke commit-boodschap waarin je beschrijft welke wijzigingen je hebt aangebracht:
git commit -m “Nieuwe rapportsectie toegevoegd voor kwartaalomzet”
Push je wijzigingen naar de externe repository met dit commando:
git push origin feature/nieuwe-rapport-sectie

Stap 7: Maak een pull request aan

Nu je wijzigingen op de externe repository staan, is de volgende stap om ze samen te voegen met de main branch. Dat doe je met een pull request:

Ga naar je repository in Azure DevOps of GitHub en maak een pull request aan.
Bekijk de wijzigingen nog een keer en vraag je collega’s om goedkeuring, indien nodig.
Zodra je wijzigingen zijn goedgekeurd, kun je ze samenvoegen met de main branch.

Vaak voorkomende problemen (en hoe ze te vermijden)

Git-integratie met Power BI maakt samenwerken een stuk makkelijker, maar helemaal probleemloos is het niet. Je kunt tegen een aantal zaken aanlopen. Gelukkig hebben we ook daar een oplossing voor:

Synchronisatieproblemen
Gebruik geen cloud-gesynchroniseerde mappen zoals OneDrive of SharePoint voor je Git-repository. Die kunnen voor conflicten zorgen met Git, wat kan leiden tot beschadigde bestanden of branches die niet goed gesynchroniseerd zijn.
Bewaar je repository liever lokaal of op Azure DevOps, GitHub of een vergelijkbare dienst. Zo voorkom je dit soort problemen.
Bestanden bewerken met externe tools
Niet alle bestanden in Power BI-projecten zijn bedoeld om buiten Power BI Desktop te worden bewerkt. Niet-ondersteunde wijzigingen die je aanbrengt in externe tools zoals Visual Studio Code, kunnen voor fouten zorgen. Het kan zelfs zo zijn dat Power BI Desktop het project niet meer kan openen. Bewerk daarom alleen de bestanden die daarvoor bedoeld zijn, zoals JSON-bestanden voor model- en rapportdefinities. En: test je wijzigingen altijd in Power BI Desktop nadat je ze hebt aangebracht.
Omgaan met regeleinden
Power BI Desktop gebruikt CRLF als regeleinde-indeling (end-of-line format). Om te voorkomen dat je onnodige diffs en problemen met regeleinden krijgt, kun je Git zo instellen dat regeleinden automatisch worden afgehandeld. Dat doe je door autocrlf in te schakelen. Op Windows kan dat eenvoudigweg door het volgende commando in je terminal uit te voeren:
git config –global core.autocrlf true

Power BI-projecten deployen

Er zijn verschillende manieren om Power BI-projecten te deployen naar een Power BI Workspace.

Git-integratie met Workspaces
Synchroniseer specifieke branches met een Workspace. Dit betekent dat je voor elke Workspace waarmee je je rapporten wilt synchroniseren een aparte branch hebt die je moet beschermen tegen directe commits, bijvoorbeeld dev/tst/acc/prd.
Hou er wel rekening mee dat deze feature nog in preview is, dus er zijn een aantal voorwaarden aan verbonden. Je hebt bijvoorbeeld Fabric Capacity of Premium Per User Workspaces nodig. Maar: de feature lijkt al stabiel te werken. Vooral voor Power BI-developers die nog niet zo veel ervaring hebben met DevOps is dit een interessante optie.
Met deze methode kun je trouwens parameters of gegevensbronnen vervangen via een Azure DevOps Pipeline (of GitHub Action) nadat je pull request is goedgekeurd. Meer weten? Check https://learn.microsoft.com/en-us/fabric/cicd/git-integration/intro-to-git-integration?tabs=azure-devops.
Deployen met een service-principal van Azure DevOps
Program manager Rui Romano van het Power BI-team heeft een voorbeeld van een Azure DevOps Pipeline op GitHub gedeeld. Deze pipeline kun je gebruiken en aanpassen aan je eigen wensen: https://github.com/microsoft/Analysis-Services/blob/master/pbidevmode/sample-ado-pipelines/DeployPBIP.yml
Let op, want deze aanpak heeft een belangrijk nadeel. Elke keer dat je deployt naar een workspace, wordt de service-principal eigenaar van het semantische model. Als de databronnen van dat model een externe login vereisen (wat meestal het geval is), moet je inloggen op de Power BI Workspace, het rapport overnemen, en inloggen op die bronnen. Na je volgende deploy is de service-principal echter weer eigenaar van je semantische model en moet je het hele proces opnieuw doorlopen. Verre van ideaal dus.
Klassieke Power BI deployment pipelines

Deze features is al jaren dé standaardmanier om Power BI-rapporten te deployen naar verschillende Workspaces. Het zit wel redelijk diep verstopt in de webinterface. Met deze pipelines kun je parameters en gegevensbronnen in verschillende omgevingen vervangen met behulp van deploymentregels.
De flow voor een Power BI-ontwikkelaar ziet er als volgt uit:

Je maakt een feature branch aan om je wijzigingen aan het rapport/model te ontwikkelen.
Je laat je collega’s je wijzigingen controleren via een pull request naar de main branch.
Zodra je wijzigingen zijn goedgekeurd, deploy je ze naar de development Workspace. De releasemanager zorgt er vervolgens voor dat de rapporten worden geïmplementeerd naar tst, acc & prd via de klassieke deployment pipeline.

Git en Power BI: een ideaal duo

Power BI-projecten en Git-integratie zijn een enorme stap vooruit voor Power BI-ontwikkelaars die samen aan rapporten willen werken. Door PBIX-bestanden op te splitsen in overzichtelijke JSON-bestanden, heeft Microsoft versiebeheer, branching en merging mogelijk gemaakt in de Power BI development lifecycle.

De features zijn voorlopig nog in preview en moeten hier en daar nog wat worden bijgeschaafd, maar ze bieden nu al enorme voordelen voor teams die efficiënter willen werken. We verwachten in de toekomst nog veel meer updates en verbeteringen die Git en Power BI perfect geschikt maken voor CI/CD-pipelines en development op grote schaal.