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 three built-in capabilities: Git integration (version control for item definitions), database projects (source-controlled schema for Warehouses), and deployment pipelines (staged promotion between workspaces). 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 automatically repoint from test data sources to production 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 a branch in Azure DevOps (Azure Repos) or GitHub — the two supported providers — so that supported items in the workspace are serialized into the repository as source files. A workspace admin makes the connection in workspace settings under Git integration, choosing the organization, repository, branch, and a folder within the branch; the folder matters because it lets several workspaces share one repository without colliding. Tenant admins must have the relevant Git integration settings enabled, and users authenticate to the provider with their own credentials.

Once connected, each supported item is stored in the repo as a folder of definition files plus a platform metadata file — human-readable sources that diff and review like any other code. That is the point: a notebook change becomes a visible diff in a pull request, not an invisible edit inside a workspace.

Two scoping rules earn exam marks. First, a workspace connects to exactly one branch at a time — the branch is the workspace's source of truth, and multi-branch work means multiple workspaces. Second, not every item type is supported for Git sync; unsupported items simply live in the workspace without version control, and a scenario that requires versioning an unsupported item type cannot be solved by Git integration alone.

Trigger words for this capability: track changes, audit who edited, roll back to a previous version, code review for notebooks. All of them point at connecting the workspace to a branch — none of them point at a deployment pipeline.

Day-to-day source control in Fabric runs through the workspace's Source control panel, which continuously compares workspace items against the connected branch and shows two directions of change. Commit pushes workspace changes (new, modified, or deleted items) into the branch; Update pulls incoming branch changes — typically merged pull requests from teammates — into the workspace. Each item carries a sync status, so you can see at a glance what is ahead, behind, or in sync.

A conflict arises when the same item changed in both places since the last sync: you edited a notebook in the workspace while a teammate's change to the same notebook merged into the branch. Fabric will not silently merge item definitions. You resolve per item by choosing which side wins — keep the workspace version (your local change overwrites the branch content on next commit) or take the Git version (the branch overwrites your workspace copy). For finer-grained resolution, you handle it in Git itself: resolve the merge in a branch using standard Git tooling, then update the workspace from the resolved branch.

The habit the exam rewards is the same one real teams use: update before you commit, keep commits small, and treat the branch as the source of truth. When a scenario describes two engineers who both edited the same item and one person's work vanished, the diagnosis is a conflict resolved by overwriting — and the prevention is isolated branches per engineer, which is exactly where the next section picks up.

Because one workspace binds to one branch, feature isolation in Fabric means one branch plus one workspace per line of work — and the branch out capability automates the pair. From a Git-connected workspace, branching out creates a new branch from the current one and a separate workspace connected to that new branch, giving an engineer a private, fully functional copy of the content to modify without touching the shared workspace.

The flow end to end: branch out from the team's development workspace; build and test your change in your isolated workspace, committing to your feature branch as you go; open a pull request in Azure DevOps or GitHub to merge the feature branch into the main development branch, where teammates review the diffs of the serialized item definitions; after the merge, the shared development workspace shows incoming changes, and an Update pulls the reviewed work in. Your feature workspace and branch are then disposable.

This is the answer pattern for a family of DP-700 scenarios: 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. The resolution is always isolation through branches and workspaces plus pull-request review — not workspace roles, and not a deployment pipeline, which governs promotion between environments rather than collaboration within one. Remember that the isolated workspace needs capacity to run on and that data does not branch with the items: the feature workspace sees whatever data its items can reach, 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 a set of .sql DDL files that live in source control and build into a deployable artifact. Where Git integration versions Fabric item definitions, a database project versions the database code inside the Warehouse, which is exactly the layer a data engineering team changes most.

The workflow: extract the Warehouse schema into a project using the SQL database projects tooling in Visual Studio Code (or Visual Studio), commit the project to the same repository as the rest of your Fabric content, and evolve the schema through normal code review. Building the project produces a dacpac — a compiled model of the intended schema — and deploying the dacpac with SqlPackage compares that model against a target Warehouse and generates the change script to bring the target into line. The same dacpac deploys to development, test, and production Warehouses, which is how schema stays identical across stages without hand-run scripts.

Schema compare rounds out the toolset: it diffs a project against a live Warehouse (or two schemas against each other) so you can detect drift — someone hot-fixing production directly — and either import the fix into the project or overwrite it from source.

Exam triggers: version control for Warehouse schema, repeatable schema deployment across environments, detect schema drift, or dacpac all point to database projects with SqlPackage. When a scenario is about T-SQL objects rather than Fabric items, this — not workspace Git sync alone — is the intended answer.

A deployment pipeline is Fabric's staged-promotion tool: a sequence of stages — by default development, test, and production, and configurable from two up to ten with custom names — where each stage is assigned one workspace. Deploying copies item definitions from one stage's workspace into the adjacent stage's workspace: the first deployment creates the items in the target, and subsequent deployments overwrite the target items' definitions with the source versions. You can deploy everything or select specific items, and creating the pipeline itself requires admin rights on the workspaces you assign.

Before deploying, the compare view is your safety check. The pipeline compares adjacent stages item by item and flags each as identical, different, or existing only in one stage — so you can see precisely what a deployment will add or overwrite in test or production before you commit to it. Reviewing the comparison before deploying to production is both the real-world practice and the exam's expected answer to how do you verify what will change.

The data boundary applies with full force here: deployment copies metadata only. A Lakehouse deploys as an empty Lakehouse; Warehouse deployment moves the item, not its rows; pipelines and notebooks arrive pointing wherever their definitions say. That is deliberate — production data belongs to production processes — and it is why the next section's deployment rules exist.

Trigger words: separate development, test, and production environments, promote content between workspaces, see differences before releasing. All deployment pipeline. If the scenario is about history, review, or rollback of individual edits, it is Git — not this.

Deployment rules solve the problem that a deployed item is a byte-for-byte copy of its source: without intervention, the semantic model you deploy to production still points at the test Lakehouse, and the notebook still writes to the development Warehouse. A deployment rule is configured on an item in a target stage and rewrites part of that item's definition whenever a deployment lands — so content flows through the pipeline unchanged while its connections become stage-appropriate automatically.

The two rule families to know are data source rules — repoint an item's data source, such as switching a semantic model or Dataflow Gen2 from the test database to the production one — and parameter rules, which set a parameter to a stage-specific value, covering cases like a connection string fragment or an environment name a Dataflow consumes. Notebooks support rules for their attached default Lakehouse, so a deployed notebook reads and writes the production Lakehouse rather than the development one it was authored against.

Rules belong to the stage, not the deployment: once defined on the production stage's copy of an item, every future deployment re-applies them, which is what makes promotion repeatable rather than a checklist of manual edits. Two gotchas earn exam marks. Rules take effect from the next deployment after you define them — they do not retroactively fix the item already sitting in the stage. And rules can only be set on items that exist in the target stage, so the sequence is deploy once, configure rules, then deploy routinely.

Trigger words: after deploying to production the report still shows test data, or notebooks must use a different Lakehouse per stage — the answer is a deployment rule on the target stage, never editing the production item by hand.

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, then 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 semantic model's data source; and the Warehouse schema rides in a database project whose dacpac deploys to each stage's Warehouse. Every requirement maps to exactly one capability — which is precisely how the exam wants you to think.