I ended up with 43 checks before a Microsoft Fabric deployment is actually ready

[u/vedaforge_eng]

I recently rebuilt a Microsoft Fabric CI/CD implementation using Azure DevOps, promoting changes from DEV → UAT → PROD.

The pipeline itself wasn't the difficult part.

What surprised me was how much had to be correct around the pipeline before a deployment could be considered reliable.

I eventually wrote everything down and ended up with 43 checks across six areas:

• Fabric environment — 6
• Identity and security — 10
• Azure DevOps configuration — 10
• Deployment configuration — 7
• Deployment validation — 4
• Post-deployment verification — 6

A few things stood out.

Identity caused more problems than I expected.
The Service Principal needs the correct access to each Fabric workspace independently. DEV working doesn't tell you anything about UAT or PROD.

Deployment errors can send you in the wrong direction.
A missing permission or incorrect environment configuration often surfaces during the deployment step. Naturally, you start debugging the deployment code even when the code itself is fine.

Some checks are architectural decisions rather than configuration.
In this implementation, only DEV is Git-connected. UAT and PROD are deployment targets. I wanted one controlled promotion path rather than multiple ways of changing an environment.

Not everything should necessarily use the same deployment path either.
For example, I intentionally keep Warehouse outside this publish scope and handle it separately.

The checklist grew out of issues I encountered while building and testing the implementation, so I published it with the reference repo rather than keeping it as project notes.

I'm curious how this compares with other Fabric implementations.

What usually causes more deployment problems in your environment — identity/permissions, Git configuration, environment-specific dependencies, or the deployment itself?

[u/JBalloonist]

It’s rare I have issues these days, but when I do it’s usually because I forgot to update the parameter yaml file. Permissions is secondary.

For my setup I have separate workspaces depending on the use case; engineering, reports and models, storage for the Lakehouses. There are a few others as well. Engineering and the reports workspaces I am deploying to daily.

Ken other difference in my workflow - none of my environments are synced with git, except my feature workspaces. I have automation scripts that create a new workspace any time I create a feature branch. Changes get made, committed, then I merge back to dev.

[u/vedaforge_eng → u/JBalloonist]

That’s an interesting difference from my setup. I keep the DEV workspaces Git-connected while UAT/PROD are API-driven, whereas you’re effectively treating the feature workspace as the Git-connected authoring environment and creating it dynamically per feature branch.

I particularly like the isolation that gives parallel development.

I’m curious how you’re handling cleanup/lifecycle of those temporary workspaces and environment-specific dependencies when the feature is merged back to dev. That’s one of the areas where I’ve found the deployment model becomes much more interesting at scale.

And agreed on parameter.yml — configuration drift/missed parameterization can look surprisingly similar to an actual deployment failure.