Home > Docs > Features > Deployment Pipelines

🚀 Deployment Pipelines — Stage-Based Promotion in Fabric¶

Last Updated: 2026-04-21 | Version: 1.0.0

📑 Table of Contents¶

• 🎯 Overview
• 🏗️ Architecture
• ⚙️ Configuration
• 🔄 Deployment Workflow
• 📐 Deployment Rules
• 🎰 Casino Implementation
• 🏛️ Federal Agency Implementation
• 🔗 API and Automation
• ⚠️ Limitations
• 📚 References

🎯 Overview¶

Deployment Pipelines is Fabric's native, built-in ALM (Application Lifecycle Management) tool for promoting workspace items through development stages. It provides a visual comparison between Dev, Test, and Production workspaces, with one-click deployment, deployment rules for environment-specific configuration, and full deployment history.

Deployment Pipelines complement (but differ from) Git-based CI/CD with fabric-cicd. While Git integration manages source-controlled item definitions, Deployment Pipelines manage the runtime promotion of compiled/instantiated Fabric items between workspaces.

Deployment Pipelines vs. fabric-cicd¶

Key Capabilities¶

🏗️ Architecture¶

Stage Architecture¶

flowchart LR
    subgraph DP["🚀 Deployment Pipeline"]
        DEV["🟢 Development<br/>casino-fabric-dev"]
        TEST["🟡 Test<br/>casino-fabric-test"]
        PROD["🔴 Production<br/>casino-fabric-prod"]
    end

    DEV -->|"Deploy ➡️"| TEST -->|"Deploy ➡️"| PROD
    PROD -->|"⬅️ Backward"| TEST -->|"⬅️ Backward"| DEV

    style DEV fill:#27AE60,stroke:#1E8449,color:#fff
    style TEST fill:#F39C12,stroke:#D68910,color:#fff
    style PROD fill:#E74C3C,stroke:#C0392B,color:#fff

What Gets Deployed¶

Deployment Pipelines copy item definitions (metadata, configuration, queries, expressions) between workspaces. They do not copy data.

┌──────────────────────┐       ┌──────────────────────┐
│   DEV Workspace      │       │   PROD Workspace     │
│                      │  ──►  │                      │
│ ✅ Notebook code     │       │ ✅ Notebook code     │
│ ✅ Pipeline JSON     │       │ ✅ Pipeline JSON     │
│ ✅ Semantic model    │       │ ✅ Semantic model    │
│ ✅ Report layout     │       │ ✅ Report layout     │
│ ✅ Lakehouse schema  │       │ ✅ Lakehouse schema  │
│ ❌ Lakehouse DATA    │       │ ❌ (not copied)      │
│ ❌ Warehouse DATA    │       │ ❌ (not copied)      │
└──────────────────────┘       └──────────────────────┘

⚙️ Configuration¶

Creating a Deployment Pipeline¶

1. Open the Fabric portal → Workspaces → Deployment Pipelines (in left nav)
2. Click + New Pipeline
3. Name it (e.g., casino-analytics-pipeline)
4. Add stages (default: Development, Test, Production)
5. Assign a workspace to each stage

Assigning Workspaces to Stages¶

⚠️ Important: Each workspace can be assigned to only ONE deployment pipeline stage. A workspace cannot belong to multiple pipelines.

Stage Permissions¶

🔄 Deployment Workflow¶

Standard Promotion Flow¶

sequenceDiagram
    participant Dev as 🟢 Dev Workspace
    participant DP as 🚀 Pipeline
    participant Test as 🟡 Test Workspace
    participant Prod as 🔴 Prod Workspace

    Dev->>DP: Developer clicks "Deploy to next stage"
    DP->>DP: Compare items (new, modified, unchanged)
    DP->>Test: Copy item definitions
    DP->>DP: Apply deployment rules (rebind connections)
    Note over Test: QA validates functionality
    Test->>DP: QA clicks "Deploy to next stage"
    DP->>Prod: Copy item definitions
    DP->>DP: Apply production deployment rules
    Note over Prod: Production live

Comparison View¶

Before deploying, the pipeline shows a comparison:

┌──────────────────────────────────────────────────────────────┐
│  Development → Test                                          │
├──────────────────────────────────────────────────────────────┤
│  Item                          │ Dev     │ Test    │ Status  │
│  ─────────────────────────────────────────────────────────── │
│  01_bronze_slot_telemetry      │ v3.2    │ v3.1    │ 🔄 Modified │
│  01_silver_slot_cleansed       │ v2.5    │ v2.5    │ ✅ Same     │
│  daily_revenue_report          │ v1.8    │ —       │ 🆕 New      │
│  lh_bronze                     │ exists  │ exists  │ ✅ Same     │
│  slot_analytics_model          │ v4.0    │ v3.9    │ 🔄 Modified │
│  compliance_pipeline           │ v2.1    │ v2.1    │ ✅ Same     │
├──────────────────────────────────────────────────────────────┤
│  [Deploy selected]  [Deploy all]  [Cancel]                   │
└──────────────────────────────────────────────────────────────┘

Selective Deployment¶

You can deploy specific items instead of all changes:

1. In the comparison view, check/uncheck individual items
2. Click Deploy selected
3. Only checked items are promoted

This is useful when: - Multiple features are in-flight in Dev but only one is ready for Test - A hotfix needs to go to Prod without promoting unrelated changes

📐 Deployment Rules¶

Deployment rules configure stage-specific parameter overrides so items work correctly in each environment without manual reconfiguration.

Rule Types¶

Configuring Rules¶

1. In the Deployment Pipeline, click Deployment Rules (⚙️) on the target stage
2. Select an item type (e.g., Semantic Model, Notebook)
3. Add a rule:
4. Source: the parameter/connection in the source stage
5. Target: the value to use in the destination stage

Casino Example: Lakehouse Rebinding¶

Rule: Lakehouse rebind for Test stage
  Item: 01_bronze_slot_telemetry (Notebook)
  Parameter: default_lakehouse
    Dev:  lh_bronze (workspace: casino-fabric-dev)
    Test: lh_bronze (workspace: casino-fabric-test)
    Prod: lh_bronze (workspace: casino-fabric-prod)

Casino Example: Connection String Override¶

Rule: SQL Server connection for Prod stage
  Item: slot_analytics_model (Semantic Model)
  Data Source Rule:
    Dev:  casino-sql-dev.database.windows.net
    Test: casino-sql-test.database.windows.net
    Prod: casino-sql-prod.database.windows.net

🎰 Casino Implementation¶

Casino Deployment Pipeline Structure¶

flowchart TB
    subgraph Pipeline["🚀 casino-analytics-pipeline"]
        subgraph DEV["🟢 casino-fabric-dev"]
            D_NB["Notebooks (17)"]
            D_LH["Lakehouses (3)"]
            D_PL["Pipelines (4)"]
            D_DF["Dataflows (3)"]
            D_SM["Semantic Models (2)"]
            D_RP["Reports (5)"]
        end
        subgraph TEST["🟡 casino-fabric-test"]
            T_NB["Notebooks (17)"]
            T_LH["Lakehouses (3)"]
            T_PL["Pipelines (4)"]
            T_DF["Dataflows (3)"]
            T_SM["Semantic Models (2)"]
            T_RP["Reports (5)"]
        end
        subgraph PROD["🔴 casino-fabric-prod"]
            P_NB["Notebooks (17)"]
            P_LH["Lakehouses (3)"]
            P_PL["Pipelines (4)"]
            P_DF["Dataflows (3)"]
            P_SM["Semantic Models (2)"]
            P_RP["Reports (5)"]
        end
    end

    DEV -->|Deploy| TEST -->|Deploy| PROD

    style DEV fill:#D5F5E3,stroke:#27AE60
    style TEST fill:#FEF9E7,stroke:#F39C12
    style PROD fill:#FADBD8,stroke:#E74C3C

Deployment Rules for Casino POC¶

Promotion Checklist¶

Before promoting from Test → Prod:

• All notebooks run successfully in Test workspace
• Data quality checks pass on Test Lakehouse data
• Compliance rules validated (CTR thresholds, SAR patterns)
• Reports render correctly with Test semantic model
• Pipeline schedules verified (no dev-only triggers active)
• Deployment rules configured for Prod stage
• Stakeholder approval obtained

🏛️ Federal Agency Implementation¶

Multi-Agency Pipeline Strategy¶

For federal deployments, create separate deployment pipelines per agency to maintain independent promotion schedules:

FedRAMP Compliance Considerations¶

🔗 API and Automation¶

REST API for Deployment Pipelines¶

Automate deployments via the Fabric REST API:

List Deployment Pipelines¶

GET https://api.fabric.microsoft.com/v1/deploymentPipelines
Authorization: Bearer {token}

Get Pipeline Stages¶

GET https://api.fabric.microsoft.com/v1/deploymentPipelines/{pipelineId}/stages

Deploy to Stage¶

POST https://api.fabric.microsoft.com/v1/deploymentPipelines/{pipelineId}/deploy
Content-Type: application/json

{
    "sourceStageOrder": 0,
    "targetStageOrder": 1,
    "items": [
        {
            "sourceItemId": "{item-id}",
            "itemType": "Notebook"
        }
    ],
    "options": {
        "allowCreateArtifact": true,
        "allowOverwriteArtifact": true
    }
}

Check Deployment Status¶

GET https://api.fabric.microsoft.com/v1/deploymentPipelines/{pipelineId}/operations/{operationId}

GitHub Actions Integration¶

# .github/workflows/promote-to-prod.yml
name: Promote to Production

on:
  workflow_dispatch:
    inputs:
      confirm:
        description: 'Type "promote" to confirm'
        required: true

jobs:
  deploy:
    runs-on: ubuntu-latest
    if: github.event.inputs.confirm == 'promote'
    steps:
      - name: Authenticate
        run: |
          az login --service-principal \
            -u ${{ secrets.AZURE_CLIENT_ID }} \
            -p ${{ secrets.AZURE_CLIENT_SECRET }} \
            --tenant ${{ secrets.AZURE_TENANT_ID }}

      - name: Deploy Test → Prod
        run: |
          TOKEN=$(az account get-access-token \
            --resource https://api.fabric.microsoft.com \
            --query accessToken -o tsv)

          curl -X POST \
            "https://api.fabric.microsoft.com/v1/deploymentPipelines/${{ vars.PIPELINE_ID }}/deploy" \
            -H "Authorization: Bearer $TOKEN" \
            -H "Content-Type: application/json" \
            -d '{
              "sourceStageOrder": 1,
              "targetStageOrder": 2,
              "options": {
                "allowOverwriteArtifact": true
              }
            }'

⚠️ Limitations¶

Current Limitations¶

When to Use fabric-cicd Instead¶

📚 References¶

🔗 Related Documents¶

• Fabric CI/CD Deployment — Git-based CI/CD with fabric-cicd Python CLI
• Workspace Monitoring — Monitor deployed workspaces
• Identity & RBAC Patterns — Role-based access for deployment stages
• Architecture — System architecture overview

📝 Document Metadata - Author: Documentation Team - Reviewers: Platform Engineering, DevOps, Compliance - Classification: Internal - Next Review: 2026-07-21