Skip to main content

Lesson 5 — Anatomy of a project

What you'll be able to do: open an EasyFabric repo and know what each folder is for and where a given change belongs.

The idea​

Once you know a platform is described in YAML (Lesson 3), the repository stops being intimidating — it's just three kinds of description, grouped by folder. If you can answer "am I describing a source connection, a table, or the semantic model?" you always know where your file goes.

In EasyFabric​

Inside the project, the platform description lives under a Dataplatform folder. The three folders that matter most day-to-day:

Dataplatform/DP/
├── Connections/     ← how to reach each source  (one folder per connection)
│   └── adv-advworks/adv-advworks.yaml
├── Objects/         ← the tables (Bronze + Silver)  (grouped by source)
│   ├── AdvWorks/customers.yaml
│   ├── AdvWorks/orders.yaml
│   └── Internal/date.yaml
└── Models/          ← the semantic model(s) for Gold
    └── DM/model.yaml

Three questions, three homes:

I want to…I edit a file in…Lesson
Tell EasyFabric how to reach a source (a blob store, files, a database)Connections/6
Add or change a table and its columnsObjects/6
Shape clean data into facts, dimensions, and measures for reportingModels/8

A connection is defined once and reused by many objects — the demo's adv-advworks connection describes CSV settings (delimiter, header, date format) that every AdvWorks table inherits. An object is one table. A model ties Silver tables together into a semantic model for Power BI.

Alongside the platform description sit the environment configuration files — one per environment (DEV, TST, PRD), e.g. dp.dev.yaml. These hold the where: which Fabric workspace, which lakehouses, which tenant and service connection to deploy into. You write the platform description once; the environment files let the same description deploy into different workspaces. That's how "promote from DEV to PRD" becomes "run the same YAML against a different environment file" — no copy-paste, no drift.

Where to look in the reference

Tables shows the Bronze/Silver-from-Objects and Gold-from-Models split with a folder diagram; Configuration config documents the environment files. To bootstrap a real project from scratch, the /setup-easyfabric agent scaffolds this layout for you.

Check your understanding​

You need to (a) change the CSV delimiter for all AdvWorks tables and (b) add a new column to just the orders table. Which folders?
  • (a) The delimiter is a property of the source, shared by every AdvWorks table → edit the Connection (Connections/adv-advworks/...). Change it once, all objects using it inherit it.
  • (b) A column belongs to one table → edit that Object (Objects/AdvWorks/orders.yaml).

The split mirrors the idea: connection-level settings are shared; object-level settings are per-table.

Why is the same platform described once but with separate dp.dev.yaml / dp.prd.yaml files?

Because what the platform is (tables, columns, model) is identical across environments, but where it deploys (workspace, lakehouses, tenant) differs. Splitting the two means DEV and PRD can't drift apart — you promote the exact same description, pointed at a different environment. It's the schema-on-write "one source of truth" idea applied to environments.

Recap​

  • The platform is described in three folders: Connections/ (sources), Objects/ (tables), Models/ (semantic model).
  • Ask "connection, table, or model?" and you always know where to edit.
  • Environment files (dp.<env>.yaml) hold the where, so one description deploys to DEV, TST, and PRD without drift.

Next: put it into practice — Your first source and table →