Microsoft Fabric CI/CD: Git Integration, Deployment Pipelines and Automation

1. What is CI/CD in Microsoft Fabric?

CI/CD means continuous integration and continuous delivery or deployment. In Fabric it is the habit of tracking changes to analytical items, reviewing them, moving validated content across environments, and managing the configuration differences between workspaces.

A Fabric solution can include Lakehouses, notebooks, Spark job definitions, Data Factory pipelines, Dataflows Gen2, semantic models, reports, and more. These items depend on one another, so promoting them is rarely as simple as copying a single file.

Keep three concepts separate

• Git integration: syncs supported item definitions between a Fabric workspace and Git. It gives you source control, not a release gate.
• Deployment pipelines: promote content between Fabric workspaces and apply supported deployment rules, with content comparison and deployment history.
• Code-first automation: uses tools such as fabric-cicd, Fabric REST APIs, and CI runners to deploy definitions in a repeatable way.

Microsoft’s Fabric CI/CD overview describes the platform as complementary capabilities built around Git integration, deployment pipelines, REST APIs, variable libraries, the Fabric CLI, Terraform, and fabric-cicd.

2. Choose the right Fabric CI/CD workflow

Don’t pick a tool because it is popular. Pick the release pattern that fits your team’s source of truth, branching model, configuration needs, and approval process.

One critical decision: where is the source of truth?

Choose one source of truth per workflow and write it down. It might be a Git branch, the development workspace with Git sync, or a defined release commit. Avoid unreviewed production edits that are never committed back, because the next deployment can overwrite them or leave environments inconsistent.

Microsoft’s CI/CD workflow options page compares per-stage Git branches, shared release commits, deployment pipelines, and ISV releases.

3. Prerequisites and permissions

Many CI/CD failures are authorisation or unsupported-item problems, not Python errors. Check these before you connect anything.

• A Fabric workspace on a capacity that supports the item types you plan to manage.
• A cloud Git repository on a supported provider: Azure DevOps or GitHub, with feature-specific limits for each.
• Tenant settings that allow Git integration. Your organisation’s administrator has to enable it, and cross-geo export must be enabled if a workspace and an Azure repo sit in different regions (this doesn’t apply to GitHub).
• Workspace and Git permissions that match the actions you need (see the table below).
• For code-first automation: a service principal or other supported credential, its tenant configuration, and access to the target workspace.
• A Dev workspace connected to source control, and separate Test and Prod workspaces that mirror your release design.
• A list of the item types and dependencies you plan to deploy, checked against the current supported-items documentation.

Who can do what

This summarises Microsoft’s Git integration permissions. Git roles and workspace roles both apply.

Viewers can’t see Git information at all. See Microsoft’s Get started with Git integration guide for current tenant switch names, since labels change.

4. Set up Fabric Git integration

Start with one development workspace and a small solution. A notebook plus its target Lakehouse is a good first test, because it exposes item dependencies and environment references without a full rollout.

1. Create or choose your development workspace. Production should never be where development starts.
2. Create a cloud Git repository. Choose Azure DevOps or GitHub, set up branch protection, and decide how pull requests will be reviewed.
3. Confirm tenant settings and permissions. An administrator must enable Git integration, and the connecting person needs workspace Admin plus repository access.
4. Open the workspace’s Git integration settings. Select the provider, organisation, repository, branch, and folder. Controls vary by provider and UI version.
5. Review the connection carefully. Confirm which branch and folder the workspace will sync with. Don’t point several live workspaces at one branch without a design.
6. Choose the sync direction on first connect. If both sides have content, you must pick a direction. Committing overwrites the Git content. Updating overwrites the workspace content, and Fabric asks you to confirm because a Git branch can be restored and a workspace can’t.
7. Commit the initial item definitions. Review the diff first and check names, files, and types.
8. Test Update from Git in a development workspace before you build any automated release.

What Git integration does not do

• It doesn’t back up Lakehouse or Warehouse data. The repository holds definitions, not data.
• It doesn’t export every item type. Unsupported items in the folder are ignored.
• It doesn’t test business logic, validate data, or approve a production promotion.
• It doesn’t mean every commit should go straight to production.

How commits and updates behave

• You can sync in only one direction at a time. You can’t commit and update together.
• Commit lets you choose which changed items to include. Update always brings the whole branch to the latest commit, and you can’t pick items.
• If an item changed in both the workspace and the branch, updates are blocked until you resolve the conflict.
• On commit, Fabric deletes files inside an item’s folder that aren’t part of the item definition. Don’t keep your own notes or scripts inside item folders.
• The Git connection is per user. With GitHub, each person should connect their own account and not share one personal access token.

Read Microsoft’s Git integration overview and supported items before you commit a production-critical solution.

5. Limits that surprise people

These come from Microsoft’s Git integration limitations. They are easy to hit and annoying to discover late, so check them against your workspace early.

Details and current numbers are on Microsoft’s Git integration process page.

6. Choose a branch strategy that your team can maintain

Branching isn’t only a Git preference. In Fabric it decides how workspaces sync, how environment values travel, and which exact version reaches production.

A simple branch policy

1. Protect the shared branch from direct commits where appropriate.
2. Require pull requests, review, and passing checks before merge.
3. Keep the Dev workspace aligned with its integration branch.
4. Deploy a known commit or tag to Test, validate it, then promote that same tested version to Prod.
5. Record configuration changes and post-deploy actions with the release notes.

For many teams a shared release commit is simpler than a branch per environment: the same known release goes to Test, then to Prod after tests and approval. Microsoft’s workflow guidance recommends that production receives the same content that was tested.

7. Code-first deployment with fabric-cicd

fabric-cicd is an open-source Python library from Microsoft that publishes Fabric item definitions from a repository into a target workspace, with environment parameter replacement. Its documentation states three base expectations that shape everything else:

• Full deployment every time. It deploys what is in scope without looking at commit diffs.
• It deploys into the tenant of the identity that runs it.
• It supports only items that have source control and public create and update APIs.

The documented item types include Notebook, DataPipeline, Lakehouse, Environment, SemanticModel, Report, PaginatedReport, Dataflow, CopyJob, SparkJobDefinition, Eventhouse, Eventstream, KQLDatabase, KQLDashboard, KQLQueryset, GraphQLApi, ApacheAirflowJob, MirroredDatabase, MLExperiment, DataAgent, Ontology, and others. The list changes between releases, and Microsoft notes that some entries are still in preview, so check the item types reference and keep your scope to types you have tested. Microsoft also says that when you sign in with a service principal or managed identity, every item type in a bulk publish must support non-interactive authentication.

Example repository layout

my-fabric-solution/
├── .github/
│   └── workflows/
│       ├── check-fabric-repo.yml
│       ├── deploy-fabric-test.yml
│       └── deploy-fabric-prod.yml
├── workspace/
│   ├── parameter.yml
│   ├── RetailLakehouse.Lakehouse/
│   ├── LoadRetailSales.Notebook/
│   └── RefreshRetailPipeline.DataPipeline/
├── check_repo.py
├── deploy.py
└── requirements.txt

Item folders follow the pattern name.ItemType, and Fabric creates them when you commit through source control. Don’t invent a definition structure for an item type Fabric hasn’t exported. Keep parameter.yml in the root of the workspace directory, which is where the documentation puts it.

Step 1: Install and pin the library

Create requirements.txt. The documentation I reviewed is for version 1.4.0, so check PyPI for the newest release, test it, and pin the exact version you used.

fabric-cicd==1.4.0

Installing fabric-cicd also installs azure-identity, which handles sign-in, so you don’t list it separately. Microsoft’s examples run on Python 3.12. Check the supported Python versions in the documentation before you choose another one.

Step 2: Define environment-specific replacements

Create workspace/parameter.yml. Each rule finds a development value in your item definitions and replaces it with a value for each target environment. The environment name you pass at deploy time must match one of the keys below.

find_replace:
  - find_value: "DEV_LAKEHOUSE_GUID"
    replace_value:
      TEST: "TEST_LAKEHOUSE_GUID"
      PROD: "PROD_LAKEHOUSE_GUID"

  - find_value: "DEV_WORKSPACE_GUID"
    replace_value:
      TEST: "TEST_WORKSPACE_GUID"
      PROD: "PROD_WORKSPACE_GUID"

Step 3: Create deploy.py

This version uses AzureCliCredential, which reuses whichever identity is signed in through the Azure CLI. That fits both local testing (az login) and the GitHub Actions job later (azure/login), with no secret in your code.

import os
from pathlib import Path

from azure.identity import AzureCliCredential
from fabric_cicd import FabricWorkspace, publish_all_items

ROOT = Path(__file__).resolve().parent

target = FabricWorkspace(
    workspace_id=os.environ["FABRIC_WORKSPACE_ID"],
    environment=os.environ["FABRIC_ENVIRONMENT"],
    repository_directory=str(ROOT / "workspace"),
    item_type_in_scope=["Lakehouse", "Notebook", "DataPipeline"],
    token_credential=AzureCliCredential(),
)

publish_all_items(target)
print("Published scoped Fabric items to " + os.environ["FABRIC_ENVIRONMENT"])

This is an example script, and it hasn’t been run against your tenant. It publishes only three item types. It doesn’t delete anything from the target. Test it on a disposable workspace first and widen the scope only after checking each type.

Step 4: Test locally before you automate

python -m venv .venv
# Windows PowerShell:
.venv\Scripts\Activate.ps1
# macOS or Linux instead: source .venv/bin/activate
python -m pip install -r requirements.txt
az login

Sign in with an account that has Contributor or higher on the target workspace, then set the two variables and run the script:

# Bash example
export FABRIC_WORKSPACE_ID="test-workspace-guid"
export FABRIC_ENVIRONMENT="TEST"
python deploy.py

In PowerShell, set them with $env:FABRIC_WORKSPACE_ID = "..." and the same name for the environment. If you see an error about failing to acquire a Microsoft Entra token, run az login again and retry.

Safety switches: deletion and scope

If you prefer the config-file route, set both switches deliberately. This starter config publishes and skips deletion:

core:
  workspace_id: "test-workspace-guid"
  repository_directory: "workspace"
  item_types_in_scope:
    - Lakehouse
    - Notebook
    - DataPipeline

publish:
  skip: false

unpublish:
  skip: true

Full details are in the Configuration Deployment guide. Because deployment is full each time, a large repository takes longer, so keep item_type_in_scope tight and look at the selective deployment options in the documentation when you need them.

8. Check the repo before you deploy

The quietest failure in parameterised deployment is a rule that matches nothing. A development GUID changes, the rule no longer finds it, the deployment succeeds, and Test keeps pointing at Dev. A short check on every pull request catches this before it merges.

Add check_repo.py. It loads parameter.yml and confirms each find_value still appears in at least one file under workspace. If you use regular-expression rules, adapt it for those.

import sys
from pathlib import Path

import yaml

root = Path("workspace")
rules = yaml.safe_load((root / "parameter.yml").read_text(encoding="utf-8")) or {}
problems = []

texts = []
for path in root.rglob("*"):
    if path.is_file():
        try:
            texts.append(path.read_text(encoding="utf-8"))
        except UnicodeDecodeError:
            continue

for rule in rules.get("find_replace", []):
    value = rule.get("find_value")
    if not value:
        problems.append("A find_replace rule has no find_value")
    elif not any(value in text for text in texts):
        problems.append("find_value not found in any file: " + value)

if problems:
    print("\n".join(problems))
    sys.exit(1)

print("Every find_value matches at least one file.")

Then add .github/workflows/check-fabric-repo.yml. It never touches Fabric, so it needs no credentials.

name: Check Fabric repo

on:
  pull_request:
    paths:
      - "workspace/**"
      - "check_repo.py"

permissions:
  contents: read

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install pyyaml
      - run: python check_repo.py

Make this check required for merges into the shared branch. It is cheap, fast, and catches the failure that is hardest to spot later.

9. Automate a Test deployment with GitHub Actions

Once the local script deploys a small solution to Test, a GitHub Actions job can run it the same way every time. The job below signs in with workload identity federation (OIDC), which Microsoft’s fabric-cicd release pipeline examples use. That means no client secret is stored in GitHub.

Step 1: Set up the identity

1. Create an app registration in Microsoft Entra ID for the pipeline.
2. Add a federated identity credential to it that trusts GitHub’s OIDC token issuer for your repository and environment. See Azure login with OIDC for the setup.
3. Allow it to call Fabric. Your Fabric administrator must permit service principals to use Fabric APIs, adding the identity to the allowed group if the setting is restricted.
4. Give it access to the target workspace. Microsoft’s documentation requires Contributor or higher on the workspace you deploy into. Use a separate workspace role per environment.

In the repository, store only identifiers as secrets: AZURE_CLIENT_ID, AZURE_TENANT_ID, and AZURE_SUBSCRIPTION_ID. Store the Test workspace ID as a variable named FABRIC_WORKSPACE_ID on a GitHub Environment called test. If your app has no Azure subscription, the login action has an option for that case, so check its README.

Step 2: Add the workflow

Save this as .github/workflows/deploy-fabric-test.yml. It deploys to Test when changes reach main, or when someone runs it manually. It never deploys to production.

name: Deploy Fabric items to Test

on:
  workflow_dispatch:
  push:
    branches:
      - main
    paths:
      - "workspace/**"
      - "deploy.py"
      - "requirements.txt"
      - ".github/workflows/deploy-fabric-test.yml"

permissions:
  id-token: write
  contents: read

jobs:
  deploy-test:
    runs-on: ubuntu-latest
    environment: test
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - run: pip install -r requirements.txt

      - uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

      - name: Publish scoped items to Test
        env:
          FABRIC_WORKSPACE_ID: ${{ vars.FABRIC_WORKSPACE_ID }}
          FABRIC_ENVIRONMENT: TEST
        run: python deploy.py

Microsoft also documents a client-secret approach for pipelines that can’t use federation, with a ClientSecretCredential and values injected as variables. Prefer OIDC where your setup allows it, and review the authentication examples for the alternatives. Keep action and package versions reviewed and pinned under your security policy.

Step 3: Add a real release gate for production

Create a second GitHub Environment named production with required reviewers, and store its own client ID, workspace ID, and identity. Then add .github/workflows/deploy-fabric-prod.yml. It runs only when someone starts it, deploys the exact tag that passed Test, and waits for approval before the job begins.

name: Deploy Fabric items to Production

on:
  workflow_dispatch:
    inputs:
      release_ref:
        description: "Tag or commit that passed Test"
        required: true

permissions:
  id-token: write
  contents: read

jobs:
  deploy-prod:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ inputs.release_ref }}

      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - run: pip install -r requirements.txt

      - uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

      - name: Publish scoped items to Production
        env:
          FABRIC_WORKSPACE_ID: ${{ vars.FABRIC_WORKSPACE_ID }}
          FABRIC_ENVIRONMENT: PROD
        run: python deploy.py

1. Make Test succeed before any production run can start.
2. Run smoke tests, refresh checks, and data-quality assertions against Test.
3. Deploy the same reviewed tag that passed Test. Don’t rebuild from an unreviewed branch after approval.
4. Record the version, target workspace, validation result, approver, and the rollback plan.

10. Handle environment-specific values correctly

Dev and Test or Prod usually differ in workspace IDs, Lakehouse IDs, connections, endpoints, schemas, secrets, and refresh behaviour. A promoted item must not keep pointing at Development.

Auto-binding isn’t universal. Microsoft notes that dependency references across workspaces and connection references don’t bind to the target automatically. For supported item types, use a Variable Library to hold stage-specific values, and use explicit parameters or post-deployment configuration where a type needs it.

Not every item type supports every mechanism. If a parameter or rule isn’t supported, use a documented post-deploy step or set it through the supported API or UI. A successful publish doesn’t mean every dependency is bound.

11. Build a validation gate before production

The weakest CI/CD pattern is “the command returned success, so release it”. Add checks that show the delivered solution is right.

Minimum Test checklist

• Expected items exist in the target workspace, with the right names and types.
• References and relationships point to Test, not Dev.
• Notebook smoke tests run with the target identity and write only to Test objects.
• Pipelines run successfully and use the intended connections and parameters.
• Lakehouse and Warehouse tables have the expected schemas, key uniqueness, and reasonable row counts.
• Critical business totals reconcile with a known baseline within a stated tolerance.
• Semantic models refresh, and reports resolve their model and data sources, where those items are in scope.
• Permissions work for the automation identity and for representative end users.
• Commit SHA, target workspace, timestamp, and test results are recorded.

Example: simple row-count reconciliation in SQL

Compare counts as one check among several. Replace the table names and account for intentional filters and incremental loads.

-- Example only: run on a SQL endpoint that can see both tables.
SELECT 'source' AS dataset_name, COUNT_BIG(*) AS row_count
FROM dbo.ExpectedSourceSnapshot
UNION ALL
SELECT 'target' AS dataset_name, COUNT_BIG(*) AS row_count
FROM dbo.RetailSales_Test;

Equal counts don’t prove equal data. Add checks for missing business keys, duplicates, null rates, date ranges, and the aggregates that matter to the workload.

Promote the tested version, and plan the rollback

Record the tag that passed Test and promote that exact version to Prod after approval. If the branch moves after Test, either deploy the tested tag or rerun validation for the new commit.

Because fabric-cicd deploys in full each time, a code rollback is simply deploying the previous good tag. That restores item definitions. It does not roll back data. If a failed release changed data, you need a separate data recovery plan, so decide it before the release, not during it.

12. What about deployment plans and variable libraries?

Fabric CI/CD features keep changing, and not every capability works on every release route. Variable libraries can hold stage-specific values for supported items. Deployment plans can describe deployment order, dependencies, and pre and post-deployment actions in supported scenarios.

Each stage of a Variable Library has its own active value set, but only supported consumer item types can read the values. Check the live documentation before you rely on either feature:

• Choose a Fabric CI/CD workflow
• Deployment plans overview
• Variable libraries overview

13. Troubleshooting common Fabric CI/CD failures

The fabric-cicd troubleshooting guide covers logging, common errors, and diagnostic scripts.

14. A first-week plan

You don’t need to build everything at once. This order gets you a working, safe pipeline and shows you the problems early.

1. Day 1: pick one small solution (a notebook, its Lakehouse, and a pipeline), and agree where the source of truth lives.
2. Day 1: connect Dev to Git and commit. Review the diff and confirm the item folders look right.
3. Day 2: prove Update from Git in a scratch workspace, so you know a clean restore works.
4. Day 2: create a Test workspace and list every environment-specific value in the items.
5. Day 3: run deploy.py by hand against a scratch workspace with az login, with deletion off.
6. Day 3: add the parameter rules and the repo check, and prove the check fails when you break a GUID on purpose.
7. Day 4: set up the identity with OIDC and the Fabric API permission, and run the Test workflow.
8. Day 4: write the Test validation: items present, references correct, a smoke test, and a row-count check.
9. Day 5: add the production workflow with a required reviewer, and do a rehearsal run against a non-critical workspace.
10. Day 5: write the runbook: who approves, how to roll back, and who to call.

15. Production readiness checklist

• There is a documented source of truth and a protected release branch or tag.
• Dev, Test, and Prod are separate workspaces or stages with clear purposes.
• The committed item types are supported by your chosen Git and deployment method.
• Environment parameters and connections are handled securely, tested, and covered by a repo check.
• The automation identity has only the permissions it needs, and uses OIDC or a secret store, not stored secrets in code.
• Test checks confirm references, dependencies, data quality, refresh behaviour, and access.
• Production deployment needs an approval, and deploys the tag that passed Test.
• Deletion of orphan items is off, or has been tested and approved on purpose.
• Each deployment records the commit, target, timestamp, validation output, and approver.
• A rollback and recovery plan exists for both item definitions and the data they depend on.
• Roles are reviewed ahead of the February 2027 Git permission change, and the team has read the current limits.

16. Frequently asked questions

Continue learning Microsoft Fabric

• Free Microsoft Fabric tutorial series: build core platform knowledge before you automate deployments.
• Data pipelines in Microsoft Fabric: understand the pipeline items in your release.
• Microsoft Fabric data governance tutorial: plan access, governance, and controlled change.
• Microsoft Fabric Data Warehouse optimization: connect release automation with warehouse validation and tuning.
• DP-600 exam guide: review Fabric analytics engineering concepts and lifecycle practices.

Official Microsoft and project references

Use these for a real tenant. Product support, UI labels, authentication requirements, and preview status can change, so check the live documentation and not a saved screenshot.

• Microsoft Fabric CI/CD documentation hub
• Introduction to CI/CD in Microsoft Fabric
• Choose the best Fabric CI/CD workflow option
• Microsoft tutorial: End-to-end automation in Fabric
• Get started with Git integration
• Git integration process, permissions, and limitations
• Fabric CI/CD concepts and best practices
• Network security for CI/CD
• Official microsoft/fabric-cicd repository
• fabric-cicd documentation: tutorial, parameterisation, optional features, and release pipeline examples.