Category: Deployment

Paul Turley makes a recommendation:

Pilot versus enterprise-wide is the wrong debate. The real question is which one your organization is actually ready for.

Start narrow, then earn scale.

Microsoft’s capacity planning guidance recommends beginning with a proof-of-concept phase on a free 60-day trial capacity, a single use case, a small user group, and an isolated workspace so nothing touches production. You’re testing the concept, not committing the whole company. That isolation matters as much as the scope — keeping the proof-of-concept out of production workspaces means a bad assumption costs you a workspace, not a week of executive reporting.

Read on for a few more tips along these lines.

Kevin Chant digs into a new announcement:

To clarify, deployment plans are a new type of Microsoft Fabric item that lets you control deployment order and automate actions as part of the deployment. For example, you can define a plan that first creates a Lakehouse and then runs a notebook afterwards to insert it with data.

Deployment plans are not another deployment option. Instead, they enrich the deployment options that are already available. At this moment in time they work with Git integration, Deployment Pipelines and supported REST APIs.

Read on to learn more about these.

Meagan Longoria has a list:

Fabric deployment pipelines look like they solve CI/CD for Fabric content, especially for people who prefer a GUI over writing code to handle deployments, but the implementation has enough structural gaps that they fall apart for several real deployment workflows. Even when they do work, the UI isn’t always intuitive.

Every piece of active software carries a backlog of feature requests and known limitations, and deployment pipelines get new capabilities on a regular basis. Everything below reflects how deployment pipelines behave as of August 2026. Some of it may have changed by the time you’re reading this, so check Microsoft’s docs for the current state before you plan around any of these.

Click through for the list, as well as a few alternatives that come with their own trade-offs.

Matt Collins shares some advice:

Selective deployments with the fabric-cicd python library are highly useful for shipping just the items that actually changed in your CI/CD process. Unfortunately, by default, it also tells you that a deployment succeeded when nothing was deployed at all.

This blog showcases an example where we selectively deployed Fabric items to upper environments, not realising that the dev ops pipeline reported as “successful” but did not contain our intended changes. We will then dig into some quality checks that highlighted a bigger error in the way Microsoft Fabric handles item naming in a repository.

You’ll learn how to help safeguard from human error in selective Fabric deployments, as well as create useful build validations in Azure DevOps that help to keep your repository resource names clean and fit-for-purpose. All this is achieved through two simple CI/CD pipelines.

Read on to learn more.