Fabric Lifecycle Management: Git Integration and Deployment Pipelines

Lifecycle management in Fabric is the discipline of moving analytics content through its life — authored, reviewed, tested, released, changed again — using built-in capabilities: Git integration (version control for item definitions), database projects (source-controlled schema for Warehouses), deployment pipelines (staged promotion between workspaces) and variable libraries (stage-specific configuration values). Together they replace the failure mode DP-700 scenarios love to describe: one shared workspace where everyone edits production directly, nobody can see what changed, and a bad edit takes down the nightly load.

The mental model that keeps every question straight is source control versus promotion. Git integration answers development-time questions: who changed this notebook, what did the previous version look like, can a colleague review my change before it lands, can I work on a feature in isolation? Deployment pipelines answer release-time questions: how does content validated in a test workspace reach production identically, and how do items pick up production connections instead of test ones?

One boundary applies to all of it: Fabric lifecycle tooling versions and deploys item definitions — metadata, not data. Committing a Lakehouse to Git versions the Lakehouse item definition, not the Delta tables inside it; deploying a Lakehouse to the production stage does not copy its files or tables. Data arrives in each environment by running your ingestion against that environment. Keep that boundary in mind whenever an answer option implies Git or a deployment pipeline moved data — it is nearly always the trap.

Git integration connects a Fabric workspace to one branch and folder of a cloud Git repository so that supported items are serialized into the repository as source files. The supported providers are Azure DevOps Services (Azure Repos), GitHub and GitHub Enterprise Cloud — cloud only. On-premises Azure DevOps Server and self-hosted GitHub Enterprise Server are not supported, so a scenario that insists on an on-premises Git server cannot use Fabric Git integration directly.

Connecting takes permissions on both sides. A tenant admin must have enabled the Git integration tenant settings. In Fabric, only a workspace Admin can connect, disconnect or change the connection. In Git, connecting and updating need Read on the repository, while committing needs write access (Contribute in Azure Repos, read-and-write contents in GitHub) and a branch policy that allows direct commits. Each user authenticates to the provider with their own account.

The Admin chooses the organization or account, repository, branch and a Git folder; the folder lets several workspaces share one repository without colliding. A workspace connects to exactly one branch at a time, so multi-branch work means multiple workspaces.

What the repository holds

• Item definitions only — each supported item becomes a folder of definition files plus a platform metadata file. Data never goes to Git.
• Workspace folders are mirrored: items in a workspace folder are exported to a Git folder of the same name, up to 10 levels deep. Empty workspace folders are not written to Git.
• Unsupported item types are ignored — they are not committed, not updated and not deleted; they simply stay in the workspace, and the workspace list shows their Git status as Unsupported item. Versioning an unsupported item type cannot be solved by Git integration alone.

The first sync

When you connect, Fabric makes both sides match. If one side is empty, content is copied from the non-empty side. If both have content, you must pick a direction: Commit exports the workspace and overwrites the Git folder (safe, because the branch history keeps the old files recoverable), or Update overwrites the workspace from Git (destructive, because a workspace has no history — Fabric asks you to confirm). Fabric never merges the two sides on connection.

Trigger words for Git integration: track changes, audit who edited an item, roll back to a previous version, code review for notebooks. If the need is about history, review or rollback, the tool is Git, not a deployment pipeline.

Day-to-day source control runs through the workspace's Source control pane, which compares workspace items with the connected branch and lists Changes (workspace edits to commit) and Updates (new commits in the branch to pull in). Each item in the workspace list also shows a Git status such as Synced, Uncommitted changes, Update required or Conflict.

Because commit is blocked while updates are pending, the working habit is update first, then commit.

Conflicts

A conflict is an item changed in both the workspace and the branch since the last sync. You cannot commit it, and Fabric never merges item definitions for you. Selecting Update opens the Resolve conflicts dialog, where you choose a whole version per item: Accept incoming changes (the branch version overwrites the workspace copy) or Keep current content (the workspace version stays, ready to commit). Undo on the conflicted item is the other in-Fabric route: it returns the item to the last synced state, after which Update brings in the branch version.

When you need both sets of edits, or branch policy blocks direct commits, resolve in Git: use Checkout new branch, which creates a branch from the last synced commit and re-points the current workspace to it without changing workspace content, so your uncommitted edits survive; commit them to the new branch; merge into the original branch with a pull request, resolving the conflict in Git tooling; then switch the workspace back to the original branch and Update.

Disconnecting and reconnecting is not a conflict tool: on reconnection both sides have content, so you must choose a direction and every item is overwritten one way. When a scenario says one engineer's work vanished after a conflict, the diagnosis is an overwrite — and the prevention is isolated branches, which the next section covers.

Because one workspace binds to one branch, feature isolation means one branch plus one workspace per line of work, and Branch out to another workspace creates that pair in one step. It is one of three branch actions in the Source control pane, and the exam tests the differences:

The workspace setting Allow users with at least Contributor role to change Git branch lets Contributors and Members who have write access to all items switch branches and check out new ones without being made Admin — the least-privilege answer when someone only needs to change branches.

The feature flow end to end: branch out from the team's development workspace; build and test in your isolated workspace, committing to your feature branch; open a pull request in Azure DevOps or GitHub to merge into the main development branch, where teammates review diffs of the serialized definitions; after the merge, the shared development workspace shows incoming updates, and Update pulls the reviewed work in. The pull request is the review gate: re-pointing a shared workspace at a feature branch replaces its content without review, and a deployment pipeline promotes between stages rather than merging branches.

This is the answer pattern for developers keep overwriting each other's changes, changes must be reviewed before they reach the shared workspace or an engineer needs to experiment without affecting the team: isolation through branches and workspaces plus pull-request review, not workspace roles. The isolated workspace needs capacity, and data does not branch with the items, so teams typically point development branches at development data.

A SQL database project captures a Warehouse's schema — tables, views, stored procedures, functions, security objects — as .sql DDL files that live in source control and build into a deployable dacpac. When a workspace containing a Warehouse is connected to Git, the Warehouse is itself committed as a database project: its folder in the repository holds individual .sql files per object, never data and never a compiled dacpac. You can also extract a project from an existing Warehouse with the SQL Database Projects tooling in Visual Studio Code or Visual Studio.

Building the project (locally or in a CI pipeline, which validates that the schema compiles) produces the dacpac — a model of the intended schema. SqlPackage then works with that model through distinct actions:

The change script is a diff between the dacpac and a particular target. If production may have drifted from test — for example after a hotfix applied directly in production — only a Script generated against the production Warehouse shows what Publish will run there. That gives the approval pattern: Script against the real target, review, then Publish the same dacpac.

Schema compare diffs a project against a live Warehouse (or two schemas) so you can detect drift and either import the hotfix into the project or overwrite it from source. Exam triggers — version control for Warehouse schema, repeatable schema deployment, detect drift, dacpac — point to database projects with SqlPackage when the scenario is about T-SQL objects rather than Fabric items.

A deployment pipeline is Fabric's staged-promotion tool: a sequence of stages — development, test and production by default, configurable from two to ten — where each stage is assigned one workspace. The number of stages and their names are set when you create the pipeline and cannot be changed afterwards; a different stage layout means a new pipeline.

Assigning workspaces

• The workspace must be on a Fabric capacity.
• A workspace can be assigned to only one deployment pipeline, and to one stage.
• Assigning needs pipeline admin plus the workspace Admin role on the workspace being assigned.

Who can deploy

The pipeline has a single permission, pipeline admin, which lets you view, share, edit and delete the pipeline but grants nothing on workspace content. To deploy between existing stages you need pipeline admin and at least Contributor in both the source and the target workspaces — Member or Admin is not required, and Viewer in either one is not enough. Comparing stages needs the same Contributor-or-higher roles in both. (Deploying to an empty stage needs pipeline admin and Contributor on the source; the deploying user becomes the new workspace's admin.) Some items add an ownership requirement: deploying a dataflow requires being its owner, and when the tenant setting that blocks republishing of semantic models is enabled, deploying a semantic model requires owning it.

Deploying

You can deploy everything or selected items, to an adjacent stage in either direction. Backward deployment is how you build a pipeline around an existing production workspace: assign it to the production stage, then deploy backward to create test and development copies, leaving production untouched. When a deployment overwrites an existing paired item it replaces only its content; the target item's ID, URL and permissions stay unchanged.

Comparing before you deploy

The compare view checks adjacent stages item by item and labels each one Only in source (deploying creates it), Different from source (deploying overwrites it), Same as source or Not in source (it exists only in the target; deploying leaves it alone). Change review shows the schema-level differences of a Different item. Two things also mark an item Different: a deployment rule that is defined but not yet applied, and a moved item — folder path is part of an item's name in deployment pipelines, so a notebook moved to a new folder shows Different with no schema change, and deploying moves its paired item into the same folder (creating the folder if needed) rather than duplicating it.

Keep the neighbouring tools apart: compare previews the next deployment, deployment history records past deployments, lineage view shows item dependencies, and the Git status column reports sync with a branch.

Trigger words for deployment pipelines: separate development, test and production environments, promote content between them, see the differences before releasing. History, review and rollback needs belong to Git instead.

A deployment copies item definitions and metadata — data sources, parameters, model metadata, report pages, item relationships — and nothing else. A Lakehouse deploys as an empty Lakehouse; a Warehouse moves as an item, not its rows; a semantic model needs a refresh in the new stage because its data was not copied.

Some settings are per stage and never copied, so they must be set once in each stage's workspace and are kept across later deployments:

• Data, item IDs and URLs
• Workspace and item permissions, and workspace settings
• For semantic models: refresh schedule, data source credentials, role membership, query caching and endorsement settings
• App content and settings

Do not confuse these with deployment rules: a rule overrides a property that is copied (a data source or parameter); a refresh schedule or credential is simply not part of what deploys.

Autobinding and Select related

When an item depends on another — a report on a semantic model, a model on a lakehouse — deployment tries to autobind it to the paired dependency in the target stage. If the dependency is neither in the deployment nor already in the target stage, the deployment fails; Select related adds the dependencies to your selection to avoid that. The exception the exam likes: a Direct Lake semantic model is not autobound. Deployed with its lakehouse, it still points at the source-stage lakehouse until you add a data source rule on the model in the target stage. Autobinding also does not apply to Dataflow Gen2.

A deployment rule is configured on an item in a target stage and rewrites part of that item's copied definition every time a deployment lands there, so content flows through the pipeline unchanged while its connections become stage-appropriate. Rules exist only for specific item types:

Items not in the table — notably data pipelines, Dataflow Gen2 and copy jobs — take no deployment rules; they get stage-specific values from a variable library (next section). A data source rule can only swap to a source of the same type.

Rules have firm prerequisites:

• They cannot be created in the development (first) stage — there is nothing upstream to override.
• You must be pipeline admin, at least Contributor in the target workspace, and the owner of the item. Workspace role alone does not satisfy this — even an Admin must take over the item (become its owner) before its rules can be edited.
• The item must already exist in the target stage, so the sequence is deploy once, set rules, then deploy routinely.
• Rules take effect from the next deployment to that stage; they do not change the item already sitting there (compare does take them into account straight away).

Once defined, a rule re-applies on every deployment, which makes promotion repeatable rather than a checklist of manual edits. Trigger words: after deploying to production the report still shows test data, notebooks must use a different Lakehouse per stage, a semantic model in a later stage keeps reading the earlier stage's source — a rule on the target stage, never a hand edit to the deployed item.

A variable library is a Fabric item that holds named variables with one value per value set (for example Default, Test and Prod), and that other items in the same workspace read at run time. It is the way to give stage-specific configuration to items that deployment rules do not cover.

Items that can consume a variable library: data pipelines, notebooks (through NotebookUtils and %%configure), Dataflow Gen2, lakehouse shortcuts, copy jobs, user data functions and Eventstream. Semantic models, paginated reports and Warehouse T-SQL objects are not consumers — semantic models and paginated reports still use deployment rules.

How the stages get different values:

• Every value set is part of the library's definition, so all of them deploy with the library and are committed to Git.
• Exactly one value set is active in each workspace's copy of the library. The active selection is workspace item state: it is not carried by deployment, so you set it once in each stage's workspace (Test in test, Prod in production) and later deployments keep it.
• Because the active selection stays with each workspace, switching the active set in one stage affects only that stage, whatever is deployed afterwards.
• Alternate value sets store only overrides: any variable a set does not override inherits the Default value. Editing a Default value therefore reaches every stage whose active set does not override that variable — not only stages where Default is active.

Contrast this with a plain pipeline parameter default: the default is part of the pipeline definition, so each deployment overwrites a per-stage edit to it with the development value. Data pipelines also take no deployment rules, so per-stage pipeline configuration that must survive every deployment lives in a variable library, with the active value set chosen once in each stage.

Git integration and deployment pipelines are complements, not competitors: Git governs how changes are made (history, isolation, review), deployment pipelines govern how approved content is released (staged promotion, comparison, rules). The canonical Fabric setup connects only the development workspace to Git and promotes forward with a deployment pipeline — test and production workspaces are never edited directly and need no Git connection of their own.

Now the scenario. A team of four engineers builds a Lakehouse-based solution and must satisfy: reviewed changes only, no lost work from simultaneous edits, identical releases to test and production, and production items reading production data. The answer assembles itself: connect the development workspace to a branch in Azure DevOps; each engineer branches out to a private workspace and merges back by pull request; the shared development workspace pulls merged work via Update; a three-stage deployment pipeline promotes development → test → production, with the compare view checked before each production deploy; deployment rules on the test and production stages repoint notebooks' default Lakehouse and the Direct Lake model's data source; the data pipelines read lakehouse references from a variable library whose active value set is chosen once per stage; refresh schedules and credentials are set once in each stage; and the Warehouse schema rides in a database project whose dacpac is scripted against, then published to, each stage's Warehouse. Every requirement maps to exactly one capability — which is precisely how the exam wants you to think.