Pipelines¶
Three pipelines under .azurepipeline/ in allez-example, which a solution repo copies (pipeline setup). What each runs, how it authenticates, which tool versions it installs, and where the version that names every run comes from. The allez repo does not run these; it deploys its own copy of the sample with GitHub Actions workflows (GitHub Actions).
Pipelines and authentication¶
| Pipeline | Trigger | Steps |
|---|---|---|
| provision-feature.yml | queued by hand on a feature/* branch |
setup → allez provision fabric --env feature → allez deploy fabric --env feature --branch-workspace --commit-to-git |
| validate.yml | each pull request into main, as a required Build validation (no push trigger) |
allez audit fabric, with its JUnit file published to the run's Tests tab. No service connection (audit in the pipeline). |
| deploy.yml | push main touching fabric/ or .allez/hooks/ |
Dev: setup → allez deploy fabric --env dev --since deployed/dev → move deployed/dev → allez teardown fabric --orphans → allez deploy fabric --env test --plan --since deployed/test (last job; no credentials, published as plan-test). Test: approval on fabric-test (evaluated at stage start, so the plan is already there to read) → setup → allez deploy fabric --env test --since deployed/test → move deployed/test → allez deploy fabric --env prod --plan --since deployed/prod (published as plan-prod). Prod: approval on fabric-prod → setup → allez deploy fabric --env prod --since deployed/prod → move deployed/prod → tag the commit v<version> |
provision-feature.yml and deploy.yml share three step templates. fab-setup-steps.yml installs the allez release variables.yml names, names the run with the solution's version, enables fab's encryption fallback (hosted agents have no keyring) and logs in. It prints the installed package and tool versions before authentication. fab-deploy-steps.yml runs allez deploy as a plain script step, into workspaces that already exist; fab uses the login the setup template made. The step template then publishes the deploy log as the deploy-log-<env>-attempt-<stage>.<job> artifact. fab-plan-steps.yml installs allez the same way, runs allez deploy --plan for the next environment and publishes it as plain text, with no service connection.
Authentication is workload identity federation. AzureCLI@2 with a workload identity federation (WIF) service connection exposes servicePrincipalId / idToken / tenantId. fab auth login --federated-token logs in with that token (the OIDC assertion: the token Azure DevOps issues the job). No client secret is stored in Azure DevOps. The authMode: secret fallback reads the service principal's id, secret and tenant from a variable group.
Deployment versions¶
allez is pinned as allezVersion in variables.yml. allez's dependencies, ms-fabric-cli and its fabric-cicd among them, resolve from the ranges pyproject.toml declares, with ms-fabric-cli bounded to one major, as fabric-cicd declares its own. The versions a run got are printed at the top of every job's log, before authentication. The allez repo's own tests run against ms-fabric-cli 1.8.0 and fabric-cicd 1.4.0, the versions its requirements-dev.txt pins.
The version¶
The solution's version comes from GitVersion, read from GitVersion.yml at the repo root: the latest v* tag on main plus the commits since it. Three commits after v1.3.0, a run is 1.4.0-ci.3; the commit the Prod stage tags v1.4.0 is 1.4.0; the next merge is 1.5.0-ci.1. A pull request merged with +semver: major in its merge message bumps the major. Every run is named with it, so Pipelines → Environments → fabric-prod lists the versions prod has held, with the commit and run behind each. GitVersion needs the full history: every checkout: self in the pipelines sets fetchDepth: 0 and fetchTags: true.
What each environment holds is a tag. After every green deploy to a named environment the deploy step moves the lightweight tag deployed/<env> to the deployed commit and pushes it. Every plan and deploy then passes --since deployed/<env>, so the plan an approver reads, and the deploy log, list each node's items that will be created, changed or deleted (reading the plan). A failed deploy leaves the tag where it was, so the next plan diffs against the commit the environment last received in full; a Redeploy moves it back to the commit it redeploys. Before the first deploy to an environment there is no tag; the pipeline says so and runs without --since. The push is why every deploy job's checkout sets persistCredentials: true and why the build service holds Contribute and Create tag (setup).