We kennen het allemaal wel: voorheen was het lastig om met meerdere mensen tegelijkertijd te ontwikkelen aan hetzelfde semantisch model. Het grootste probleem? Power BI modellen werden opgeslagen als één grote file, waardoor tegelijkertijd werken aan dezelfde modellen regelmatig voor problemen en frustraties zorgde. Gelukkig is daar sinds de introductie van het TMDL/PBIP-formaat verandering in gekomen.
Deze nieuwe manier van werken bestaat al een tijdje, maar hoe werkt dit nu eigenlijk in de praktijk? In deze blog neem ik je mee in de wereld van moderne Power BI ontwikkeling met teams.
PBIP (Power BI Project) bestanden
Met de introductie van de nieuwe PBIP-structuur worden de verschillende onderdelen van een semantisch model opgeslagen in aparte tekstbestanden, geschreven in het TMDL-formaat. Deze bestanden zijn specifiek zo ontworpen dat ze Git-friendly zijn en dus naadloos te integreren zijn met Git en Azure DevOps.
De belangrijkste voordelen van het werken met de PBIP-bestanden
- Source control friendly: Tekstbestanden die Git kan tracken
- Betere samenwerking: Meerdere mensen kunnen aan verschillende onderdelen werken
- Merge conflicts oplossen: Omdat alles in tekst staat, kun je conflicts beter beheren
- Modulariteit: Rapport en dataset zijn gescheiden
- TMDL-format: Nieuwe, meer leesbare definitietaal voor het datamodel
Het moderne PBIP-formaat brengt eigenlijk de voordelen van Enterprise development (zoals bij SSAS Tabular) naar Power BI Desktop, waardoor het veel professioneler en schaalbaarder wordt voor teams.
Hoe werkt het in de praktijk
Voor deze blog maken we gebruik van een model uit een van onze eigen oplossingen: BI4SAP Live. Het model staat in een Power BI werkruimte die gekoppeld is aan een development branch in Azure DevOps. Vanuit deze development branch worden wijzigingen overgezet naar een productie branch, die op zijn beurt weer gekoppeld is aan een productie werkruimte.
Op de development branch kunnen verschillende ontwikkelaars werken. Voor elke nieuwe feature wordt een aparte feature branch aangemaakt. Deze feature branches worden via pull requests weer gemerged met de development branch. Dit zorgt voor een overzichtelijke en gecontroleerde workflow.
Het ontwikkelen zelf kan op verschillende manieren worden gedaan:
- Lokaal ontwikkelen met Tabular Editor in combinatie met Power BI Desktop
- Remote ontwikkelen in een eigen werkruimte die gekoppeld is aan de feature branch
Laten we beide methodes eens nader bekijken.
Lokaal ontwikkelen
Door de branch met bijvoorbeeld visual studio code lokaal te klonen kan er onder andere met de volgende tools ontwikkeld worden aan het model
- Tabular Editor – Onze voorkeurskeuze voor modelontwikkeling
- Visual Studio Code – Voor het bekijken en bewerken van de TMDL-bestanden
- Power BI desktop – Voor het testen van data en het aanmaken van meetwaarden
Het testen van data en het aanmaken van meetwaarden kan met deze werkwijze ook met Power BI desktop worden gedaan. Onze voorkeur gaat uit naar Tabular Editor, maar ik wil toch even aanstippen dat dit met deze structuur ook mogelijk is.
Zodra de ontwikkelingen voltooid zijn, kunnen de wijzigingen naar de feature branch worden gecommit. Dit kan eenvoudig via Visual Studio Code of een andere Git-client naar keuze. Je hebt volledige controle over welke wijzigingen je commit en kunt gedetailleerde commit messages toevoegen.
Remote ontwikkelen
Als een ontwikkelaar liever wil ontwikkelen in een Power BI wokspace kan hij de feature branch koppelen aan een eigen werkruimte. Wijzigingen kunnen dan bijvoorbeeld met Tabular Editor worden doorgevoerd en de data kan voor test doeleinden op de gebruikelijke wijze worden ververst. Voordeel van werken op deze manier is dat er geen lokale resources voor worden benut.
Ontwikkelingen kunnen via de source control settings van de werkruimte naar de feature branch worden gecommit.
Mergen
Als de ontwikkelingen klaar zijn kunnen de wijzigingen via een pull request in de development branch worden gemerged. Omdat het project uit veel verschillende files bestaat verloopt dit vaak zonder problemen. Eventuele merge conflicts kunnen in de pull request zelf worden opgelost. Om dit goed te laten verlopen zijn er natuurlijk wel een aantal basisregels waar je je aan moet houden. Deze zal ik in de conclusie even toelichten.
Conclusie
Met deze methode is het ontwikkelen van semantische modellen met een team een stuk makkelijker en toegankelijker geworden. In de praktijk zijn er echter nog wel een aantal aandachtpunten waar rekening mee gehouden moet worden om het mergen van de branches zo probleemloos mogelijk te laten verlopen
- Probeer per ontwikkelaar te werken aan een eigen feature in een bepaald informatiegebied, zodat er niet meerdere mensen dezelfde tabellen raken
- Hou de features klein en overzichtelijk.
- In sommige gevallen wordt er gewerkt met een speciale/centrale “meetwaarde” tabel waar alle meetwaardes van het model in zitten. Probeer dit te vermijden, want dan worden er veel wijzigingen van meerdere mensen op deze tabel gedaan. Hou de meetwaarden gewoon in de feitentabellen of maak een aparte tabel per informatiegebied.
- De file relationships.tmdl bevat alle relaties van het model en de file model.tmdl beval een referentie naar alle tabellen. Dit zijn dus files waar relatief vaak merge conflicten op ontstaan. Aangezien respectievelijk elke relatie en elke tabel op een aparte regel staat zijn deze conflicten makkelijk op te lossen. Als je weet dat je wijzigingen aan deze files hebt gedaan zou je ook nog een rebase van je branch kunnen doen voor het mergen.
Met een paar slimme aanpassingen in je werkwijze is het ontwikkelen van Power BI modellen met meerdere ontwikkelaars zeker goed te doen. Sterker nog: het is een fijne en efficiënte manier van werken die de samenwerking binnen teams naar een hoger niveau tilt.
