Power BI met Git integratie. De oplossing voor versiebeheer?
Dit is wat je moet weten voordat je ermee aan de slag gaat.
Power BI met Git integratie. Een feature waar men al jaren op zat te wachten, is nu eindelijk beschikbaar. Microsoft lanceerde recentelijk gelijktijdig met Azure Fabric Git functionaliteit voor Power BI.
Het was al mogelijk om Power BI-bestanden op Git op te slaan, maar door het bestandsformaat had je hier eigenlijk (bijna) niks aan. Wijzigingen aan het bestand waren niet zichtbaar en gelijktijdig aan een bestand werken was al helemaal niet mogelijk.
Probleem versiebeheer en Power BI
Tot voorkort was het gebruikelijk om je Power BI versiebeheer in een folderstructuur of op Sharepoint te doen. Op die manier was het makkelijk om terug te gaan naar een oudere versie of even een oudere versie te openen en te kijken wat er sindsdien veranderd was.
Het nadeel was dat je handmatig de versies aan moest maken en een strikte naam- en folderstructuur moest handhaven, omdat je anders vroeg of laat niet meer wist wat de laatste versie was waar je team aan gewerkt had. Met de nieuwe functionaliteit van Power BI behoort dit probleem tot de verleden tijd.
Wat is Git?
Git is een krachtig en gedistribueerd versiebeheersysteem dat wordt gebruikt voor het bijhouden van wijzigingen in de broncode van softwareprojecten. Het stelt ontwikkelaars in staat om samen te werken aan projecten, terwijl ze tegelijkertijd de geschiedenis van wijzigingen beheren en de mogelijkheid hebben om terug te keren naar eerdere versies van de code.
In essentie stelt Git ontwikkelaars in staat om de voortgang van hun werk bij te houden door middel van zogenaamde “commits”. Een commit is een snapshot van de huidige staat van de code op een bepaald moment. Git maakt het gemakkelijk om verschillende takken (branches) van ontwikkeling te creëren, zodat meerdere mensen parallel aan een project kunnen werken zonder elkaars werk te verstoren.
Wat Git onderscheidt, is zijn gedistribueerde aard. Elke ontwikkelaar heeft een volledige kopie van het hele project en kan lokaal wijzigingen aanbrengen. Deze wijzigingen kunnen vervolgens worden gedeeld met anderen via zogenaamde “push” en “pull” operaties.
“Je kan nu volledig in de cloud werken en nog steeds je versiebeheer netjes op orde hebben!”
Hoe werkt Power BI samen met Git?
Grofweg kan je de Git functionaliteit op twee manieren gebruiken; lokaal en online. In de beweging waarin Microsoft steeds meer pusht om Power BI development online te doen, komt de online functionaliteit als geroepen.
Het bijhouden van versies terwijl je direct in de workspace bewerkingen deed was namelijk iets wat niet goed samenging. Geïntegreerde versiebeheer was daar de missende schakel. Nu dat er wel is kan je volledig in de cloud werken en nog steeds je versiebeheer netjes op orde hebben! Maar ook lokaal of hybride werken met Power BI Desktop is gewoon nog mogelijk.
Meer van dit in je mailbox?
We sturen je circa 6x per jaar een email met handpicked cases, blogs en tips.
Lokaal ontwikkelen
Door vanuit Power BI desktop je project op te slaan als een PBIP (Power BI Project) bestand, wordt het opgeslagen als een set platte bestanden in bijvoorbeeld JSON- en XML-formaat. Deze bestanden zijn verdeeld in een mapje Dataset en een mapje Report. Hierbij wordt de data zelf niet opgeslagen, alleen de connectiegegevens naar de bron. Deze platte bestanden kunnen in principe op elke Git neergezet worden.
Maar eigenlijk heb je er pas echt wat aan als je de Git repository ook koppelt aan een Power BI workspace, en dat kan (momenteel) alleen met een Azure DevOps Git repository. Dat is dan gelijk een beperking van Power BI i.c.m. Git Met deze koppeling kunnen wijzigingen namelijk direct vanuit Git uitgerold worden in de Power BI workspace.
Wijzigingen die online of door andere developers gedaan zijn, kunnen ook makkelijk via Git binnengehaald worden door middel van een simpele “Git pull”. Het koppelen van een Git repository aan een Power BI workspace is in een paar clicks geregeld.
In onderstaand figuur zie je hoe twee developers lokaal in Power BI desktop in een eigen branch kunnen werken, en deze in Azure Devops mergen met de master branch. Door dit via een pull request te doen kan er eventueel ook nog een review van de wijzigingen plaatsvinden. De master branch wordt in sync gehouden met de Power BI workspace zodat de huidige versie altijd in de master branch op Git staat.
Online ontwikkelen
Er kan ook online ontwikkeld worden. In dit geval hebben developers een eigen development workspace die ze kunnen koppelen met een feature branch in Git. Uiteraard kan lokaal en online werken ook gecombineerd worden.
Changes kunnen ook direct in de main workspace van Power BI gedaan worden waarna ze naar de master branch in Git gesynct kunnen worden. Hierdoor verlies je de traceerbaarheid natuurlijk wel deels, zeker als je vergeet de changes naar Git te halen.
Mocht je al gebruik maken van deployment pipelines passen deze gewoon in de nieuwe werkwijze met Git. De meest voordehand liggende optie is om de master branch van Git te koppelen aan de development workspace in Power BI. Een voorbeeld van deze opzet is te zien in onderstaand figuur.
Power BI laat in de gekoppelde workspace altijd zien aan welke Git branch de workspace gekoppeld is, wanneer deze voor het laatst gesynct is en wat de laatste commit was bij deze sync. In het source control menu van de workspace is te zien welke wijzigingen er op Git staan of welke wijzigingen er in de workspace gedaan zijn.
Deze kunnen dan binnengehaald worden of juist naar de master branch gepusht worden. Een voorbeeld van dit menu is te zien in de afbeelding rechts. In dit voorbeeld zijn er changes gedaan direct in de workspace.
Wat heb je er nou precies aan?
Het samenwerken in rapporten is met Git mogelijk geworden, maar het vraagt alsnog afstemming binnen het team zodat er geen merge-conficten zullen ontstaan.
Ook is de traceerbaarheid van wijzigingen op deze manier een stuk inzichtelijker geworden door de commit historie van Git. Je kan precies zien wie wanneer welke wijzigingen gedaan heeft. Sommige wijzigingen zijn wel makkelijker te zien dan anderen.
Zo zijn wijzigingen in DAX keurig terug te zien en bijvoorbeeld te reviewen (zie afbeelding dax wijzigingen). Wijzigingen in opmaak zijn abstracter en kan je over het algemeen niet reviewen op basis van de code. (Zie afbeelding visuele wijzigingen in Git)
Dax wijzigingen in Git
Visuele wijzigingen in Git
Het deployment proces en release management is er met git in principe ook eenvoudiger en gestructureerder op geworden. Je hoeft niet meer hele rapporten te downloaden en uploaden, of een mappenstructuur met versies bij te houden.
Wel zullen ontwikkelaars gewend moeten zijn of raken aan Git en de daarbij horende deployment- en branching strategieën.
Ook voor back-up en herstel is Git zeer geschikt. Je kan terug naar oudere versies van een rapport, maar dit is in Git misschien wel moeilijker dan met een simpele folder structuur waar je versies in bijhoudt. Het voordeel is wel dat Git versies voor jou bijhoudt, en je niet meer afhankelijk bent van een handmatig proces.
Aan de slag!
Het toevoegen van Git binnen het Power BI ecosysteem is zonder meer een stap in de goede richting. De functionaliteit staat nog in de kinderschoenen en zal nog verder doorontwikkeld moeten worden. Zo zijn er af en toe nog wel bugs waar je tegenaan loopt als je Git gaat implementeren.
Maar met Power BI Premium en Premium per user is het nu zeker al de moeite waard om Git te koppelen, want het is in een paar clicks geregeld. Met Power BI pro is de toegevoegde waarde momenteel wellicht nog te klein om er al groots op in te zetten, maar experimenteren kan natuurlijk geen kwaad.
Wil je aan de slag met Git voor Power BI? Je kan direct beginnen door de preview feature ‘Power BI project (.pbip) save option’ aanzetten. Hiermee kan je een rapport opslaan als een set platte bestanden die door Git geïnterpreteerd kunnen worden.
Maar om de Git functionaliteit echt nuttig te maken wil je ook workspaces kunnen koppelen aan de Git repository. Voor deze online Git functionaliteit zal je moeten werken met Power BI premium of Premium per user. Ook is die online integratie met Git beperkt tot Azure DevOps. Je zal daar dus een Git repository aan moeten maken om te koppelen aan een workspace.
Meer weten of hier zelf mee aan de slag? Neem contact met ons op.
Geschreven door
Tijmen van Willigen
Data engineer
Op de hoogte blijven van de laatste ontwikkelingen en webinars?
Schrijf je dan in voor de nieuwsbrief en ontvang circa 6x per jaar een selectie van blogs, cases, webinars en nieuws in je mailbox.
Meer over dit onderwerp
Is Microsoft Fabric de moeite waard? Dit zijn onze bevindingen
Microsoft Fabric biedt op het eerste oog ongekende mogelijkheden, maar maakt het de verwachtingen waar? Data engineer Koen Kurver zocht het uit.
Het succes van je BI oplossing vergroten? Meten en gericht verbeteren!
Maar wat houdt dat in? En wat is daarin de rol van de data specialist?
Begin nú met het valideren van je data: zo doe je dat met dbt
Lees hoe je data eenvoudig valideert met dbt én waarom dat belangrijk is