Skip to content

Repo structure

The example solution's repo layout, which is allez-example's. allez itself and its docs stay in the allez repo; a solution repo installs the package.

.azurepipeline/ and GitVersion.yml belong to the example pipelines; a repo that runs allez another way leaves them out.

One repo holds one solution (philosophy). Each sub-folder of fabric/ is one workspace. The folder can have any name, but there is one root allez.yml per repo (why). Git integration keeps the folder and the workspace in step. The items are the <Name>.<Type>/ folders: git is the list of what exists. Everything else is there to deploy them.

├── 📁 .azurepipeline/                          # (1)!
│   ├── 📄 provision-feature.yml                # (2)!
│   ├── 📄 deploy.yml                           # (3)!
│   ├── 📄 validate.yml
│   ├── 📄 variables.yml                        # (5)!
│   └── 📁 templates/
├── 📄 GitVersion.yml                           # (4)!
├── 📁 .allez/                                  # (6)!
│   ├── 📁 hooks/                               # only a hook of your own
│   └── 📁 cache/                               # (23)!
├── 📁 fabric/                                  # (7)!
│   ├── 📄 allez.yml                            # (8)!
│   ├── 📁 orchestration/
│   │   ├── 📄 config.yml
│   │   ├── 📄 parameter.yml
│   │   ├── 📄 allez.yml
│   │   ├── 📁 .deploy/
│   │   │   ├── 📁 config-overlay/
│   │   │   │   └── 📄 pipeline.config.yml      # (26)!
│   │   │   └── 📁 hooks/
│   │   │       ├── 📄 schema.hooks.yml
│   │   │       └── 📄 run.hooks.yml
│   │   ├── 📁 Control.SQLDatabase/
│   │   └── 📁 Orchestrate.DataPipeline/        # (27)!
│   ├── 📁 data/                                # (9)!
│   │   ├── 📄 config.yml                       # (10)!
│   │   ├── 📄 parameter.yml                    # (11)!
│   │   ├── 📄 allez.yml                        # (12)!
│   │   ├── 📁 .deploy/                         # (13)!
│   │   │   ├── 📁 hooks/                       # (14)!
│   │   │   │   ├── 📄 schema.hooks.yml         # (15)!
│   │   │   │   └── 📄 ingest.hooks.yml         # (16)!
│   │   │   └── 📁 parameters/                  # (17)!
│   │   │       └── 📄 dbt.yml
│   │   ├── 📁 Bronze.Lakehouse/
│   │   ├── 📁 Compute/
│   │   │   └── 📁 Spark.Environment/           # (18)!
│   │   ├── 📁 Notebook.Notebook/
│   │   ├── 📁 Warehouse.Warehouse/
│   │   └── 📁 dbtJob_1.DataBuildToolJob/       # (19)!
│   └── 📁 reporting/
│       ├── 📄 config.yml
│       ├── 📄 parameter.yml
│       ├── 📄 allez.yml
│       ├── 📁 .deploy/
│       │   ├── 📁 hooks/
│       │   │   ├── 📄 takeover.hooks.yml       # (20)!
│       │   │   └── 📄 refresh.hooks.yml        # (21)!
│       │   └── 📁 parameters/
│       │       └── 📄 semantic-model.yml       # (22)!
│       ├── 📁 Report.Report/
│       └── 📁 SemanticModel.SemanticModel/
├── 📄 .gitignore                               # (24)!
└── 📄 allez.schema.json                        # (25)!
  1. Examples only. Copied whole from allez-example's .azurepipeline/, templates/ included, with the allez release named as allezVersion in variables.yml. Pipeline setup.
  2. You run it by hand, once per feature/* branch. It creates the branch workspaces, deploys into them and connects them to git. Safe to run again if it fails. Branch workspaces.
  3. Runs when a change under fabric/ or .allez/hooks/ is merged to main: deploys dev, then test and prod behind their approvals. Pipelines.
  4. The solution's version: GitVersion reads it from the tags on main and this file. Copied unchanged from allez-example. The version.
  5. The names of your service connections and the allez release. The only place you set them. Pipeline setup.
  6. The one folder allez keeps in your repo, beside fabric/. hooks/ holds your own hooks: one file per action, shared by every workspace. The common ones ship with allez, so it holds only what is yours and may not exist at all. Where allez finds a hook.
  7. Your solution. Each sub-folder is one workspace; name them as you like.
  8. Settings for the whole solution: the environments, how branch workspaces are created and connected to git, and the deploy order. allez.yml, The deployment dag.
  9. One workspace, in every environment. A branch workspace is named from the branch (allez provision).
  10. fabric-cicd's file: which workspace each environment deploys to (by name), which item types to deploy, and whether to delete items that aren't in git. Every sub-folder needs one. config.yml.
  11. fabric-cicd's file: the values to change per environment, such as ids that point at another workspace. parameter.yml.
  12. Optional. Extra settings for this workspace only: description, settings, identity, extra roles. allez.yml.
  13. Everything in the sub-folder that isn't an item: hooks files, extend templates, and any overlays (Overlays). Keeping them here means they're never mistaken for items.
  14. This workspace's hooks files. A hooks file is a list of steps that runs before or after this workspace deploys; the dag: in the root allez.yml says which and when. Hooks files.
  15. Runs after the data workspace deploys (publish_sqlproj).
  16. Runs next (run_notebook).
  17. Extend templates. parameter.yml lists them under extend:, and fabric-cicd merges their rules with its own: here the dbt job's rules. One level only (Splitting a large parameter.yml).
  18. An item, exactly as git integration saves it, inside a Fabric folder. Any <Name>.<Type>/ folder is an item: a workspace folder arrives from git integration as a plain folder with the items inside, and allez finds them at any depth.
  19. A dbt job. Its whole dbt project is inside the item, so it deploys like any other item; .deploy/parameters/dbt.yml points it at the right warehouse in each environment.
  20. Runs before the reporting workspace deploys (fab_api).
  21. Runs after (fab_api).
  22. Extend template for reporting/parameter.yml. Its rules point the semantic model at the data workspace in the same environment, using $allez.* variables. $allez.* variables.
  23. A git-ignored cache of workspace ids for --plan; safe to delete (Commands).
  24. Keeps .allez/cache/ out of git: **/.allez/cache/, no wider.
  25. Optional: a copy of the schema for editing offline. Otherwise each allez.yml's first line names the schema on GitHub at the allez tag you pin. Editor support.
  26. An overlay: a partial config.yml that narrows one dag node to the pipeline, so the orchestration workspace is visited twice, first for its database and last for its pipeline (Overlays).
  27. A data pipeline that reaches into the other two workspaces. Its parameter.yml rules rebind the notebook and the model it names with $allez.* variables, and each activity's connection with a literal per environment.