Skip to content
FR

Maintaining the Analytics Development Lifecycle

Step 3 of 20

Maintaining the Analytics Development Lifecycle

Introduction

This lesson completes the domain Maintain a data analytics solution (25–30% of the DP-600 skills measured). This course targets the English syllabus effective October 19, 2026. Microsoft does not publish the question count or the question-type mix for the exam, so OnLevelUp mock exams use a 50-question practice length and an unofficial 80% practice target; neither is equivalent to the official 700/1000 scaled passing score.

Security protects a solution; the development lifecycle keeps it changing safely. A report that is edited directly in production, a semantic model that nobody can roll back, or a column renamed without checking who consumes it are all lifecycle failures. The exam presents a team, a deployment pain point and a toolbox, and asks which tool fits. After this lesson you will be able to connect a workspace to Git, develop with Power BI Desktop projects (.pbip), promote content through deployment pipelines, assess the downstream impact of a change, deploy a semantic model through the XMLA endpoint, and package reusable assets.

Learning objectives

  • Configure version control for a workspace and explain what is synchronised.
  • Describe the structure and benefits of Power BI Desktop projects (.pbip) over .pbix.
  • Design a dev/test/prod flow with deployment pipelines, rules and the compare view.
  • Perform impact analysis of downstream dependencies before changing an item.
  • Use the XMLA endpoint to deploy and manage semantic models.
  • Choose between .pbit, .pbids and shared semantic models as reusable assets.

1. Version control for a workspace (Git integration)

Fabric Git integration connects a workspace to a branch in a Git repository (Azure DevOps or GitHub). The repository becomes the source of truth for item definitions.

Key facts:

  • You connect a workspace to one branch and one folder of a repository. Items are serialised as folders of text files (for example a semantic model as TMDL or BIM definition files, a report as PBIR/definition files, notebooks as source files).
  • Two directions of sync: Commit pushes workspace changes to the branch; Update pulls branch changes into the workspace. The Source control panel shows which items differ.
  • Data is not stored in Git: only definitions. A lakehouse's tables, a warehouse's rows and a semantic model's cached data are not committed.
  • Not every item type is supported; the supported list evolves, so unsupported items are simply not tracked.
  • Git integration works with Enhanced metadata semantic models; older models must be upgraded (republish from Power BI Desktop or change the compatibility level).
  • Typical branching: each developer works in a feature branch with an isolated workspace (branch out to a new workspace), then merges through a pull request into the main branch connected to the shared dev workspace.
  • Merge conflicts are resolved in Git, not in the workspace. Resolve in the repository, then Update the workspace.

Example. Adventure Works has a dev workspace linked to the main branch folder /fabric. Priya wants to refactor measures. She creates a feature branch workspace from the Source control panel, edits the semantic model, commits, opens a pull request, a colleague reviews the TMDL diff, and after merge the dev workspace shows an Update available.

2. Power BI Desktop projects (.pbip)

A .pbix is a single binary file. A .pbip project is a folder of text files that Power BI Desktop can open:

Text
Sales.pbip
Sales.SemanticModel/
  definition.pbism
  definition/               <- TMDL files: tables, relationships, roles, expressions
Sales.Report/
  definition.pbir
  definition/               <- report pages, visuals (PBIR format)

Why it matters:

  • Text files give readable diffs and merges in Git, which a .pbix cannot.
  • The semantic model and the report are separate folders, so a model can be edited without touching reports and several reports can point to one model.
  • You can edit TMDL in VS Code or the TMDL view and use external tools; changes made outside Desktop appear when you reopen the project.
  • A project does not contain the imported data cache by default (the data is refreshed after opening or kept in an ignored cache file), keeping the repository small.
  • For automated deployment of PBIP content from source control, Microsoft documents the open-source fabric-cicd Python library, which can parameterise values (for example a connection string per environment).

Exam tip: a requirement such as "see exactly what changed in a measure between versions" or "use pull requests for model changes" points to .pbip with Git integration.

3. Deployment pipelines

A deployment pipeline promotes content through stages, typically Development → Test → Production. Each stage is bound to a workspace.

Core concepts:

Concept Meaning
Stage A pipeline step bound to one workspace (2 to 10 stages are possible; three is the default)
Deploy Copy selected items forward (or backwards) to the next stage, creating or overwriting items there
Compare Shows which items differ between two stages (new, different, same) before you deploy
Deployment rules Per-stage overrides for data source, parameter and (for supported items) default lakehouse so that Test and Prod point to their own sources
Selective deployment Choose specific items instead of the whole stage
Backward deployment Possible to an empty stage
Auto-binding Items keep connections between each other (report to model) within the target stage

Practical points:

  • The pipeline copies definitions, not data. After deploying a semantic model to Test, you must refresh it so it holds data from the Test source.
  • Deployment rules are the right tool for changing a SQL server name or a parameter per stage. Editing the item in Prod directly breaks the discipline.
  • Permissions: you need at least Contributor on the workspaces (and be a pipeline admin) to deploy; Viewers of Prod can consume the results.
  • Pipelines can be driven by the REST API or Azure DevOps tasks for automation.
  • Git and pipelines combine well: Git connected to the Dev workspace only, then deployment pipelines promote to Test and Prod (a hybrid), or one branch per stage with a Git-only flow. Both are documented patterns in Microsoft's CI/CD guidance.

Worked example 1: pipeline rules. Scenario. A semantic model uses a Power Query parameter ServerName set to sql-dev.contoso.com. After deployment to Production the dataset still reads the dev server. How do you fix this permanently?

Reasoning.

  1. Editing the parameter in Prod fixes one deployment but is lost conceptually, and must be repeated.
  2. Deployment rules can override a parameter for the target stage.
  3. Open the Prod stage, choose the semantic model, set a parameter rule for ServerName to sql-prod.contoso.com.
  4. Redeploy and refresh: the rule is applied at each deployment.

Solution. A deployment rule on the Production stage for the parameter.

Why the other choices are worse. Manual edits in Prod are repeated and unaudited. Creating a second model for Prod duplicates logic. Using one workspace for all stages removes isolation.

4. Impact analysis of downstream dependencies

Before you rename a column, delete a measure or change a lakehouse table, you need to know who depends on it.

Tools:

  • Lineage view in the workspace shows the flow from data source to lakehouse, dataflow, semantic model, report and dashboard, across workspaces if you have access.
  • Impact analysis on a semantic model (or dataflow, lakehouse) lists the downstream reports and dashboards, with their owners and view counts, and lets you notify contacts of affected items. It requires access to see the dependants.
  • Fabric item dependencies in the OneLake catalog and Microsoft Purview extend this across the tenant.
  • Dependant counts guide the change window: a model feeding 40 reports requires a communication and a staged rollout.

Process: check impact → notify owners → apply the change in Dev → compare in the pipeline → deploy to Test → validate → deploy to Prod.

Worked example 2. Scenario. You plan to rename Sales[Amt] to Sales[Net Amount] in the shared model Corporate Sales. How do you reduce the risk? Steps. Open lineage view → select the model → run impact analysis → notice 18 reports in four workspaces → contact the owners with the notify feature → rename in Dev, fix visuals in affected reports, or keep the old name as a hidden alias column during transition → deploy. Solution. Impact analysis plus notification before the change. Worse options: renaming in Prod first (breaks visuals immediately); asking users to check manually (no reliable list).

5. Deploying semantic models through the XMLA endpoint

The XMLA endpoint is an open-platform connection that exposes semantic models in a Fabric/Premium capacity to client tools using the Analysis Services protocol.

  • Enable read-write XMLA in the capacity settings (the capacity admin controls it); read-only allows queries only.
  • The connection string is the workspace URL: powerbi://api.powerbi.com/v1.0/myorg/<WorkspaceName>.
  • Tools: Tabular Editor, SQL Server Management Studio, Visual Studio / Analysis Services projects, ALM Toolkit (schema compare), PowerShell and TMSL scripts.
  • Typical uses: deploy a model with metadata only, apply partition-level refreshes, run advanced refresh commands, edit model features not available in Desktop, and compare schemas between workspaces.
  • A semantic model created or modified through XMLA may no longer be downloadable as .pbix from the service. Consider this when the team's workflow relies on downloading PBIX files.
  • Deploying with XMLA requires the semantic model to be in an Enhanced metadata-compatible format and the user to have write permission on the workspace.

Exam tip: keywords "metadata-only deployment", "partition refresh", "script the model", "schema compare" mean XMLA endpoint.

6. Reusable assets

Asset What it is Use it when
.pbit (Power BI template) A report/model file without data; prompts for parameters on opening Distributing a standard report layout and model to new analysts
.pbids (data source file) A JSON file that stores a connection (server, database) Giving analysts a pre-configured connection without credentials
Shared semantic model One published model reused by many reports through a live connection (or composite model) Avoiding multiple copies of the same logic; central certification

A shared, certified semantic model is the preferred reuse pattern: one definition of measures, one refresh schedule, one place for RLS. Report authors need Build permission on the model to create reports.

Worked example 3: Git-only or hybrid? Scenario. Tailspin has a lakehouse, notebooks, a semantic model and reports. The team wants peer review of every change, but also wants a business-owned Test workspace promoted with one click and without maintaining three long-lived branches.

Reasoning.

  1. A Git-only flow with one branch per stage gives full history but requires merging between stage branches and calling Git APIs or pipelines of your own for each promotion.
  2. A hybrid keeps Git on the Dev workspace only, where pull requests provide review, and uses a deployment pipeline for Test and Prod, where rules and compare give a visual promotion step.
  3. The requirement "one click" and "no long-lived branches" matches the hybrid.

Solution. Connect Git to Dev only, review through pull requests, then promote with a deployment pipeline using deployment rules.

Why the alternatives are weaker. Git-only needs more automation. A pipeline without Git has no code review or history of definitions. Manual export and import is neither repeatable nor auditable.

Practical commit routine in Dev. Pull the latest Update, make changes in your branch workspace, check the Source control panel to see which items changed (a renamed table touches the model and each report that references it), write a commit message describing the business reason, and commit. If the panel reports a conflict, resolve it in the repository by choosing which version to keep, then Update again. Never use "Revert to previous" in a shared workspace without telling colleagues, because it overwrites their uncommitted edits.

Deployment checklist before pushing to Production. Run Compare and read every item marked Different; confirm that no item was edited directly in Test; verify that deployment rules exist for every data source that differs; make sure the capacity of the target workspace is available and that the semantic model can refresh with the target credentials; schedule a refresh immediately after deployment; and notify downstream owners if the change alters column names or measures.

Comparison: choosing the lifecycle tool

Need Tool
Track item changes and review them Git integration
Readable model/report diffs in the repo .pbip project
Promote the same content through stages Deployment pipeline
Different connection per stage Deployment rule
Know who is affected Impact analysis / lineage
Metadata-only deployment, partition refresh, schema compare XMLA endpoint
Standard report starting point .pbit
Pre-configured data connection .pbids
One model for many reports Shared semantic model

Common pitfalls

  • Expecting Git or pipelines to move data; they move definitions, and you refresh afterwards.
  • Editing the Production workspace directly and then overwriting the change on the next deployment.
  • Forgetting that a model with legacy metadata must be upgraded for Git and pipelines.
  • Granting Build on a semantic model when only Read is needed.
  • Assuming a .pbix downloaded months ago still matches a model that was modified through XMLA.
  • Ignoring impact analysis before renaming or deleting objects.

Exam tip: when two answers both "work", prefer the one that is automated, repeatable and keeps Prod read-only for developers.

Mini case study

Northwind Retail has one workspace where five BI developers edit a shared Sales model and 30 reports. Last month a measure change broke a regional dashboard and nobody could tell who changed what.

Proposed redesign.

  1. Convert the .pbix to a .pbip project and connect the dev workspace to a Git repository; feature branches and pull requests give reviewable TMDL diffs.
  2. Create a deployment pipeline with Dev, Test and Prod workspaces; add deployment rules for the SQL server parameter per stage.
  3. Before each model change, run impact analysis and notify the owners of dependent reports.
  4. Make Sales a shared, certified semantic model; report authors get Build, and reports live in separate workspaces.
  5. For nightly partition-level processing of the large fact table, use the XMLA endpoint with a scripted refresh.
  6. Give analysts a .pbit template with the corporate theme and a .pbids file for the warehouse connection.

Commentary. Git provides history and review; the pipeline provides controlled promotion; impact analysis lowers the blast radius; the shared model removes duplicated logic. Developers become Viewers in Prod.

Key terms

  • Git integration: synchronises workspace item definitions with a branch.
  • .pbip: folder-based Power BI project of text definitions.
  • Deployment pipeline: staged promotion of content with rules and compare.
  • Impact analysis: list of downstream items affected by a change.
  • XMLA endpoint: Analysis Services protocol access to published models.
  • .pbit / .pbids: template without data / data source connection file.
  • Shared semantic model: model reused by many reports.

Summary checklist

  • I can explain what Git integration commits and what it does not.
  • I know why .pbip beats .pbix for team development.
  • I can design a Dev/Test/Prod pipeline with deployment rules and a compare step.
  • I can run impact analysis before changing a shared item.
  • I can name three XMLA endpoint uses and its capacity prerequisite.
  • I can pick between .pbit, .pbids and a shared semantic model.
  • I remember that the practice length (50 questions) and 80% target are not official, and that the course targets the syllabus effective October 19, 2026.

Official sources