Skip to content

Example usage

This section presents an example of how allez can be used: trunk-based development on Azure Pipelines, with a branch workspace per feature branch and an approval before test and prod. The example is its own repository, allez-example: the sample solution with placeholders, the three pipelines and GitVersion.yml, installing a pinned allez release. The steps are below, with an animation of the workflow that walks through one change from branch to prod.

To adopt it, start with the repo structure, then follow Tenant setup and Pipeline setup. The allez repo tests itself with a smaller flow on GitHub Actions (GitHub Actions).

Adapting the flow

The pipeline files set which branch deploys to which environment and what approval it needs; allez only derives a branch workspace's name from a branch. Whichever flow you pick, a deployed workspace is published by allez deploy and never updated from git, because an update from git cannot parameterize.

You want What changes
Git Flow (a branch per environment) Trigger a deploy pipeline on each deployed branch (dev, test, main, …) and map each to a stage running allez deploy fabric --env <env>. Set protected-branches: [main, dev, test] at the root of allez.yml so no branch workspace is ever made for a deployed branch, and change the first step of provision-feature.yml to accept the branches you develop on.
Release branches (test and prod from release/*) Split deploy.yml: the Dev stage on main, the Test and Prod stages on release/* with no paths: filter (a freshly cut branch carries no new commits).
Test automatic, only prod gated Remove the approval from fabric-test. Every merge then deploys dev and test, and the prod approver reads plan-prod.
No test environment Delete the Test stage and PlanTest, move PlanProd to the end of the Dev stage, and remove test from environments: in the root allez.yml and from each config.yml.
Git-connect test as well Outside allez: connect the test workspace to main, the same way dev is connected (if dev is connected to main).
No version Delete the GitVersion step from fab-setup-steps.yml and the tag step from the Prod stage. Runs are named by date again, and the Environments page shows commits.
Different approvals An approval is an Azure DevOps environment check; allez has no setting for it. Put one on any environment, or none.

Trunk-based development

  • One long-lived branch, main. It is the only branch that deploys, and what is on it is what every environment holds.
  • Every change is a short-lived feature/* branch off main, merged back by pull request.
    • A feature branch gets its own branch workspaces while it lives (branch workspaces), so nothing is tested in a shared workspace before it merges.

Azure Pipelines

  • The three pipelines run in Azure Pipelines. The repo can be on GitHub, as allez-example is, or in Azure Repos; Azure Pipelines reads either. Nothing in allez needs them: the pipelines are one worked example of running the CLI, and any automation that can run allez does (why).
    • provision-feature.yml: queued by hand on a feature branch, makes its branch workspaces.
    • validate.yml: runs allez audit on every pull request into main.
    • deploy.yml: promotes the solution on every merge to main.
  • provision-feature.yml and deploy.yml sign in to Fabric as a service principal, with no stored secret (pipeline setup).

Environments and approvals

  • An Azure DevOps environment is a named deployment target a pipeline stage declares: fabric-dev, fabric-test, fabric-prod, one per Fabric environment.
    • An approval check on an environment pauses the stage until someone named approves it.
    • Before each approval, the stage before it publishes the plan for the next environment, so the approver reads what will change (reading the plan).