rbac-devops

DevOps considerations for Microsoft Fabric Landing Zones

In the context of Microsoft Fabric, DevOps practices enable repeatable, scalable deployment, automation, and monitoring of the Fabric environment and its workloads. While some aspects differ from classical Azure Landing Zones, the core DevOps principles apply with specific tools and APIs suited for Fabric.

What DevOps Means for Fabric

DevOps in Fabric Landing Zones focuses on:

• Automating provisioning and deployment of Fabric workspaces, capacities, items (e.g., Lakehouses, Warehouses, Data Pipelines, Semantic Models).
• Managing Fabric resources via REST APIs, Fabric CLI, and Infrastructure-as-Code principles.
• Implementing CI/CD pipelines for continuous testing, deployment, and promotion across Dev/Test/Prod environments.
• Aligning team collaboration and platform automation with lifecycle management of Fabric artifacts.

Supported Automation Approaches in Fabric

Fabric REST API

Microsoft Fabric exposes a REST API that allows management of key objects:

• Workspaces
• Semantic Models
• Data Pipelines
• Lakehouses and Warehouses
• Notebooks and Reports

You can script deployments, assign permissions, trigger refreshes, and track statuses.

Example: Triggering a semantic model refresh

POST https://api.fabric.microsoft.com/v1/workspaces/{workspaceId}/semanticmodels/{modelId}/refreshes
Authorization: Bearer <token>

Fabric CLI

The Fabric CLI (fabric) is a command-line tool for managing resources locally and in CI/CD pipelines.

Example usage:

fabric login
fabric workspace list
fabric pipeline run --id <pipelineId>

You can integrate it into GitHub Actions or Azure Pipelines for fully automated deployments.

XMLA Endpoint

For semantic models, advanced deployments can also use the XMLA endpoint to:

• Deploy changes from Visual Studio or Tabular Editor
• Automate schema updates
• Manage incremental refresh policies

This approach is useful in enterprise BI DevOps workflows and complements REST and CLI automation.

---

DevOps Best Practices for Fabric Landing Zones

1. Infrastructure as Code (IaC)

Although Fabric does not yet support ARM/Bicep or Terraform natively, you can treat workspace provisioning and object deployment as code by:

• Maintaining Fabric item definitions (e.g., DAX, Power Query M, JSON metadata) in source control
• Using fabric CLI scripts and YAML-based GitHub workflows for automated promotion

Example YAML GitHub Actions snippet:

jobs:
  deploy_fabric:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Setup Fabric CLI
        run: |
          npm install -g @microsoft/fabric-cli
      - name: Deploy Semantic Model
        run: fabric semanticmodel deploy --file ./model.dax

2. Visual Studio Code Integration

Use VS Code together with extensions for:

• Source control (Git)
• GitHub Copilot or ChatGPT for code generation
• Notebook development (.ipynb)
• DAX, KQL, SQL editing with syntax highlighting
• Debugging and executing Fabric code with CLI terminals

This combination provides a modern, DevOps-ready IDE experience for Fabric.

---

Team Considerations

Fabric Landing Zone DevOps requires:

• A Platform Team responsible for base workspaces, RBAC, capacities, and CI/CD pipeline templates.
• Application/Data Teams responsible for individual projects, source control, testing, and deployments via pipelines.
• Enabling Teams providing best practices, coaching, and managing shared automation modules.

---

DevOps Team Topologies and Design Considerations

The successful implementation of DevOps in Microsoft Fabric Landing Zones depends heavily on clearly defined team responsibilities and a well-aligned team topology. The goal is to strike the right balance between centralized control (Platform Team) and autonomous agility (Application/Data Teams), following modern DevOps and cloud-native principles.

Understanding Conway's Law in the Context of Fabric

According to Conway's Law, the systems an organization builds mirror the communication structure of the teams. In Fabric, this means the way your teams are structured will influence your workspace organization, deployment flows, and collaboration patterns.

To counteract undesirable outcomes from rigid communication paths, apply the Reverse Conway Maneuver: design your teams based on the desired architecture and deployment strategy in Fabric—not the other way around.

Recommended Team Types

Team Type	Description
Platform Team	Owns the base infrastructure of the Fabric Landing Zone, including workspaces, capacity management, RBAC definitions, reusable deployment scripts, policies, and platform observability.
Application/Data Teams	Responsible for building, testing, and deploying specific Fabric workloads (e.g., Lakehouses, Pipelines, Reports). These teams use CI/CD to manage their own code, often drawing on templates and guidance from the Platform Team.
Enabling Teams	Provide training, coaching, shared modules, and DevOps platform enablement. Their role is to raise DevOps maturity across teams and reduce skill gaps.

Platform Team Responsibilities

• Design and enforce RBAC strategy across Fabric workspaces
• Manage shared CI/CD pipelines and GitHub Actions templates
• Own Fabric CLI configurations and deployment automation
• Monitor deployments and enforce policy compliance
• Develop reusable modules for workspace provisioning and semantic model promotion
• Implement IaC (where possible) using REST, CLI, and scripting conventions

Application Team Responsibilities

• Develop and maintain semantic models, notebooks, pipelines, etc.
• Apply deployment policies defined by the platform team
• Automate testing and deployment through pull-request-driven workflows
• Maintain observability dashboards for application-specific metrics
• Collaborate via Git and VS Code on shared source control systems

Enabling Team Responsibilities

• Build and maintain CI/CD accelerators and bootstrapping scripts
• Train Platform and Application teams on automation best practices
• Contribute reusable YAML pipeline templates, CLI wrappers, and secrets management
• Help enforce peer-review culture and test-driven development in Fabric projects

Interaction Modes

Teams should interact according to their goals and dependencies:

• Collaboration: Platform and Application teams co-design deployment patterns
• X-as-a-Service: Platform team exposes CI/CD modules or RBAC templates as reusable services
• Facilitating: Enabling team guides Application teams through DevOps onboarding or migration

---

A mature Fabric DevOps implementation embraces autonomy, automation, and cross-team collaboration while ensuring policy-driven governance and centralized observability.

---

Practical Implementation Details per Team

Platform Team – Technical Implementation Tasks

• RBAC Automation: Maintain centralized YAML or JSON definitions for workspace roles and permissions. Use fabric workspace permission set to enforce them.

  fabric workspace permission set --workspace-id <id> --input permissions.json

• Workspace Provisioning: Automate creation of new workspaces using CLI and REST.

  fabric workspace create --name "sales-dwh-dev" --capacity-id <capacity-guid>

• Pipeline Templates: Provide reusable GitHub Actions or Azure DevOps pipeline templates with environment parameterization.
• Policy Enforcement: Track failed refresh jobs or unauthorized changes by integrating Fabric Activity Logs with Azure Monitor or Log Analytics.
• Shared CLI Tools: Develop internal wrappers around the fabric CLI for common patterns like promotion, validation, or rollback.

Application/Data Teams – Technical Implementation Tasks

• Item Development: Build models, notebooks, pipelines locally in VS Code with workspace sync scripts.
• CI/CD Pipelines: Create per-project YAML pipelines (or GitHub Actions workflows) that:
  • Lint source files (e.g., daxlint)
  • Deploy via Fabric CLI
  • Trigger tests and refreshes
  • Handle rollback if validation fails

Example GitHub Actions deployment step:

- name: Promote model to test
  run: fabric semanticmodel deploy --file model.dax --workspace-id ${{ secrets.TEST_WORKSPACE }}

• Observability: Use API endpoints to check job status, refresh history, or model deployments.

fabric semanticmodel refresh list --workspace-id <id> --model-id <id>

• GitOps Patterns: Use pull-request based workflows to ensure reviewed changes trigger promotion.

Enabling Team – Technical Responsibilities

• CI/CD Accelerators: Publish pre-built GitHub Action composite actions:
  • deploy-lakehouse.yml
  • validate-notebook.yml
• Dev Environment Bootstrap: Provide VS Code devcontainer templates with pre-installed fabric CLI and Python SDKs.
• Cross-cutting Libraries: Offer shared modules for interacting with Fabric REST APIs securely (using service principals or workload identities).
• Security Automation: Ensure secrets like API tokens are stored in GitHub/Azure Key Vault and exposed securely via environment variables in pipelines.

---

Monitoring and Feedback

Use Microsoft Purview, Defender for Cloud, and Fabric Activity Logs via REST to:

• Monitor deployments and refresh jobs
• Track failures and execution history
• Feed incidents into centralized alerting (e.g., Azure Monitor)

---

Summary

DevOps in Fabric Landing Zones is enabled through:

• REST APIs and CLI for automation
• Git-based CI/CD workflows for item promotion
• VS Code as the central DevOps workbench
• DevOps team topologies aligned with Fabric platform and application ownership

For a practical start, see:

• Fabric REST API Overview
• Fabric CLI Guide

Appendix: Example Repository Layout for Fabric DevOps

📁 fabric-landing-zone/
├── .github/
│   └── workflows/
│       ├── deploy-model.yml
│       └── refresh-pipeline.yml
├── lakehouse/
│   └── definition.json
├── semanticmodel/
│   ├── model.dax
│   └── metadata.json
├── notebooks/
│   └── cleanup.ipynb
├── pipelines/
│   └── daily_etl.json
└── workspace/
    └── permissions.json

This layout reflects a modular, GitOps-ready Fabric project repository. Each artifact type is stored declaratively and deployed automatically via CI/CD pipelines.