Lifecycle Management with Git, Database Projects and Deployment Pipelines

What it is

Lifecycle management moves Fabric items from development to production in a controlled way. Git integration puts item definitions under version control, database projects manage warehouse schema as code, and deployment pipelines promote content between workspaces that act as stages.

Git and deployment pipelines move definitions, not data. A lakehouse arrives in the next stage as an item without its tables, and you load data there with your own processes.

How it works

Version control with Git integration

A workspace admin connects the workspace to Azure DevOps (Azure Repos) or GitHub, choosing an organization, repository, branch and folder. One workspace connects to one branch at a time.

The Source control panel shows which items have uncommitted changes and which have incoming updates. If the same item changed on both sides, you resolve the conflict before you can commit, for example by keeping one version or by fixing it in Git.

Each item is stored as a folder of text files. A notebook is saved as source code, a pipeline as JSON, and a warehouse as a SQL database project, so changes are readable in a pull request.

A common pattern: each developer works in a private workspace on a feature branch, opens a pull request into main, and the shared development workspace is connected to main.

Database projects

A SQL database project describes a warehouse (or SQL database) as a set of CREATE scripts plus a project file. You get one by connecting the warehouse to Git or by downloading the project from the warehouse, then edit it in VS Code or Visual Studio with the SQL Database Projects tooling.

Building the project validates the schema and produces a .dacpac file. Publishing the dacpac compares it with the target warehouse and applies only the changes needed.

-- Tables/dbo.DimCustomer.sql inside the project
CREATE TABLE dbo.DimCustomer
(
    CustomerKey  INT          NOT NULL,
    CustomerID   VARCHAR(20)  NOT NULL,
    CustomerName VARCHAR(200) NOT NULL,
    City         VARCHAR(100) NULL
);

SqlPackage /Action:Publish /SourceFile:bin/Debug/SalesDW.dacpac /TargetConnectionString:"<warehouse connection string>"

Database projects suit teams that already use SQL Server tooling, need schema compare, or run deployments from Azure DevOps or GitHub Actions.

Deployment pipelines

A deployment pipeline has 2 to 10 stages; the default is Development, Test and Production. Each stage is assigned one workspace on a Fabric capacity.

For values a pipeline or notebook reads at run time, such as a connection or a folder name per stage, a variable library holds one value set per stage. Deployment pipelines and Git can be combined: Git for development history, deployment pipelines for promotion.

A worked example

A team builds notebooks, a lakehouse and a pipeline. Development notebooks point at LH_Dev, but in production they must use LH_Prod. The data in LH_Dev is test data that must never reach production.

They create a deployment pipeline with Development, Test and Production stages and set a default lakehouse deployment rule on each notebook in Test and Production. Deploying copies only definitions, so the test data stays behind, and the production lakehouse is loaded by the production pipeline run.

How the exam asks about this

• "Track every change to notebooks and roll back a bad change." Connect the workspace to Git and commit.
• "Promote items from test to production without copying data, and use a different data source in production." Deployment pipeline with deployment rules.
• "Manage the warehouse schema in Visual Studio Code and deploy only the differences." SQL database project published as a dacpac.