Microsoft Fabric Deployment Options: Choose What Your Team Can Own

As the saying goes, there are many ways to skin a cat. Being a cat owner myself, I quite frankly find the saying absurd, and anyone who got close to my cats with ill intentions would be the one in trouble.

But I digress.

There are several ways to deploy items in Microsoft Fabric, ranging from editing them directly in a workspace to automating entire environments.

Each approach adds capabilities. Each also asks something of the people using and maintaining it. Before choosing, I ask two questions: Where does the source of truth live, in the workspace or in Git? And how do changes move, through a visual interface or through code?

These approaches overlap. Deployment plans extend supported deployment operations rather than replace them. The skill levels below are my assessment of the deployment work, separate from the skills needed to build the Fabric solution.

The technically most capable option is not automatically the best one. The best option meets the requirements and can still be understood, repaired, and extended after the consultant has left.

Direct Workspace Editing: Start Simple

#

The simplest approach is to create and edit items directly in the workspace where they will be used. No promotion between environments. No deployment machinery.

For exploration, learning, and disposable prototypes, this is perfectly reasonable. You can start working immediately. The problem appears when people depend on what you have built. If you edit the live solution, your mistakes can become their problems before you have finished testing.

• Pros: Immediate, minimal setup, nothing to maintain beyond the solution itself.
• Cons: No separate release step or safe place to test changes; recovery depends on safeguards you arrange yourself.
• Developer skill: Low deployment knowledge.
• Maintainer skill: Low initially, but troubleshooting live changes can require considerable expertise.

I would happily use this for a sandbox. For a business-critical solution, I want somewhere safe to make mistakes.

Deployment Pipelines: Move Changes Through Environments

#

Fabric deployment pipelines move supported items between workspace stages, typically development, test, and production. You can compare stages and control promotion through a visual interface. Microsoft also provides APIs for automation. Microsoft’s deployment pipeline overview.

That gives a team a release process it can see and explain: build, test, then promote. Deployment rules can set stage-specific values, such as data sources or parameters, for supported items.

There is still learning involved. Maintainers need to understand how items are paired between stages, what a deployment overwrites, and which item types it supports. Deployment pipelines provide deployment history, but not version control or a way to retrieve arbitrary historical versions of item definitions.

• Pros: Visual, built into Fabric, and a manageable way to separate development from production.
• Cons: Item-specific limitations and environment settings still need attention; testing remains your responsibility.
• Developer skill: Low to moderate.
• Maintainer skill: Moderate: permissions, pairing, dependencies, and environment settings.

For most of my clients, this is where I would start. The process is understandable, and the team has a reasonable chance of owning it after I leave.

Git Integration: Deploy From the Repository

#

Fabric can update supported workspace items directly from Git. Microsoft describes a workflow in which development, test, and production workspaces connect to separate branches. Changes move through pull requests before each workspace is updated. Microsoft’s workflow comparison.

• Pros: Version history and review through pull requests.
• Cons: Branches, conflicts, synchronization, and environment configuration need managing.
• Developer skill: Moderate: Git and pull requests.
• Maintainer skill: Moderate to high, especially when updates are automated.

Git does not have to carry the entire release. It can hold development history while another tool handles promotion. Git integration synchronizes supported item definitions, but environment-specific configuration and dependencies may still require additional steps.

Hybrid: Git for Development, Pipelines for Promotion

#

In practice, many teams combine the two. Developers work in a Git-connected development workspace and get review and version history. Promotion to test and production runs through a deployment pipeline. The team gets a release process it can see.

• Pros: Version control alongside familiar visual promotion.
• Cons: Two mechanisms to understand; the team must know which state is authoritative when they disagree.
• Developer skill: Moderate.
• Maintainer skill: Moderate.

This is my usual starting point when a client already uses Git.

Deployment Plans: Add Order and Actions

#

A deployment plan adds explicit item order and supported actions before or after deployment. It works with deployment pipelines, supported Git operations, and supported APIs; it does not run by itself. It is currently in preview. Microsoft’s deployment plan overview.

This is useful when moving items alone is insufficient. Perhaps a notebook must run as part of the release, or dependencies need an order that Fabric cannot infer. A plan attaches to an individual operation and does not roll back completed work if a later step fails. It also does not work with fabric-cicd.

• Pros: Explicit sequencing and repeatable actions within Fabric.
• Cons: Preview limitations and another failure path for the team to understand.
• Developer skill: Moderate, rising with the complexity of the actions.
• Maintainer skill: Moderate to high: dependencies, action behaviour, and recovery after partial failure.

I would add a plan only for a concrete requirement. Every action should have a purpose and an owner who can explain what happens when it fails.

Code-Driven Deployment: fabric-cicd and Fabric CLI

#

The Microsoft-hosted fabric-cicd Python library deploys supported Fabric items from files without requiring developers to write every API call themselves. Fabric CLI’s fab deploy offers a configuration-driven command that uses fabric-cicd underneath.

These tools provide a foundation for repeatable releases, checks, and approvals. Someone still has to own authentication, configuration, the execution environment, and failures.

• Pros: Repeatable deployment through code, flexibility, and less direct API work.
• Cons: Code, dependencies, and supported-item boundaries need ongoing care.
• Developer skill: Moderate to high for people building the workflow.
• Maintainer skill: High: Git, scripting, authentication, and troubleshooting.

Developers following an established workflow may need less knowledge. Somebody still needs to change that workflow safely.

These tools generally work towards a desired state rather than simply deploying the latest changes. Teams must understand which items are in scope and whether deployments can remove items from the target workspace.

Notice the pattern? Each step gives us more control, and each step creates more things someone must understand when deployment fails.

FabricOps and Custom Automation: Broader Control

#

Peer Grönnerup’s FabricOps goes beyond item deployment. It provisions workspaces, manages feature-branch workspaces, and releases across environments using fabric-cicd. It is a reference and boilerplate that a team must adapt and test.

Terraform can provision infrastructure such as workspaces and connections. Custom REST API scripts can drive item or pipeline deployments. For a team with CI/CD skills, my current preference would likely be GitHub Actions orchestrating deployments through Fabric REST APIs. GitHub Actions handles the workflow, approvals, and execution, while the APIs perform the actual deployment operations. The same orchestration could equally use fabric-cicd or Fabric CLI. That flexibility is also a maintenance commitment. Microsoft’s CI/CD planning guidance.

• Pros: Can automate a broader platform and a more tailored release process.
• Cons: More components, permissions, and conventions to maintain.
• Developer skill: Moderate to high.
• Maintainer skill: High: Fabric, Git, infrastructure, authentication, and automation.

I would consider this where a team has both the need and the capacity to own it.

Who Will Run the Next Release?

#

Most of my clients are not CI/CD experts. They understand their data and their business, and their time is already spoken for. A consultant may enjoy building a sophisticated deployment setup. The client bears the cost of operating and extending it.

Before choosing a tool, ask who will run releases six months from now. How often will they release? Can they explain a failed run and make a small change to the process without calling its original author?

I would start with deployment pipelines, adding Git for version history where appropriate. I would be hesitant to go further unless the team has a need that justifies it and someone who can maintain it.

That settles how changes move. It does not settle what arrives at the other end. In the next post, I will look at the Fabric items themselves and the work that can remain after a deployment reports success.

Join the Conversation

#

How does your organization deal with Fabric deployments? I’d be interested in your thoughts on what constitutes the perfect deployment strategy - for you. Find me on LinkedIn or BlueSky.

Photo by Ben Allan on Unsplash