2.5 Deployment Pipelines & XMLA
Key Takeaways
- A deployment pipeline has three stages — Development, Test, Production — each bound to a workspace, and promotes content forward stage by stage.
- Deployment rules rebind stage-specific settings (e.g., data source or parameter) so a model points to test data in Test and prod data in Production after deployment.
- Comparison indicators show which items differ between stages so you deploy only what changed.
- The XMLA endpoint allows external tools and CI/CD scripts to read and write semantic model definitions for automated, scripted deployment.
- Deployment pipelines provide a guided UI promotion path; XMLA endpoint deployment enables fully scripted automation outside the pipeline UI.
Promoting Content Safely
Quick Answer: A deployment pipeline has three stages — Development → Test → Production — each mapped to a workspace. You promote content forward one stage at a time. Deployment rules automatically rebind environment-specific settings (data sources, parameters) so the model uses the right data in each stage. The XMLA endpoint is a separate, programmatic path that lets external tools and CI/CD scripts read/write semantic models for fully automated deployment.
Deployment Pipeline Stages
| Stage | Bound To | Purpose |
|---|---|---|
| Development | Dev workspace | Active building and iteration |
| Test | Test workspace | Validation, UAT, performance checks against test data |
| Production | Prod workspace | Live content consumed by the business |
Key behaviors tested on the exam:
- Comparison indicators show which items differ between adjacent stages, so you can deploy only changed items rather than everything.
- You can deploy selected items or the whole stage; promotion always flows forward (Dev → Test → Prod).
- Each stage points at a distinct workspace, which is why the pipeline is the natural complement to per-environment workspaces.
Deployment Rules
When content moves from Dev to Test to Prod, it must not keep pointing at development data. Deployment rules solve this:
- A rule is configured on a target stage (e.g., on Production).
- It rebinds a setting after deployment — for example, swap a semantic model's data source from the dev database to the prod database, or change a parameter value.
- Without deployment rules, a promoted Prod model could still query Dev data — a frequent scenario answer.
XMLA Endpoint Deployment
The XMLA endpoint exposes a semantic model through the XML for Analysis protocol so external tools can connect to it directly:
- Read access supports tools like DAX Studio, Tabular Editor, and SQL Server Management Studio for analysis and queries.
- Read/Write access supports scripted, automated deployment of model metadata — for example, a CI/CD pipeline that deploys a TMDL/BIM definition without using the Fabric pipeline UI.
- It is the mechanism for enterprise CI/CD when the deployment pipeline UI is not sufficient (e.g., advanced automated release management).
Pipeline UI vs XMLA — Which When
| Need | Use |
|---|---|
| Guided, UI-driven Dev→Test→Prod promotion with rules | Deployment pipeline |
| Fully scripted, automated semantic-model deployment in CI/CD | XMLA endpoint (read/write) |
| Connect external modeling/analysis tools to a model | XMLA endpoint (read) |
After promoting a semantic model from Development to Production via a deployment pipeline, the model in Production still queries the development database. The team wants future deployments to automatically point the Production model at the production database without manual edits. What should they configure?