In een eerdere blog heb ik het al gehad over Power BI Deployment Pipelines. Deze zijn uiteraard ook goed te gebruiken om Fabric items vanuit verschillende stadia de promoten naar bijvoorbeeld acceptatie of productie. Om de pipelines flexibel te maken waren er al Deployment Rules, maar sinds kort zijn er ook Variable Libraries geïntroduceerd om de flow nog beter onder controle te kunnen houden.
Deployment Rules
Binnen Power BI Deployment Pipelines kan je Deployment Rules gebruiken om bepaalde instellingen of parameters aan te passen tijdens het deployen naar een volgende omgeving/werkruimte. Hierbij moet je denken aan het wijzigen van een data source of een parameter binnen een semantisch model.
Deployment Rules zijn echter maar beschikbaar voor een beperkt aantal objecten. Er kan dus bijvoorbeeld geen deployment rule worden ingezet om de source van een copy activity van een fabric pipeline aan te passen.
Wat dan wel weer mogelijk is is een deployment rule aanmaken op een notebook om het Default Lakehouse aan te passen bij deployment. Sinds oktober ondersteunen notebooks echter ook auto-binding. Dat wil zeggen dat het default lakehouse en de environment wordt aangepast naar de items in de target workspace (zolang de items in dezelfde werkruimte bestaan).
Variable Libraries
Om nog flexibeler te zijn heeft Microsoft variable libraries geïntroduceerd. Dit kan je eigenlijk zien als een set van variabelen welke je per werkruimte kan aanpassen. Deze variabelen kun je onder andere in je pipelines gebruiken. Dit werkt eigenlijk bijna hetzelfde als het gebruik van standaardvariabelen
Binnen een werkruimte kan een item genaamd “Variable Library“ worden aangemaakt. Daarna definieer je in een pipeline welke variabelen vanuit de library gebruikt kunnen worden in de pipeline.
Deze gedefinieerde variabelen kunnen dan net als gewone variabelen op de volgende manier worden gebruikt binnen een pipeline.
Binnen een variable library kunnen verschillende variabelen worden aangemaakt. Voor iedere toepassing of werkruimte kunnen dan alternatieve value sets worden aangemaakt. Per werkruimte kan dan een andere value set actief worden gezet. In dit voorbeeld wordt er een connectionstring en een warehouse gebruikt.
De default set voor development
En de ACC set voor de acceptatieomgeving
Ook al zijn er binnen de verschillende werkruimten andere value sets actief, de deployment pipeline zal dit niet als verandering zien bij het vergelijken van de items tussen de werkruimten.
Deze variabelen kunnen niet alleen binnen pipelines worden gebruikt, maar kunnen ook in een lakehouse worden gebruikt als shortcut naar een storage account bijvoorbeeld. Voor de volledigheid hier een overzicht van de items waar de variabelen gebruikt kunnen worden:
- Pipeline
- Shortcut for a lakehouse
- Notebook, through NotebookUtils and %%configure
- Dataflow Gen 2
- Copy job
- User data functions
Auto-binding
Buiten het gebruik van Deployment Rules en Variable Libraries bestaat er binnen werkruimten natuurlijk ook nog auto-binding.
Auto-binding houdt eigenlijk in dat bij het overzetten van items van de ene naar de andere werkruimte wordt geprobeerd om de referenties aan te passen naar items in de nieuwe werkruimte. Hierbij moet je denken aan bijvoorbeeld
- Notebook referenties in een pipeline
- Default lakehouse referentie in een Notebook
Dit werkt niet voor connecties in een pipeline. Je zou misschien verwachten dat een connectie naar een lakehouse of warehouse binnen dezelfde werkruimte ook via auto-binding wordt aangepast, maar dat is niet zo. Misschien ook wel omdat connecties zelf niet binnen een werkruimte worden gedefinieerd. Maar dat is prima op te lossen door het gebruik van variable libraries.
Conclusie
Door het gebruik van variable libraries wordt het beheer van het lifecyclemanagement van een Fabric-omgeving een stuk eenvoudiger. Door de juiste variabelen aan te maken, hoeft er tijdens de deployment zelf eigenlijk niets meer te worden aangepast en worden de connecties en referenties automatisch bijgewerkt.
