CI/CD in MS Fabric — Coming from GitHub Actions, Here's What I Found

My Background

I'm a data engineer with a Python background. My CI/CD setup was simple and clean:

• Write code locally in VS Code

• Push to GitHub

• GitHub Actions handles the rest — testing, deployment, automation

Everything was code driven, version controlled, and reproducible. I had full control over every step of the process.

When I started using MS Fabric, the first thing I wanted to figure out was — how does CI/CD work here?

Spoiler: it's very different. Some parts frustrated me deeply. Some parts genuinely impressed me. Here's the honest breakdown.

What I Tried

I went after two things right away:

1. Git Integration with Azure DevOps — to version control my Fabric items

2. Deployment Pipelines — to promote changes across Dev → Test → Prod environments

The Frustration #1 — Azure DevOps Git Integration

In GitHub Actions, everything lives in a YAML file. You write it, commit it, version control it like any other piece of code. It's clean, transparent, and fully reproducible.

In Fabric, connecting to Azure DevOps is a click-through UI process. You go through menus and buttons to set up version control. There's no YAML, no code, no single file you can point to and say "this is my CI/CD configuration."

For a developer used to having everything in source control, this feels deeply uncomfortable.

One thing worth noting — Fabric does support GitHub as well, not just Azure DevOps. If you're coming from a GitHub background that might feel slightly more natural. But the fundamental issue remains — it's still a UI driven process, not a code driven one.

The Frustration #2 — There Is No True Local Development Story

This is the bigger frustration, and I want to be specific because it matters.

When I first complained about browser-based notebooks, immediately I found the Fabric has got VS code integrated. And yes, that's true. But here's the thing — it doesn't solve the core problem.

Even with VS Code connected, you're still running code on a remote Fabric Spark cluster. That means:

• ⏱ 2-3 minutes cluster startup every time you begin a session

• 🌐 Network latency on every code execution

• 🐛 Limited debugging compared to a true local environment

• 📵 No offline development — no internet means no work

Compare that to your local Python workflow where you hit run and get results in milliseconds.

So the real issue isn't browser vs VS Code. It's deeper than that. There is no true local development story in Fabric. Everything runs remotely, and that fundamentally changes how fast you can iterate and experiment.

For Python developers, fast iteration is everything. You try something, it fails in 2 seconds, you fix it, you move on. In Fabric that feedback loop is slower. And you feel it constantly.

The Fortune — Fabric REST API

Here's where things got interesting.

The Fabric REST API is genuinely powerful for automating deployments. You can trigger deployment pipeline stages programmatically, which finally felt familiar — it's the kind of control Python developers expect from a CD workflow.

This is where Fabric starts to feel less like a BI tool and more like a proper engineering platform. Instead of clicking through the UI to promote changes, you can write a script, call the API, and automate the entire promotion process.

I'm still digging into this fully and will share a dedicated post with real code snippets soon. But early impressions are very positive.

My Honest Take

The Git integration asks you to give up the smooth, code-driven workflow you're used to. The lack of true local development is a real productivity cost — not something you just get used to quickly. And if you're coming from GitHub Actions, the jump is bigger than you'd expect.

But the API side gives me some hope in continuous deployment. Once you start automating through the REST API, Fabric starts to earn its place as a serious data engineering platform.

What's Next

In my next post I'll walk through how I used the Fabric REST API for CD automation — with real code snippets and a step by step breakdown.

If you're a data engineer making the same transition from Python and GitHub Actions to MS Fabric, I'd love to hear your experience in the comments.