Pipeline setup¶

What the example pipelines need, on top of tenant setup: the pipeline files in your repo, two service principals, the groups that hold them, and the Azure DevOps environments, branch policy and permissions the pipelines expect. Service principals and groups are per tenant; a second solution repo reuses them. The rest is per repo.

1. Start from allez-example
2. Service principals
3. Security groups
4. Azure DevOps environments and branches
5. Build service permissions
6. Register the pipelines

Start from allez-example¶

Your solution lives in its own repo and installs a pinned allez release (install). The pipelines install the same release, pip install allez==<version>, from one line in variables.yml, so nothing is checked out from the allez repo at run time. Everything a solution repo needs beyond the package is in allez-example: the sample solution under fabric/, its hook under .allez/hooks/, the three pipelines with their templates under .azurepipeline/, and GitVersion.yml at the root.

Copy, then edit¶

Fork allez-example, or copy .azurepipeline/ (the whole folder: provision-feature.yml, deploy.yml, validate.yml, variables.yml and templates/) and the root GitVersion.yml into your repo, GitVersion.yml unchanged: it is what names every run with your solution's version. The main trigger and the prod tag are already on. Then edit:

Then register the three pipelines (register the pipelines).

Upgrading¶

Read the changelog first; it lists every breaking change and how to migrate, per release. Then change the version each solution repo pins: the pip install line on laptops, and allezVersion in variables.yml. Move the tag in each allez.yml's $schema= line to the same release, or recopy allez.schema.json if you keep a copy, so editor checks match the installed version. If the release changed the pipelines folder, the changelog says so and allez-example carries the new copy; copy it again and re-apply your edits.

Service principals¶

Two service principals deploy:

Create each one from an Azure DevOps service connection. That makes the app registration, the federated credential and the connection together.

1. Azure DevOps Project settings Pipelines Service connections Create service connection.
2. Azure Resource Manager Next.
3. Identity type App registration (automatic), credential Workload identity federation.
4. Scope Subscription, any subscription. Name it sc-fabric-deploy-nonprod.
5. Leave Grant access permission to all pipelines unticked; you authorise each pipeline later. Save.
6. Entra ID App registrations the app Azure DevOps just created (its name includes the project and connection) rename it sp-fabric-deploy-nonprod.
7. Check Certificates & secrets Federated credentials has the Azure DevOps credential.
8. Azure portal the subscription Access control (IAM) remove the Contributor role Azure DevOps added. Fabric doesn't need it.

Repeat for sc-fabric-deploy-prod and sp-fabric-deploy-prod.

Security groups¶

Entra ID Groups New group. People get access through groups, never by name.

Azure DevOps environments and branches¶

Environments. Pipelines Environments create fabric-dev, fabric-test and fabric-prod.

• fabric-test: Approvals and checks Approvals an approver group, and a Timeout of one day. Every merge to main queues this approval; one nobody gave in a day is stale, and the next merge brings a newer candidate.
• fabric-prod: the same, with approver sg-fabric-approve-prod. Also add Exclusive lock, so two runs can't deploy prod at once.

Environments belong to the Azure DevOps project, not the repo. If the project holds more than one solution, give each its own three, for example sales-dev, sales-test and sales-prod. Shared ones mix every solution's runs in one history, so the Environments page no longer tells you which version of this solution is in prod, Redeploy offers the other solution's runs, and the exclusive lock makes one solution's prod deploy wait for the other's. Then change environment: in deploy.yml to match (see the end of this page).

Branches. Repos Branches:

• main: require a pull request, and turn on delete source branch after merge by default. teardown --orphans only removes branch workspaces whose branch is gone.
• main, Build validation: add validate as a required check, so a pull request cannot complete while allez audit finds an environment-specific id no parameter.yml rule rewrites. The pipeline needs no service connection, so the check runs for every pull request as soon as it is registered.
• main, Automatically included reviewers: a required reviewer group for the paths /.azurepipeline/* and /.allez/hooks/*. Both are code the deploy jobs run with the service principal's access, so a change to them gets a second pair of eyes before it merges.

Build service permissions¶

The pipeline pushes tags (the version), so the identity it runs as must be allowed to write one. Repos the solution repo Security the build service identity (<project> Build Service (<organization>)) Contribute and Create tag set to Allow. Nothing else is granted; the pipeline pushes tags and never a commit.

Register the pipelines¶

1. Register each pipeline. Pipelines Create pipeline GitHub or Azure Repos Git the solution repo Existing Azure Pipelines YAML file pick the file Save. Do it for provision-feature.yml, deploy.yml and validate.yml, named provision-feature, deploy and validate. These are your copies (start from allez-example), with the service connections already named in variables.yml. A YAML file runs nothing until it is registered.

2. Let the pipelines use the service connections. Each service connection Security Pipeline permissions:

   • sc-fabric-deploy-nonprod: provision-feature, deploy
   • sc-fabric-deploy-prod: deploy only

   If you forget, each pipeline's first run asks.

The pipelines already name the fabric-dev, fabric-test and fabric-prod environments. If you renamed them, change environment: in the pipelines to match, or the approval never happens.