Skip to content

Tenant setup

Tenant preparation for the example solution: permissions, capacity, git and data connections, and named workspaces. The steps build on Fabric-CICD in Practice: Groundwork. Apply the parts your deployment uses.

allez runs as whoever is logged in to fab: you on a laptop, a service principal in CI. This page calls that the deploying identity. Pipeline setup adds the Azure DevOps configuration and the two service principals used by the example.

Tenant settings are per tenant. A second solution repo reuses them.

  1. Tenant settings
  2. Capacity
  3. Git connection
  4. Workspaces
  5. Domains and tags
  6. Data connections

Tenant settings

Fabric admin portal Tenant settings. Turn on each setting for a security group that holds the identity shown; people and service principals get access through groups, never by name:

Tenant setting Section For
Service principals can call Fabric public APIs Developer settings Every deploying identity that is a service principal. Every fab call needs it. On by default.
Service principals can create workspaces, connections, and deployment pipelines Developer settings The identity that runs allez provision, which creates branch workspaces. Off by default.
Users can synchronize workspace items with their Git repositories Git integration The identity that runs allez deploy --branch-workspace --commit-to-git, which connects branch workspaces to git and commits. Also every developer who commits from the Fabric UI.

Capacity

Fabric admin portal Capacity settings the capacity named by branch-workspace.capacity:

Capacity permission Section For
Contributor Contributor permissions The identity that runs allez provision, which creates branch workspaces on this capacity.

Git connection

allez deploy --branch-workspace --commit-to-git connects each branch workspace to git through a Fabric source control connection that holds a credential for the repo's host. Make it once, for the provider the root allez.yml's git block names.

A service principal's credential:

fab mkdir "/.connections/<name>.Connection" -P \
  connectionDetails.type=AzureDevOpsSourceControl,\
  connectionDetails.creationMethod=AzureDevOpsSourceControl.Contents,\
  connectionDetails.parameters.url=https://dev.azure.com/<org>/<project>/_git/<repo>,\
  credentialDetails.type=ServicePrincipal,\
  credentialDetails.tenantId=<tenant-guid>,\
  credentialDetails.servicePrincipalClientId=<spn-app-guid>,\
  credentialDetails.servicePrincipalSecret=$GIT_SPN_SECRET

Fabric runs its git operations as that credential, so add the service principal to Azure DevOps: Organization settings Users Add users, with Basic access (Stakeholder can't write to repos). Then give it Contribute on the solution repo (Repos the repo Security): it commits to every feature branch.

Fabric's GitHub integration authenticates with a personal access token (fine-grained, scoped to the one repository, with Contents read and write), not a service principal. The sample in this repo uses this shape.

fab mkdir "/.connections/<name>.Connection" -P \
  connectionDetails.type=GitHubSourceControl,\
  connectionDetails.creationMethod=GitHubSourceControl.Contents,\
  connectionDetails.parameters.url=https://github.com/<owner>/<repo>,\
  credentialDetails.type=Key,\
  credentialDetails.key=$GITHUB_TOKEN

[Check the parameter names against the connection types Fabric lists for GitHub; they come from the REST reference, not from a run.] A commit from a branch workspace is authored by the token's owner, so use a machine account rather than a person where you can.

Pass the secret from the shell; do not put it in a file. To rotate it, fab rm the connection and run the same command again; nothing in the repo changes.

  1. Create it as the identity that runs allez deploy --branch-workspace --commit-to-git, so that identity owns the connection. Or create it as an admin, then share it with that identity under Manage connections and gateways.
  2. Put its name in the root allez.yml as branch-workspace.git.connection-name.

Workspaces

Create a dev, test and prod workspace for each sub-folder of fabric/, on a capacity, with infrastructure as code (IaC) or the portal. Name each exactly as core.workspace.<env> in that sub-folder's config.yml. The sample has three sub-folders, so it needs nine.

Grant the deploying identity Contributor on each workspace under Workspace Manage access. The example pipelines split that across two service principals, one for dev and test and one for prod, and adds an admin group per environment (pipeline setup).

Optional: connect dev to main

Only the Fabric UI changes: with branch-workspace.git.base-env: dev set, each branch workspace appears nested under dev. Skip both and nothing else changes.

Connect each dev workspace to main: Workspace Source control, with the git connection, pointing at that sub-folder's directory, direction prefer remote (git's version wins where they differ). allez deploy --env dev publishes dev; never update it from git or commit from it.

Domains and tags

Optional. provision can put every branch workspace in a domain and tag it (branch-workspace). Both must exist first: a domain is made in the Fabric admin portal under Domains, and the deploying identity and your developers must be among its contributors if that was narrowed from the default; a tag is made there under Tags, or on the domain's page.

Data connections

Every connection an item uses is deployed as it is, for example a Copy activity's source or a dbt profile, and the publish fails if the deploying identity can't use it. Share each one with User access: Manage connections and gateways the connection Manage users. Before the first deploy to an environment, give that environment's deploying identity access on its connections. Its id goes in parameter.yml as a literal per environment (fabric-cicd files).