Werk je met Power BI? Dan herken je vast het volgende scenario; je werkt in Power BI Desktop aan een bestaand rapport en hebt een mooie nieuwe versie klaar voor publicatie. Maar, zonder dat je het doorhad was er een collega ook bezig aan hetzelfde rapport en slaat zijn versie op over jouw versie. Met als gevolg: jouw aanpassingen zijn tenietgedaan, waardoor je weer van voren af aan moet beginnen. In deze blog deelt technisch consultant Joep Hermans hoe je vanaf nu bovenstaand scenario voorkomt en lees je hoe je versiebeheer toepast.  

‘The last publish wins’

De bovenstaande werkwijze is niet te rijmen met de principes van CI/CD. Simpelweg omdat het tot grote frustraties kan leiden op het moment dat je met verschillende ontwikkelaars in dezelfde Power BI omgeving werkt. Om alle functionaliteiten van Power BI te gebruiken moet je lokaal ontwikkelen met Power BI Desktop. Hierbij wordt ieder rapport in een apart bestand opgeslagen. In dit bestandsformaat lagen de rapportdefinitie en de data waarop het rapport draaide vast. Hierdoor namen bestanden met grote datasets al snel veel ruimte in beslag. Als je tevreden was met het eindresultaat van je rapport en van de dataset kon je je bestand lokaal opslaan en publiceren naar de Power BI Service. Wanneer je op dat moment aan een bestaand rapport wilde sleutelen kon je twee dingen doen. Eén het lokale bestand bewerken en hopen dat dit de laatste versie was of twee een bestand genereren op basis van datgene wat op dat moment als huidige versie in de Service stond. Microsoft bood op deze manier geen enkele mogelijkheid om versiehistorie van rapporten bij te houden. Met als lange tijd het principe van ‘the last publish wins’ op het moment dat er simultaan gewerkt werd aan hetzelfde rapport. 

De oplossing

Ontwikkelaars verzonnen allerlei workarounds om ’the last publish wins’ te voorkomen. Met als eenvoudigste manier versiebeheer aanhouden in de naamgeving van je bestanden door deze een datum of versienummer mee te geven. Dit leunt echter sterk op afspraken die je met elkaar maakt en de juiste naleving hiervan. Aangezien er niks door het systeem afgedwongen wordt. Met als gevaar dat dingen door elkaar gaan lopen en er versies verloren gaan. Kortom, je moet met te veel dingen rekening houden en echt goed in de gaten houden waar je mee bezig bent.  

Een fatsoenlijke inrichting van versiebeheer laat deze problemen in één keer verdwijnen. Je wilt de mogelijkheid hebben om inzichtelijk te maken wat op welk moment gewijzigd is aan een rapport. Waardoor je voor ieder rapport altijd terug kan gaan naar de voorgaande versies. Op het moment dat er simultaan aan hetzelfde rapport wordt gewerkt, wil je er ook zeker van zijn dat de verschillende aanpassingen verenigbaar zijn in een nieuwe versie. Je Power BI omgeving is dus enorm gebaat bij een goede CI/CD functionaliteit. 

Het voordeel van Power BI versiebeheer 

Begin 2024 was het dan eindelijk zo ver: voor het eerst was er in de preview een optie om bestanden vanaf nu op te slaan in PBIP-format, wat staat voor Power BI Project. Hierbij wordt ook de mogelijkheid geboden om datadefinitie los te trekken van de rapportdefinitie en op te slaan in een apart TMDL-format bestand, wat staat voor Tabular Model Definition Language. Dit vereenvoudigt een manier van werken waarbij je datasets kunt hergebruiken en waarbij data los van het rapport gezien kan worden. Dit is een concept dat in de Service al een tijdje bestond. Lokaal waren data- en rapportdefinitie echter altijd onlosmakelijk aan elkaar verbonden. In tegenstelling tot het oude PBIX-bestandformaat, bevatten beide bestandformaten nu een structuur die de mogelijkheid biedt om bestanden aan te sluiten op een git-repository. In die git-repository kunnen nu twee aparte folders gecreëerd worden. Eén voor datadefinities (TMDL-bestanden) en één voor rapportdefinities (PBIP-bestanden). Deze bestanden zijn vervolgens zoals gebruikelijk in en uit te checken. Ook kan er in verschillende branches gewerkt worden, waarbij via een pull-request wordt nagegaan of bepaalde veranderingen in jouw branch passen en in de branch waarin je wilt mergen. Wanneer er simultaan aan dezelfde bestanden gewerkt wordt en beide versies worden naar de git-repository gepusht, kan dit eventueel tot merge conflicts leiden, waarbij per bestand kan worden aangegeven welke versie moet blijven staan. Volgens dit principe is het natuurlijk ook gebruikelijk dat je een ontwikkel- en een productiebranch bijhoudt en zo nu en dan een release uitvoert van de ene branch naar de andere. 

 Als je verbonden bent met een gecentraliseerde git-repository, dan kun je de Power BI Service hier ook aan koppelen. Hierna kun je vervolgens in de Service werkruimtes gaan koppelen aan branches, waardoor je voor iedere werkruimte verschillende versies krijgt. Op het moment dat er veranderingen buiten de Service gedetecteerd worden, krijg je hier een melding van en is het mogelijk om deze ook naar de Service toe te trekken. Zodra je voor iedere werkruimte een ontwikkelversie, een testversie en een productieversie hebt, kun je deze werkruimtes aan elkaar verbinden. En kan het veranderproces georkestreerd worden aan de hand van de zogeheten deployment pipelines. Bij het bouwen van deze pipelines kun je per omgeving bepaalde regels definiëren. Zodat de veranderingen die je in je ontwikkelwerkruimte laat plaatsvinden op de juiste manier doorgezet worden naar de testwerkruimte en later naar de productiewerkruimte.  

Let hierbij wel op: het moment dat een rapport en dataset naar de volgende branch gaan, heeft de dataset een refresh nodig om de juiste data in het rapport te tonen. Hij zet dus als het ware een nieuwe lege versie van de rapport- en datasetdefinities neer. 

Het grootste nadeel van git-integratie binnen Power BI is dat het alleen beschikbaar is voor werkruimtes die een premium of fabric capacity hebben. Power BI Pro werkruimtes kennen dus geen git-integratie. Het zou in principe mogelijk zijn om aan de hand van de PBIP-bestanden een eigen maatwerkoplossing te fabriceren. Dit is echter een stuk minder eindgebruiker-vriendelijk dan wanneer je het in Power BI zelf faciliteert. Ook kost het je meer tijd om dit te implementeren en vervolgens te beheren. 

Toekomst

Versiebeheer is een belangrijke stap in de professionalisering van Power BI als ontwikkeltool. Het maakt het niet alleen makkelijker om zaken te ontwikkelen, maar het draagt vooral ook bij aan de stabiliteit van je omgeving. Dit straalt meer professionaliteit uit naar de eindgebruiker. Waar Microsoft met Power BI voorheen heel sterk heeft ingezet op self service, zie je dat ze nu een grote inhaalslag aan het maken zijn wat betreft het structureel opbouwen van de ontwikkelomgeving. Een goede inrichting van versiebeheer is hierin een onmisbare schakel. Ondanks het feit dat er nog wat haken en ogen zitten aan de huidige implementatie, is het een hele verademing dat deze functionaliteit nu doorgang heeft gevonden.