Changelog¶

Releases are tagged <major>.<minor>.<patch> and published to PyPI as allez, to the VS Code Marketplace as vscode-allez, and as a GitHub release carrying both files. The CLI and the extension share one version.

0.1.0 - October 2026¶

allez 0.1.0 on PyPI · vscode-allez on the Marketplace · GitHub release (wheel and VSIX)

The first public release. allez was built and used privately for two months before this; that history is folded into one entry, so this page says what allez is, not what it was.

allez CLI¶

Six verbs over the Fabric CLI, fab. allez apply imports one item into a branch workspace and checks it is there. allez deploy runs fab deploy for every workspace in dag order, hooks included, and with --branch-workspace --commit-to-git publishes a fresh branch workspace and connects it to its branch. allez provision creates and configures branch workspaces; allez teardown deletes one branch's, or every orphaned one. allez audit and allez document run offline. Every verb takes --plan, which prints the exact fab calls a run would make and touches nothing.
allez.yml is automation config. The root file declares environments:, optional protected-branches:, a branch-workspace: block (capacity, roles, domain, tags, settings, identity, and the git: block the binding deploy connects with) and the dag: that orders config.yml files, with hooks either side of each publish. A sub-folder's allez.yml patches the root. Every key is validated at load, before any fab call, and allez.schema.json gives the editor completion and hover text. allez.yml.
The dag orders config files, not workspaces. A node is a sub-folder's config.yml or a .deploy/config-overlay/*.config.yml overlay, with depends_on, pre_deploy_hooks, post_deploy_hooks and an environments: scope. A workspace can be revisited. Deployment dag.
A node publishes what fabric-cicd would. Every config.yml setting is read per environment the way fabric-cicd 1.4.0 reads it, a mapping yielding its entry for the environment, and the plan, allez document, the Deployment view and allez audit all honour the publish and unpublish filters and core.repository_directory. deploy --plan prints Item types: resolved for --env and an Excluded: line naming each item a publish filter excludes and the key; --since lists only published items, and a removal may read not in unpublish.items_to_include (kept). A filter without its features: flag, both folder filters for one environment, or a regex that does not compile is refused at load, naming the file, the key and the fix. config.yml.
$allez.* tokens in parameter.yml. $allez.<sub-folder>.$workspace.$id, $allez.<sub-folder>.$items.<Type>.<Name>.$id, $sqlendpoint and $sqlendpointid resolve against the right workspace for --env, per dag node, inside allez deploy, so a report can bind to another workspace's model before that workspace has ever been deployed. A node resolves only the rules for the item types it publishes, so a workspace the dag revisits through an overlay can name items a later node publishes; the plan prints the rest as deferred. The repo keeps its tokens: every file a publish rewrote is restored, byte for byte. Variables.
A hooks library, and your own hooks. A hooks file is a flat steps: list; each step's action names a Python file in your repo's .allez/hooks/ or one of the seven hooks allez ships: run_notebook, run_pipeline, run_item, refresh_semanticmodel (with Power BI's enhanced refresh body and a per-partition report), query_semanticmodel (one DAX query, its rows printed in the deploy log), fab_api and publish_sqlproj (a SQL database's or a warehouse's sqlproj definition, built and published by Fabric, so no SqlPackage anywhere). A hook's name spells the item type or format as Fabric writes it. Placeholders such as {{ workspace_id }} fill from the node. Signatures are checked at load. Hooks.
Branch workspaces, named from the branch. [<repo>]-[<branch-slug>]-[<sub-folder>], created by provision, filled by the binding deploy, committed back to the branch selectively so an item the workspace lacks is never deleted from it, related to dev in the Fabric UI, swept by teardown --orphans once the branch is gone. Protected branches (main, master, release/* by default, or the root protected-branches:) are refused before any fab call. Workspaces are found by name on every run; nothing records an id. Branch workspaces.
allez audit checks that parameter.yml covers every environment-specific id, offline. An id no rule rewrites (uncovered) or a rule with no value for an environment (env-gap) fails it; a rule that matches nothing (dead-rule) and a rule or token that resolves before what it names is published (order) warn, or fail with --strict. Ids fabric-cicd rebinds by itself are skipped. A finding that is the design is accepted in the sub-folder's allez.yml under audit.accept: with a reason; it still prints, never counts, and warns unused-accept when it stops matching. --junit-xml writes one test case per scanned file.
The plan says which items will change. allez deploy --since <ref> lists, under each node, the items that differ between that commit and the working tree: + new, ~ changed with the files named (dimmed when only ids moved), - removed with the unpublish verdict. The pipelines pass --since deployed/<env>, a tag every green deploy moves. Reading the plan.
allez document prints the solution as JSON. The plan's data, the audit's findings for every environment, the lines each rule matches, and every id reference with how it is covered (autobinding, dynamic replace, static replace, $allez token, uncovered) and, per item, whether a filter excludes it. Offline, for tools.
Readable console output, on a laptop and on an agent. Numbered, foldable sections per dag node, coloured phases, and Azure Pipelines logging commands when a run is on an agent, so warnings reach the run summary.
No secrets, no state. allez carries no credential: the git connection is made once with fab mkdir and named in allez.yml; pipelines authenticate with workload identity federation. The only folder it owns beside your solution is .allez/: committed hooks, and a git-ignored id cache that serves --plan.

VS Code extension¶

vscode-allez, on the Marketplace. The audit's findings in the Problems panel at their file and line; quick fixes for an uncovered id, a missing environment and a config.yml the dag does not list; CodeLens above each rule and dag node, counting what the node publishes; schema help for allez.yml; and a Deployment view that draws the dag per environment with the id references between items, coloured by coverage, saying which config.yml key excludes an item, with a find box that outlines the items whose <Name>.<Type> matches a regular expression (.Notebook, SemanticModel|Report) and dims or hides the rest, and an icon per hook step for the item type it acts on. It reads allez document, so it needs no Fabric login. Nothing requires it. Usage · Finding items.

Packaging and versions¶

pip install allez. The package on PyPI is allez, as are the import and the command. It depends on typer, PyYAML, rich and ms-fabric-cli, so one install brings fab and fabric-cicd with it. Releases are built and published by release.yml from a tag, with PyPI's trusted publishing and a managed identity on the Marketplace publisher, so no token exists anywhere; the tag must agree with the version in src/allez/__init__.py, which pyproject.toml reads, and in the extension's package.json. Install.
Pinned where it matters, floating where fabric-cicd floats. A solution repo pins allez by setting allezVersion in its pipeline variables, and its templates run pip install allez==<version> and nothing else. ms-fabric-cli is bounded to <2 and brings fabric-cicd, so those two float within that bound and every deploy log prints the versions it got. This repo keeps one plain requirements-dev.txt for its own development and CI, compiled from the dev group in pyproject.toml. Python and the hosted image are pinned by the pipelines themselves. Deployment versions.

The sample¶

The solution in fabric/, which this repo deploys to its test tenant from GitHub Actions. The Azure Pipelines example a team starts from, with placeholders and the solution's own version, is allez-example. Both are a worked example; the CLI runs anywhere.

Three workspaces, four dag nodes. allez-orchestration (a SQL database, published by publish_sqlproj, and a data pipeline that reads it, runs the notebook and refreshes the model, published last by an overlay), allez-data (a warehouse whose schema the same hook pushes as its sqlproj definition, a lakehouse with a shortcut, a Spark environment in a Fabric folder, a notebook attached to all three, a scratch notebook the deploy skips through publish: exclude_regex, a dbt job) and allez-reporting (a semantic model and a report), with parameter.yml rules, $allez tokens and a connection id per environment for the pipeline's Lookup and refresh that rebind every cross-workspace id. Sample.