Skip to content

Workflow

The example flow in action, adding a new notebook: branch and provision, develop, promote. Play it below, or read the same steps beneath it.

Watching the walkthrough

play all (stops at approvals) · previous step · replay step · play this step (again to pause) · play next step.

Workflow in text

  1. you Branch off main and push

    git switch -c feature/foo main
git push -u origin feature/foo

  2. you Queue provision-feature.yml on the branch

    Once. It has no push trigger. The Run dialog defaults to main, which is refused, so pick your branch.

  3. provision-feature.yml Create the branch workspaces

    allez provision --env feature creates and configures one empty workspace per fabric/<sub-folder> (provision).

  4. provision-feature.yml Fill them and connect them to the branch

    allez deploy --env feature --branch-workspace --commit-to-git publishes into each workspace, connects it to the branch and commits [skip ci]. If base-env is set, each workspace is also related to dev's (what a run does, why a deploy, not an update from git).

  5. you git pull before you push again

    The pipeline's commit is on your branch now.

Work in the workspace, in the repo, or both, on the same branch.

  • In the workspace

    Edit in the Fabric UI, then commit to feature/* from the workspace's source control pane. No allez involved.

  • In the repo

    Edit the definition files, then apply and verify per item:

    allez apply fabric/<sub-folder>                    # every item
allez apply fabric/<sub-folder> -i <A>.<Type>      # a subset (-i repeatable)
allez apply fabric/<sub-folder> -i <A>.<Type> --verify-run

    Commit once it verifies green.

Git integration moves committed state only, so testing a repo edit that way costs a throwaway commit per iteration and reports one coarse status for the whole workspace. allez apply pushes the uncommitted working tree to the branch workspace item by item, and a read-back after each item proves it landed. It applies no parameter.yml, so items land exactly as authored and it never promotes across environments (allez apply).

From here on, pipeline triggers do the work.

  1. you Merge the pull request into main

    Leave delete source branch on, so the branch workspaces can be swept.

  2. deploy.yml Deploy dev, sweep, plan test

    allez deploy --env dev, then allez teardown --orphans removes your branch workspaces, then the plan for test is published.

  3. approver Approve fabric-test

    After reading the test plan (reading the plan).

  4. deploy.yml Deploy test, plan prod

    allez deploy --env test, then the plan for prod is published.

  5. approver Approve fabric-prod

  6. deploy.yml Deploy prod, tag the release

    allez deploy --env prod, then the commit is tagged v<version>.

Each stage, its trigger and its steps are in the table under Pipelines. A hotfix is an ordinary merge to main that walks the same two gates. Every run is named with the solution's version (the version). When a release goes wrong: Rollback.