Skip to main content

Lesson 4 — The moving parts

What you'll be able to do: name the main components, and — crucially — say which ones act at deploy time versus run time.

The idea​

A big source of early confusion is mixing up two very different moments:

  • Deploy time — "make the shape exist." Your YAML is turned into real Fabric objects (lakehouses, tables, views, semantic model). Happens when you push to Git.
  • Run time — "put data in the shape." A notebook running inside Fabric reads the metadata and loads Bronze → Silver → Gold. Happens on a schedule or on demand.

Lesson 3 told you these are separate steps. This lesson tells you which component does each, so nothing feels like magic.

In EasyFabric​

Four parts, following one flow from your keyboard to a report:

1. Your YAML (the specification) — connections, objects, and models you write in VS Code. This is the source of truth. Everything downstream is derived from it.

2. The generator / API (the brain) — reads your YAML and produces the technical output: table definitions, SQL views, the semantic-model definition, and notebook code. It knows how to turn a declaration into Fabric objects, so you don't. (This is apps/api-generator plus the client-side generator — an implementation detail you rarely touch directly.)

3. The Azure DevOps pipeline (the conveyor belt) — triggered when you push. It runs the generator and deploys the results into your Fabric workspace: lakehouses, tables, views, semantic model, reports. This is deploy time. After it runs, every object exists — empty.

4. The wheel package easyfabric-py (the bridge) — a Python package installed in your Fabric environment. At run time, notebooks call it to actually move data: load_data_bronze, load_data_silver, load_data_gold. It reads the same YAML metadata (stored in the Meta lakehouse) to know what to load and how.

Put together as a single sentence you can hold in your head:

You write YAML → push to Git → the DevOps pipeline runs the generator to deploy empty objects (deploy time) → a notebook using the wheel package loads data into them (run time).

Notice the YAML is read twice, by two different components, at two different moments: by the generator at deploy time to build the shapes, and by the wheel package at run time to fill them. Same source of truth, two consumers. That's why the metadata-driven principle from Lesson 3 is so central — it's the contract both halves agree on.

Go deeper

The System overview shows the same components with diagrams, and the Wheel package page covers the run-time bridge in detail.

Check your understanding​

Sort these into "deploy time" vs "run time": (a) a Bronze table appears in the lakehouse, (b) yesterday's CSV rows land in that table, (c) the semantic model is created, (d) Silver quality checks run over new rows.
  • Deploy time (shapes): (a) the Bronze table appears, (c) the semantic model is created.
  • Run time (data): (b) rows land in the table, (d) Silver quality checks run over new rows.

The giveaway: creating an object is deploy; moving or checking rows is run.

Both the generator and the wheel package read your YAML. Why isn't that wasteful duplication?

They read it for different purposes at different times. The generator reads it at deploy time to build object shapes; the wheel package reads it at run time to decide what data to load and how. One shared source of truth, consumed by two components — which is exactly what "metadata-driven" enables. It's the opposite of wasteful: it guarantees the shape and the loading logic can never drift apart, because they come from the same file.

Recap​

  • Four parts: YAML (spec) → generator/API (brain) → DevOps pipeline (deploy) → wheel package (run-time loading).
  • Deploy time makes objects exist; run time puts data in them. Keep those two moments separate in your head.
  • The YAML is read twice — by the generator to build and the wheel to load — which is why one clean specification matters so much.

Next: where all this lives in the repo — Anatomy of a project →