How to set up CI/CD for Microsoft Fabric

And what actually sits in each layer:

• Azure foundation: resource groups, storage, Key Vault, managed identities, Log Analytics and the Fabric capacity itself.
• Fabric control plane: workspaces, capacity assignment, domains, connections, roles and the Git wiring of each workspace.
• Fabric items: lakehouses, warehouses, notebooks, data pipelines, dataflows, semantic models, reports, eventhouses, Spark environments and variable libraries.
• Release orchestration: validation, approvals, the order of the steps and the checks afterwards.

That line is not a matter of taste. Creating a workspace touches identity, capacity and networking, and you want to see that in a plan before it happens. Changing a notebook touches nothing outside that workspace, and you specifically do not want to push it through a platform team's approval round.

The first two put Git in the lead role and differ mainly in who performs the deployment: Fabric itself, or your pipeline. The third inverts it. There the Development workspace is the source and you promote content to the next stage, with item pairing, deployment rules and a deployment history. That works well as long as you keep the first stage connected to Git; without Git you have promotion without a way back.

There is one constraint that can make this decision for you, and it does not appear in any list of benefits. Deployment pipelines do not work together with inbound and outbound access protection on a workspace. It is mutual, too: if a workspace sits in a deployment pipeline you can no longer enable outbound access protection, and if that protection is already on you cannot add the workspace to a pipeline.

Connect the first workspace to Git and put the items in a dedicated folder, for example /fabric. Fabric writes each item as a folder named {display name}.{item type} with a .platform file holding the metadata and the logical identity. If your pipeline YAML and scripts live in that same folder, the sync gets confused.

Keep feature branches short and delete them after the merge. Fabric items are generated files; the longer two people work next to each other, the better the odds of a merge you have to settle by hand.

Bicep is the obvious choice if the rest of your organisation already works Azure-native. Terraform wins as soon as you want Azure and Fabric in one plan, because then the capacity and the workspace hanging off it share a state.

resource cap 'Microsoft.Fabric/capacities@2023-11-01' = {
  name: 'fabprod001'
  location: location
  sku: {
    name: 'F32'
    tier: 'Fabric'
  }
  properties: {
    administration: {
      members: [capacityAdminObjectId]
    }
  }
}

The workspace and its Git wiring in Terraform:

resource "fabric_workspace" "dev" {
  display_name = "ws-sales-dev"
  capacity_id  = data.fabric_capacity.cap.id
}

resource "fabric_workspace_git" "dev" {
  workspace_id            = fabric_workspace.dev.id
  initialization_strategy = "PreferRemote"

  git_provider_details = {
    git_provider_type = "AzureDevOps"
    organization_name = var.ado_org
    project_name      = var.ado_project
    repository_name   = var.ado_repo
    branch_name       = "main"
    directory_name    = "/fabric"
  }

  git_credentials = {
    source        = "ConfiguredConnection"
    connection_id = fabric_connection.ado.id
  }
}

Put the Terraform state in protected cloud storage. State holds resource IDs, configuration and sometimes secrets, and a state file on a laptop or in the repo is exactly the kind of risk this whole setup is meant to remove.

What sinks almost every first automated deployment is not the authentication but the authorisation around it. A service principal has to be allowed in four places, and all four live somewhere else:

1. The tenant setting Service principals can create workspaces, connections, and deployment pipelines, for creating those three things.
2. The tenant setting Service principals can call Fabric public APIs, for all other API traffic.
3. An explicit role on the workspace itself. Membership of the tenant setting grants no access to content.
4. Access in your Git provider. In Azure DevOps the principal has to be known in the organisation or project before the Git wiring works.

Those first two settings do not cover for each other. Enable only the first and your pipeline will happily create a workspace and then fail on the first item call, with an error that does not say which of the two is missing.

A workflow that puts the two layers in the right order:

name: fabric-cicd

on:
  push:
    branches: [main]
    paths:
      - "fabric/**"
      - "infra/**"

permissions:
  id-token: write
  contents: read

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

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

      - name: Update the control plane
        run: |
          terraform -chdir=infra init
          terraform -chdir=infra apply -auto-approve

      - name: Deploy the items
        run: |
          pip install fabric-cicd azure-identity
          python scripts/deploy.py --environment test

For environment-specific values use a variable library rather than parameter files. It is supported by Git, deployment pipelines and the APIs, and it can carry its own value set per stage, so you no longer need a find-and-replace step between test and production.

The order from commit to production:

1. Developer creates a short branch and works in a dedicated workspace.
2. The change is committed to Git as an item definition.
3. The pull request validates IaC, YAML, item definitions and secrets.
4. After review the merge lands on the integration branch.
5. The pipeline updates the control plane first.
6. A check confirms workspace, capacity, roles and Git status.
7. Only then do the items go out, through the mechanism from step 2.
8. A script activates the value set and repairs broken references.
9. Integration tests run on realistic data volume and capacity.
10. An approval guards the transition to production.
11. Production runs under its own principal with minimal rights.
12. Monitoring confirms the release does what it should.

For monitoring afterwards the retention periods are worth knowing, because they decide how long you can still investigate an incident: