Lesson 9 — Deploying with Azure DevOps
What you'll be able to do: describe how YAML in Git becomes live, empty objects in a Fabric workspace, and why EasyFabric deploys through a pipeline rather than by hand.
This is the deploy time half of Lesson 4, seen up close.
The idea
You could click through Fabric's UI to create every lakehouse, table, and semantic model — and re-click it for DEV, then TST, then PRD, keeping all three in sync by hand. That's slow, and it drifts.
Instead, EasyFabric treats deployment as an automated pipeline: push your YAML, and a conveyor belt validates it, generates the Fabric objects, and creates them in the target workspace. Deployment becomes "push to Git," and every environment gets the identical build.
EasyFabric deliberately replaces Fabric's own Git integration and release pipelines. You drive everything from config files through one Azure DevOps pipeline — don't mix the two models.
In EasyFabric — the pipeline
When you push to your Azure DevOps repository, the pipeline runs two phases:
Build
- Validate the YAML — catch common errors before touching Fabric, so a typo fails the build, not production.
- Generate the deployment scripts and object definitions from your YAML (the generator from Lesson 4).
Deploy
- Copy your YAML to the Meta lakehouse (this is the metadata the wheel package reads at run time — Lesson 7).
- Deploy the notebooks to the Meta, Bronze, Silver, and Gold lakehouses.
- Run a notebook that creates the objects in each lakehouse.
When it finishes, every Bronze, Silver, and Gold object exists in the workspace — empty (schema-on-write, Lesson 3). Nothing has loaded yet; loading (Lesson 7) is the separate run-time step.
Notice how the pieces connect: the build uses the generator, the deploy seeds the Meta lakehouse that the wheel package later reads, and the environment file (Lesson 5) decides which workspace this all lands in. Point the same pipeline at dp.tst.yaml instead of dp.dev.yaml and the identical platform builds in TST — that's promotion, no copy-paste.
Validation happening in Build, before deploy, is a deliberate "fail early" design: the cheapest place to catch a broken table definition is a failed pipeline run, not a half-created workspace.
Setting up the pipeline, service connection, and Fabric workspace is a one-time exercise. The /setup-easyfabric bootstrap walks the Entra / Azure DevOps / Fabric prerequisites, and the Deployment section covers the pipeline and requirements in full.
Check your understanding
A colleague wants to also turn on Fabric's built-in Git integration "as a backup." Good idea?
No — EasyFabric intentionally replaces Fabric's own Git integration and release pipelines. Running both fights over the same objects and causes confusion. Pick the EasyFabric pipeline and drive everything from config.
You mistyped a column type in an object YAML. Where does it most likely surface — in the Fabric workspace, or earlier?
Earlier — in the Build phase's validation, before anything is deployed. That's the point of validating first: a typo fails the pipeline cheaply instead of leaving a half-created or broken object in Fabric.
The pipeline just finished successfully against DEV. Do your reports have data now?
No. Deploy created the empty objects. You still run the loader (Lesson 7) to fill them, then the semantic model has data for reports. Deploy = shape; load = contents — always two steps.
Recap
- Push YAML → the Azure DevOps pipeline validates (Build) then generates and creates objects (Deploy).
- It seeds the Meta lakehouse the wheel reads at run time, and targets the workspace named in the environment file — so promotion is re-running the same build against another env.
- EasyFabric replaces Fabric's native Git/release integration; validation fails early; deploy leaves objects empty.
Next: consolidate and choose your deeper path — Where to go next →