Press "Enter" to skip to content

Category: Deployment

The Pain of Microsoft Fabric Deployment Pipelines

Published 2026-08-24 by Kevin Feasel

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.

Leave a Comment

Validating Selective Deployments in Microsoft Fabric

Published 2026-08-24 by Kevin Feasel

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.

Leave a Comment

Blocking Database Project Deployment on Data Loss

Published 2026-08-17 by Kevin Feasel

Jerry Nixon flips a switch:

This important feature shows up in a few places. This article discusses its role in Database Projects and in SQL Server Management Studio (SSMS); it defaults to true in both. This simple setting evaluates the delta between your desired schema and your actual schema and calculates if applying your desired schema would result in data loss. If the answer is “yes,” it stops.

An easy example is dropping a table or column. Doing so would clearly lose data. Another, perhaps less obvious, is reducing the range of a column’s data type, like from INT to TINYINT, where any existing value under zero or over 255 could be lost. These evaluations are done by the engine when BlockOnPossibleDataLoss is set to True and, as a result, you can trust that data in your database is not accidentally destroyed by publishing a schema.

The tricky part becomes dealing with database changes when there will be data loss. For that scenario, I’m not sure the database project approach offers anything significant over writing your own database change scripts.

Leave a Comment

Deploying Fabric Resources via ADO

Published 2026-08-11 by Kevin Feasel

Jon Lunn continues a series on source control and branching with Microsoft Fabric:

There are a few things you need to check first:

  1. Does the account your going to use to authenticate to (In this case a Service Principal) been added to the workspace with contributor level access?
  2. Has the DevOps Library been updated with the values for the Service Principal and workspace id you are deploying to?
  3. Has any DevOps Environment that is production been gated to to allow deployments only after approval?
  4. Got the list of items to deploy?

You have done all those, then alright! Lets push that button! Flick that switch! Saddle that horse!

Be right back; acquiring horse.

Comments closed

Replacing Item IDs and Connection Strings with Variable Libraries

Published 2026-07-16 by Kevin Feasel

Gilbert Quevauvilliers makes use of variable libraries in Microsoft Fabric:

In this blog post I’m going to show you how you can use variable libraries with connection strings as well as items.

This approach allows you to manage environment-specific configuration when deploying Fabric items across development, test, and production workspaces

If you’re looking to move your fabric capacities across workspaces or regions, you can do this quickly and easily without having to re-Plumb a lot of the work.

Click through for a working example.

Comments closed

Thoughts on Deploying Fabric Data Agents

Published 2026-06-24 by Kevin Feasel

Marc Lelijveld performs a deployment:

Over the past year, I’ve frequently blogged about Fabric Data Agents. Alongside myself, many other community members have been sharing their experiences and best practices to get the most out of Data Agents. However, there is one topic I rarely see discussed: deployment of Data Agents.

As Data Agents become part of production-grade solutions, deployment and lifecycle management become increasingly important. Building a Data Agent is one thing, but moving it consistently between Development, Test, and Production environments is a completely different challenge.

In this blog, I will share my current best practices around deploying Fabric Data Agents, including what works today, where the limitations are, and the gaps that still exist.

Read on to see what Marc recommends at this time, with the proviso that some of this will likely change as the product develops further.

Comments closed

Moving Fabric Notebooks between Workspaces

Published 2026-06-17 by Kevin Feasel

Gilbert Quevauvilliers takes advantage of source control:

With the new Lakehouse Auto-Binding capability in Notebook Git integration, Fabric can now intelligently preserve and resolve the binding between your notebooks and their attached Lakehouses as you move them across workspaces. This makes true multi-environment development and CI/CD workflows in Fabric significantly smoother and more reliable.

I am going to show you how to do this in the blog post below.

That is pretty nice, and Gilbert has a demo of the process, showing that it’s not particularly onerous

Comments closed

Database Deployment Variables with SQLCMD

Published 2026-05-07 by Kevin Feasel

Andy Brownsword changes a variable:

A regular Database Project deployment is static and delivers consistent results regardless of environment. When it comes to schema, that’s usually desired, but data is a different story.

Data is environment specific. You want a Database Project that works across all environments. You want smarter deployments. You need SQLCMD Variables.

These have been the go-to method for handling different environments and other things that change between releases since I started using database projects about 15 years ago. Looks like not a lot has changed on this front, but it’s good to see that they still work as expected.

Comments closed

Training, Serving, and Deploying Scikit-Learn Models via FastAPI

Published 2026-04-24 by Kevin Feasel

Abid Ali Awan serves a model:

In this article, you will learn how to train a Scikit-learn classification model, serve it with FastAPI, and deploy it to FastAPI Cloud.

Topics we will cover include:

  • How to structure a simple project and train a Scikit-learn model for inference.
  • How to build and test a FastAPI inference API locally.
  • How to deploy the API to FastAPI Cloud and prepare it for more production-ready usage.

Click through for the process.

Comments closed

The Power of Database Projects

Published 2026-04-22 by Kevin Feasel

Andy Brownsword is sold:

If you’ve been using Database Projects for simply maintaining copies of your database objects – like I used to – then you’ve been missing out on the power of its deployments. Initially I was sceptical about how it could effectively perform upgrades but after seeing them land in SSMS last month I wanted to revisit them as a means of actual deployment.

My scepticism was completely misplaced, so if you haven’t touched Database Projects before – or had similar concerns as me – I want to demonstrate 3 features which make them not just good, but amazing for deployments.

Click through for those features. I will say that for straightforward databases, the database project deployment process is pretty good. Where it falls apart is when you have a large number of cross-database dependencies, especially if there are mutual cross-database dependencies: DB1.dbo.sp1 needs DB2.dbo.Table2, and DB2.dbo.view2 references DB1.dbo.Table1. In that case, the workaround is so annoying and essentially comes down to “have three separate database projects, one for DB1, one for DB2, and one for a scalled-down version of DB1/DB2 without the dependencies, and then use that to inject into the other DB.” Which does kind of work, yeah, but now you’re maintaining even more. And once you get to dozens of dependencies and lots of cross-database queries? Yeah, forget about it.

Comments closed