Implementatiepijplijn (Deployment pipeline)

Wat is een implementatiepijplijn (Deployment pipeline)?

Een implementatiepijplijn is de ingebouwde ALM-tool van Microsoft Fabric. Je bouwt in een Development-werkruimte, je promoveert naar Test, je promoveert naar Production. Elke stap kopieert de rapporten, modellen, lakehouses, notebooks en andere items van de vorige werkruimte naar de volgende op een voorspelbare manier.

Dit is geen vervanging voor Git; het is een alternatieve route voor teams die geen pull-requests en YAML-CI willen opzetten. Fabric ondersteunt ook Git-integratie voor wie dat wel wil, en beide mechanismen bestaan naast elkaar.

Je kan een implementatiepijplijn vergelijken met een lift in een appartementsgebouw. Development, Test en Production zijn de verdiepingen. Je drukt op de knop, de hele inhoud gaat mee omhoog, en bij aankomst zit alles op zijn plek.

Hoe is een pijplijn opgebouwd?

Een pijplijn bestaat uit stages. De standaard is drie: Development, Test en Production. Je kan er twee hebben als je testen overslaat, of tot tien als je een ingewikkelde keten van omgevingen hebt (Dev, QA, UAT, Staging, Prod, per continent, per business unit).

Aan elke stage hangt exact één werkruimte. Die werkruimte bevat alle items die bij die stage horen. Promoveer je content, dan komt ze in de gekoppelde werkruimte van de volgende stage terecht.

De drie standaardstages in het klein:

Development
Bouwen en breken. Hier publiceer je nieuwe rapporten, pas je modellen aan en experimenteer je.

Test
Vergelijk content tussen Dev en Test (Fabric toont een diff), deploy, en laat reviewers of testgebruikers kijken op representatieve data. Meestal draait Test op een aparte lakehouse of warehouse met een subset of een anonieme kopie van productie.

Production
De definitieve versie. Deployen naar Prod gebeurt in principe alleen vanuit Test, nooit rechtstreeks vanuit Dev.

Welke items kan je meenemen?

De lijst groeit bij elke Fabric-release. Op dit moment (deels in preview):

Power BI: rapporten, paginated reports, semantische modellen (op basis van een .pbix), dashboards, dataflows, org-apps.

Data Engineering: lakehouse, notebook, spark job definition, environment, user data functions.

Data Factory: pipelines, dataflows gen2, copy jobs, mirrored databases.

Real-Time Intelligence: eventhouse, eventstream, KQL-database, KQL-queryset, real-time dashboard.

Data Warehouse: warehouse, gespiegelde Databricks-catalog.

SQL en Cosmos DB: SQL database, Cosmos database, beide in preview.

Let op: vanaf 12 februari 2026 ondersteunen deployment pipelines geen semantische modellen meer die nog niet op Enhanced Metadata draaien. Oude PBIX-bestanden uit 2018 moeten dus eerst naar het nieuwere formaat gebracht worden.

Item-pairing: de sleutel

Dit is het concept dat beginners het vaakst over het hoofd zien, en dat verklaart waarom een deploy soms duplicaten maakt in plaats van te overschrijven.

Een rapport in Dev en een rapport in Test worden niet automatisch met elkaar verbonden omdat ze dezelfde naam hebben. Ze worden gepaard op het moment dat ze voor het eerst via de pijplijn gedeployd worden, of op het moment dat je een werkruimte aan een stage hangt die al items bevat. Twee gepaarde items overschrijven elkaar bij volgende deploys; twee ongepaarde items met dezelfde naam duplicéren.

Gevolg: als iemand handmatig een rapport in Production uploadt dat niet via de pijplijn is gekomen, en je deployt nadien een rapport met dezelfde naam vanuit Test, krijg je twee versies in Production. Altijd via de pijplijn naar boven.

Deployment rules

Tussen stages moet bijna altijd iets veranderen. Een rapport in Dev wijst naar de test-warehouse; in Production moet datzelfde rapport naar de prod-warehouse verwijzen.

Deployment rules zorgen daarvoor. Je definieert per stage welke connectiestring, welk database-object of welke parameter-waarde vervangen moet worden wanneer de content arriveert. De auteur hoeft niks in het rapport aan te passen; de pijplijn herschrijft de bron-verwijzingen automatisch op het moment van promoveren.

Voor Direct Lake-modellen op OneLake is er één bekende beperking: je kan de databron niet rechtstreeks via een rule herbinden. Werken met een parameter-expressie in de connection string is daar de standaard-workaround.

Valkuilen

Alles in één werkruimte
Dev, test en productie mengen in één werkruimte lijkt eenvoudig tot een onafgewerkt rapport per ongeluk bij de eindgebruikers opduikt. Zet elke stage in zijn eigen werkruimte. Altijd.

Handmatige edit in Production
Een "klein foutje rechtstreeks in Prod" oplossen breekt pairing en geeft gezeur bij elke volgende deploy. Fix in Dev, promoveer naar Test, promoveer naar Prod.

Data en code door elkaar
Een lakehouse bevat code (schemas, tabeldefinities) én data (de rijen zelf). Deployment pipelines kopiëren niet automatisch de data van de tabellen mee. Reken op een apart proces (bijvoorbeeld een bronkopie of pipeline) om Test van data te voorzien.

Licenties van contribuanten
Elke gebruiker die in een stage-werkruimte mag publiceren, heeft een Pro-licentie nodig. Gratis gebruikers kunnen alleen lezen, en dan nog enkel op F64 of hoger. Onderschat dit niet bij het berekenen van de kost van een release-ploeg.

Git-integratie en pipelines door elkaar halen
Git-integratie versioneert je code in een repo; pijplijnen kopiëren content tussen werkruimtes. Combineren kan, maar begrijp het onderscheid: een pijplijn is geen source control en Git is geen release-mechanisme.