Development Lifecycle

A well-structured deployment strategy ensures reliability and consistency across environments. Microsoft Fabric supports a full Dev → Test → Prod lifecycle with built-in tools.

The Two Building Blocks

Fabric provides two complementary tools for lifecycle management. Understanding each one is key to choosing the right deployment pattern.

Deployment Patterns

How you combine Git and Deployment Pipelines defines your CI/CD pattern. Microsoft documents three primary approaches — choose based on your branching strategy, team maturity, and governance needs.

Pattern 1: Git-Based Deployments (Gitflow)

All deployments originate from the Git repository. Each stage has a dedicated primary branch (e.g., dev, test, prod) that feeds its workspace. Promotion happens via Pull Requests between branches.

Pattern 2: Git + Build Environments (Trunk-Based)

All deployments originate from a single main branch. Each stage has its own build pipeline that uses a build environment to transform configuration (connection IDs, lakehouse IDs, parameters) before deploying to each workspace.

Pattern 3: Fabric Deployment Pipelines

Git is connected only to the Dev workspace. Promotion from Dev → Test → Prod happens through Fabric's native deployment pipelines, which can be orchestrated via APIs from Azure DevOps or GitHub Actions.

ISV / Multi-Tenant Pattern

For ISVs building SaaS on Fabric, a variant of Pattern 2 exists where Dev and Test are centralized, but Prod fans out to per-customer workspaces (potentially thousands). Each customer release runs in parallel with unique parameters. See the full ISV pattern ↗

Which Pattern Should You Choose?

There's no one-size-fits-all — many organizations use hybrid approaches. Use these scenarios to guide your decision:

Implementation: fabric-cicd Python SDK

The fabric-cicd library is Microsoft's open-source Python SDK for automating Fabric workspace deployments. It provides deterministic, code-first deployments that integrate seamlessly with GitHub Actions and Azure DevOps pipelines. Best suited for Pattern 2 but works with any Git-based approach.

Installation

pip install fabric-cicd

Key Capabilities

• Deterministic deployments: Full, predictable workspace deployments every time — no manual workspace operations needed
• Source-control integration: Deploy directly from Git repository directories (GitHub, Azure DevOps) into target workspaces
• Environment parameterization: Use parameter.yml files to manage environment-specific values (connection strings, workspace IDs, lakehouse names)
• Flexible authentication: Supports all Azure TokenCredential methods — user identity, service principal, and managed identity
• Supported item types: Notebooks, Data Pipelines, Semantic Models, Reports, Lakehouses, Environments, and more

Deployment Example

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

# Authenticate with service principal
credential = ClientSecretCredential(
    tenant_id="your-tenant-id",
    client_id="your-client-id",
    client_secret="your-client-secret"
)

# Define the target workspace
workspace = FabricWorkspace(
    workspace_id="your-workspace-id",
    environment="PROD",                    # Maps to parameter.yml values
    repository_directory="./fabric-items", # Local repo directory with item definitions
    item_type_in_scope=["Notebook", "DataPipeline", "SemanticModel", "Report"],
    credential=credential
)

# Deploy all items
publish_all_items(workspace)

GitHub Actions Integration

name: Deploy to Fabric
on:
  push:
    branches: [main]

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

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'

      - name: Install fabric-cicd
        run: pip install fabric-cicd

      - name: Deploy to Production
        env:
          AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
          AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }}
          AZURE_CLIENT_SECRET: ${{ secrets.AZURE_CLIENT_SECRET }}
        run: python scripts/deploy.py --env PROD

Environment Parameterization

find_replace:
  - find: "your-dev-lakehouse-id"
    replace_with:
      DEV: "dev-lakehouse-id"
      TEST: "test-lakehouse-id"
      PROD: "prod-lakehouse-id"
  - find: "your-dev-connection"
    replace_with:
      DEV: "dev-connection-string"
      TEST: "test-connection-string"
      PROD: "prod-connection-string"

CI/CD Best Practices

• Use separate workspaces per environment (ws-dev, ws-test, ws-prod)
• Use separate capacities for production vs. non-production workloads
• Use service principals (not user accounts) for CI/CD automation — create a dedicated app registration in Entra ID, grant workspace Contributor access, store credentials as CI/CD secrets
• Apply deployment rules to swap connection strings per environment
• Restrict production workspace access to service principals or limited admins
• Use parameter.yml to parameterize environment-specific values so the same codebase deploys to Dev, Test, and Prod
• Make small, frequent commits — easier to merge and less likely to conflict
• Connect different stages to different databases — never overload production with dev/test queries

Migration Decision Framework

Migration is not one-size-fits-all. Use a phased approach to reduce risk and ensure continuity:

🔄 Interactive Migration Path Recommender

Select your current platform to see a step-by-step tailored migration path to Fabric.

Migration Paths

From Azure Synapse Analytics

• Dedicated SQL Pools → Fabric Warehouse: Migrate T-SQL scripts and stored procedures. Most T-SQL is compatible; review unsupported features (e.g., some system views)
• Serverless SQL Pools → Fabric Lakehouse: Replace OPENROWSET queries with Lakehouse SQL endpoints
• Synapse Spark → Fabric Notebooks: PySpark/Scala code largely compatible; update library references and session configs
• Use Shortcuts to connect Fabric to existing ADLS Gen2 storage during transition

From Azure Data Factory (ADF)

• Fabric Data Factory supports most ADF pipeline activities natively
• Use copy activity equivalents and Dataflows Gen2 for transformation
• Some connectors may differ — validate your source/sink connectors
• Consider running ADF and Fabric in parallel during migration

From Power BI Premium

• Power BI workspaces can be reassigned to Fabric capacity (F64 or higher)
• Existing datasets, reports, and dashboards continue to work unchanged
• Migrate import-mode datasets to Direct Lake for better performance and cost savings
• Legacy P SKUs map to equivalent F SKUs (P1 ≈ F64, P2 ≈ F128, P3 ≈ F256, P4 ≈ F512, P5 ≈ F1024)

From On-Premises (SQL Server / SSIS)

• Use Data Factory pipelines with on-premises data gateway for initial data movement
• Migrate SSIS packages to Dataflows Gen2 or Fabric notebooks
• Use Fabric mirroring to replicate SQL Server databases to OneLake in near real-time
• Plan for a hybrid phase where on-prem and Fabric run in parallel

🛠️ Official Migration Tools & Resources

Select your source platform to see the official Microsoft tools, step-by-step guidance, and current migration support status.