Skip to content

Operating

Running the example pipelines day to day: how a release goes back, who holds which role, what a human does when prod needs a hand, and where the record of every run is.

Rollback

There is no separate rollback path. fab deploy publishes the whole folder every time, so to restore the previous state you deploy the previous known-good commit. Test the rollback on a non-prod environment first. Two places where redeploying the old commit is not a full rollback:

  • Data doesn't roll back; definitions do. A dropped column or rewritten table is not undone by redeploying the older definition. Treat schema and data changes as forward-only and fix them with a new change.
  • Unpublish is destructive on the way back too. Rolling back to a commit that never had item X unpublishes X. Confirm that is what you want before approving.
Situation Action
The change is wrong and a fix is known git revert the merge on main (normal PR). The revert walks dev, the test approval and the prod approval like any change. This is the normal path.
Prod must go back now Pipelines → Environments → fabric-prod → the deployment to return to (its run is named with the version, 1.3.2) → Redeploy. That re-runs the Prod stage of that run on that commit, behind the same approval; dev and test are untouched. Then revert on main so the next merge does not bring the bad change back.

Identities and least privilege

The target: one service principal for the non-prod environments (dev and test) and one for prod, plus the credential the git connection authenticates with. No permanent human account. The prod principal creates nothing and cannot approve its own deployment, so the prod approval is a change of identity as well as a check. Which principal holds which role, and the groups that hold them, are in pipeline setup.

Humans get access through allez.yml roles (roles): one developers group in branch-workspace.roles for branch workspaces, and one empty admin group per named environment, eligible through Privileged Identity Management (PIM) (set up).

Break-glass for prod

The prod service principal can deploy and cannot approve its own deployment. When a human must touch prod:

  1. Use a PIM-eligible Fabric admin, activated for the incident with a justification and a time limit. Nobody holds permanent write access to prod.
  2. Prefer the pipeline even in an incident (Rollback).
  3. Write any manual change back to the repo the same day. The next deploy overwrites it.
  4. Afterwards, deactivate the role and open the PR that makes the change reproducible.

Audit

  • Fabric / Purview audit log: who did what in the tenant. Alert on workspace deletion, role assignments and connection creation; provision and teardown appear as the service principal.
  • Pipeline run history: every deploy attempt publishes deploy-log-<env>-attempt-<stage>.<job> (commit, branch, run, the base commit, each node's item changes since it, then fabric-cicd's per-item output) and every plan job plan-<env>-attempt-<stage>.<job>, so a retried stage keeps the failed attempt's log too. Approvals are recorded on the fabric-prod environment.
  • Git history: the repo is the definition of every environment. A workspace that disagrees with its branch is drift, and the next deploy erases it.