Why allez exists¶

Fabric's CI/CD features¶

The comparison below explains the limitations for both Fabric's native tools and fabric-cicd. For adoption steps, go straight to migrating from fabric-cicd.

Autobinding¶

An item definition holds references to other items, for example a notebook to its lakehouse. Promote between environments (dev → test → prod) and every reference must be rebound to the new workspace's items. A Fabric item has a unique id, its itemId. On export to git, Fabric swaps some itemIds for portable logicalIds, held in the item's .platform file; the dependency-binding matrix says which. Microsoft calls the swap autobinding. It lets Fabric rebind the dependencies between items in the same workspace as they are promoted through environments. Git content never changes between environments, so there is no rule to write and nothing to go stale.

Problems

Only references the matrix marked Yes autobinds. The rest stay pinned to the source workspace.
Binding is same-workspace only. A reference into a different workspace is always an itemId and never binds.
Connections (data sources, gateways) never bind either.

Git integration¶

Git integration connects a workspace to a branch. Commit to git copies workspace → git; update from git copies git → workspace.

Problems

Update from git rebinds logical-id references (Autobinding) and nothing else. Every other id, name, URI and connection arrives as committed.
1,000 items per workspace, 25 MB per file, no submodules.

Branch-out¶

Branch-out gives a feature branch its own workspace. From a git-connected workspace, one portal action creates the branch, connects it to a workspace (a new one on a capacity you pick, or an existing one) and fills that workspace from git.

Problems

No API. It is a portal action only, so nothing scripts it, and nothing removes the workspace when the branch merges.
The new workspace carries little of its base. Roles, settings, Spark configuration, the workspace identity and the domain are not copied.
It is an update from git, so only the references the matrix marks Yes rebind (Autobinding). Every other id still points at the base workspace.
A variable library's active value set is workspace state, so the new workspace runs on Default until someone switches it by hand.
It does not fit the deployment pipeline model. A branch workspace is not a stage and sits in no pipeline, so nothing promotes from it and nothing deploys into it.

Deployment pipelines¶

Deployment pipelines clone item metadata from stage to stage (for example dev → test → prod), with rules to change a definition per stage and autobinding for same-workspace references, across pipelines too when both have the same number of stages.

Problems

The deployment pipeline itself (stages, pairings, rules) is not in source control.
Only metadata moves. Data, workspace settings, schedules, credentials and role assignments do not.
Rules cover five item types, are set per item and per stage in the UI, and are deleted with the item. A rule can only be created once the item exists in the target stage, so the first deploy carries dev's configuration.
Autobinding needs the dependency already in the target stage or the deploy fails. Across pipelines it matches stages by position. Nothing runs the two pipelines in order; the order is kept by hand.
A Direct Lake model stays bound to the source stage's lakehouse until a data source rule repoints it. Dataflow Gen2 has no autobinding. A parameter-controlled connection isn't autobound at all.
A workspace can be in only one pipeline, so one data workspace can't feed several reporting pipelines.
No approvals, and nothing runs after a deploy.

Variable libraries¶

Variable libraries move environment-specific values into a git-tracked item with a value set per stage. The definition names a variable instead of an id, and the workspace's active value set supplies the id (one idea, two mechanisms).

Problems

Not all items can read them (for example Semantic models, Environments).
ItemReference variables hold a raw workspaceId and itemId, overridden per environment by hand. Git never swaps them for a logical id, so nothing rebinds them (binding matrix).
Which value set is active is a manually set workspace state; git does not hold it. fabric-cicd sets it on each deploy, to the set named after the environment, but Fabric's own tools leave it on Default, unless manually set in the workspace.
A reference to an item that does not exist is refused (ReferencedEntityNotFound). A new environment, or a long-lived branch workspace without the item, needs a rule to write the id in first, and that rule could have rewritten the consumer directly.
Values are plain text in git, so no secrets.

Deployment plans¶

Deployment plans (preview) are a workspace item, committed to git. A plan adds explicit order and actions, and can be attached to a Branch Out, Deployment Pipeline deploy or a Bulk Import REST API call (a closer look).

Problems

One plan, one target workspace, one operation. Nothing orders across workspaces.
fabric-cicd doesn't support them today.
Attached per operation, never as a default. A scheduled or scripted deploy must attach it every time.
Stops at the first failed item or action. No rollback, no continue-on-error. A flaky refresh leaves a half-deployed workspace.
Orders and runs; doesn't rebind. Connections, workspace identities and Spark settings aren't carried.
Can't switch a variable library's active value set, so a new workspace runs its actions on Default.
No per-environment scope on a group or action. Though this can be achieved with multiple plans.

fabric-cicd¶

fabric-cicd, Microsoft's supported library, gets furthest. Definitions come from the repo, config.yml says where they land, and parameter.yml rewrites them on the way in. That includes dynamic replacement, which resolves $workspace.$id and $items.<Type>.<Name>.$id against the real target at publish time. That reaches every id the binding matrix can't.

Problems

One config.yml deploys one workspace. A multi-workspace solution is several separate runs, and nothing orders them.
It publishes definitions and stops. Nothing refreshes a model, runs a notebook, seeds a table or sets a schedule afterwards.
Another workspace is reachable only by its literal display name ($workspace.<name>.…).
A find_value that matches nothing replaces nothing, silently.
Items are matched by display name and type, not logicalId. A renamed item is a new item, and the old one is unpublished (found by name).

What allez adds¶

Every tool above stops at one workspace. allez starts there. It is a CLI over the Fabric CLI, fab, and fabric-cicd stays the publishing engine: your config.yml and parameter.yml are untouched and each still deploys one workspace. allez supplies the part between them.

One order across workspaces. The root allez.yml declares a dag over the config.yml files, and allez deploy runs fab deploy for each in that order, so the data workspace lands before the reporting workspace that reads it (deployment dag).
Hooks either side of a publish. A notebook run, a model refresh, a warehouse's schema or an API call, from the library allez ships or a Python file in your repo (hooks).
Cross-workspace references by folder. A $allez.<sub-folder>.… token in parameter.yml resolves against the right workspace for the environment and the branch, with no display name and no raw id ($allez.* variables).
A workspace per feature branch. allez provision creates one per sub-folder with the roles, settings and identity allez.yml gives it, allez deploy --branch-workspace --commit-to-git fills it and connects it to the branch, and allez teardown removes it when the branch is gone (branch workspaces).
An audit before any deploy. allez audit reads the repo offline and names every environment-specific id no rule rewrites and every rule missing a value for an environment, the silent find_value above included (allez audit).

Credentials, connections, approvals and data stay where Fabric and your pipeline put them. Get started adds allez to a fabric-cicd repo one feature at a time.

Philosophy¶

If your existing deployments already handle ordering, hooks and cross-workspace references, you do not need allez.

One repo holds one solution: one team or domain, a handful of workspaces and one dag. allez is not built for a monorepo (CI/CD for Fabric Data Teams). Each branch gets one workspace per sub-folder for as long as the branch lives (branch workspaces).

The colleague who inherits the tool must understand it. New commands and configuration keys need to earn that cost; use what Microsoft already supplies wherever it fits.

Teams differ in how they branch, who approves what and what a deploy has to run afterwards, so allez fixes none of it. Branching strategy and approvals belong to your pipeline: allez derives a branch workspace's name from a branch and refuses the protected ones, and nothing more. What runs around a publish is a hooks file you write. The example Azure Pipelines flow is one way to put the pieces together, and adapting the flow lists the changes for others.

Outside allez's scope¶

Credentials. Users authenticate with fab auth login; pipelines supply their identity. allez stores no secrets (identities).
Connections. Create and share them outside allez. parameter.yml can replace their references; a custom hook can create them with fab.
Data. Deployments publish definitions, not rows. A hook can load data (what a deploy does not carry).
Named environment workspaces. Create dev, test and prod outside allez (tenant setup). allez provision creates only branch workspaces.