Fabric ALM end-to-end — feature workspace to PR gate to deployment pipeline to production
Four-column flow showing a change moving from an isolated feature workspace through a gated pull request into main-synced integration workspaces, then promoted by deployment pipeline through Test to Production.
// 01 · develop
workspace · per developer
Feature workspace
▸ Core semantic model
▸ report definitions
▸ notebooks
⇄ synced to feature/x
isolated · ephemeral
open pr
// 02 · pull request
gate · runs on every pr
PR quality gate
✓ naming + best practice
✓ report validation
✓ model binding check
✓ human review
approve · merge
branch · write-protected
main
// 03 · integrate
workspace · main-synced
Domain_Gold_Dev
never edited by hand
workspace · main-synced
Domain_Reports_Dev
never edited by hand
update from git
// 04 · release
stage · test
Domain_Gold_Test
UAT on prod-shaped data
○ awaiting sign-off
pipeline · gate
stage · production
Domain_Gold_Prod
served to end users
● live
// one path to production · feature → pr → main → dev → test → prod
no manual publish · no untracked changes · every release reviewed
01 / 09 Fabric ALM end-to-end — feature workspace → PR gate → deployment pipeline → production
Naming and workspace boundaries — every name answers four questions
Asset names are built from domain, type, description and environment segments. Workspaces separate curated data, reports and shared landing. Reports carry business names with no type codes or environment suffixes.
// asset naming — every name answers four questions
domain
Domain
which product or area
_
type
LH · SM · NTB
what kind of asset
_
description
Core · Landing
what it does
_
environment
Dev · Test · Prod
which stage it belongs to
// workspace boundaries — data, reports and landing never mix
workspace · curated data
Domain_Gold_Dev
lakehouses + semantic model
workspace · report layer
Domain_Reports_Test
thin reports · UAT stage
workspace · shared · env-neutral
Global_Landing
sources land once, upstream
// reports carry business names — infrastructure codes stay upstream
✓ report name
Regional performance summary
the workspace supplies the context
✗ not a report name
Domain_RPT_RegPerf_Prod
type codes and env suffixes belong on infrastructure
a name tells you what it is, where it runs, and who should touch it — before you open it
02 / 09 Naming and workspace boundaries — domain, type and environment are explicit
Land once, expose per environment — governed lakehouses via OneLake shortcuts
Source systems are mirrored once into a shared landing workspace, then curated gold lakehouses expose governed tables to each environment through OneLake shortcuts rather than data copies.
// 01 · source systems
operational system
Source A
line-of-business data
operational system
Source B
reference data
mirror
// 02 · land once
workspace · shared
Global_Landing
▸ mirrored db · Source A
▸ mirrored db · Source B
▸ intermediate lakehouses
one copy of the data
env-neutral · governed
onelake shortcut
// 03 · expose per environment
lakehouse · development
Domain_LH_Gold_Dev
governed tables · default binding
● default
lakehouse · test
Domain_LH_Gold_Test
governed tables · test tier
lakehouse · production
Domain_LH_Gold_Prod
governed tables · prod tier
// shortcuts, not copies — the data lands once
every environment reads governed tables through the same chain · no duplication to drift
03 / 09 Land once, expose per environment — governed lakehouses via OneLake shortcuts
Feature workspace discipline — isolated development, main-synced integration
Each developer works in an isolated feature workspace synced to a feature branch. Changes reach the write-protected main branch only through a gated pull request, and the integration workspaces are updated from Git — never edited by hand.
// 01 · isolated feature workspaces
workspace · developer a
Feature workspace
full working copy of the stack
⇄ feature/a
workspace · developer b
Feature workspace
full working copy of the stack
⇄ feature/b
sync
// 02 · git
branch
feature/a
branch
feature/b
branch · write-protected
main
pr + gates
pr + gates
// 03 · main-synced integration
workspace · integration
Domain_Gold_Dev
updated from git on merge
✗ no manual edits
workspace · integration
Domain_Reports_Dev
updated from git on merge
✗ no manual edits
// hand-edits can't drift production — the repo is the source of truth
feature workspaces are ephemeral · deleted or reused when the branch merges
04 / 09 Feature workspace discipline — isolated dev; integration workspaces are main-synced
Semantic model binding — validate on any tier, return to Dev before the PR
The core DirectLake semantic model in a feature workspace defaults to the Dev lakehouse. It can be rebound transiently to Test or Prod tiers for validation, but must be rebound to Dev before a pull request — the PR gate blocks any other binding.
// 01 · feature workspace
workspace · per developer
Feature workspace
directlake semantic model
Core semantic model
binding decides which tier it reads
rebind notebooks · run here only
RebindDev · RebindTest · RebindProd
default binding
transient rebind — never merged
// 02 · lakehouse tiers
tier · development
Domain_LH_Gold_Dev
● required before pr
tier · test
Domain_LH_Gold_Test
self-service validation
tier · prod-shaped
Domain_LH_Gold_Prod
pre-release sign-off
open pr
// 03 · pr gate
binding check · rest api
Binding validation
✓ bound to Gold_Dev → merge
✗ any other tier → blocked
re-run RebindDev and push
// validate against any tier — always return to the dev binding before merge
the gate makes the rule mechanical · nothing merges pointing at the wrong data
05 / 09 Semantic model binding — validate on any tier, Dev binding enforced before PR
PR quality gates — four checks between a change and main
Every pull request triggers static checks, report validation, semantic model binding validation and human review. Passing all four merges the change; any failure blocks the pull request until fixed.
// 01 · trigger
pull request
PR → main
pipeline runs on open
and on every push
// 02 · gates — all four must pass
gate 1 · static
Static checks
naming convention rules
best-practice scan on the model
gate 2 · report layer
Report validation
schema + definition checks
broken visuals fail the build
gate 3 · binding
Binding validation
semantic model must point
at Domain_LH_Gold_Dev
gate 4 · human
Review
a second pair of eyes
on every change · no exceptions
all pass
any fail
// 03 · outcome
✓ pass
Merge
into main
✗ blocked
Fix first
nothing unsafe
reaches main
// unsafe releases stop at the pr — not in production
the gates run the same way for every developer, every change, every time
06 / 09 PR quality gates — static checks, report and binding validation, review before merge
Deployment pipeline rules — code artefacts promote, lakehouses stay per environment
The semantic model, reports and notebooks are promoted as code from Dev to Test to Prod. Lakehouses and mirrored sources are not promoted — datasource rules rebind the model to each stage's lakehouse automatically.
// what the deployment pipeline promotes — and what it never touches
✓ promoted as code
In the pipeline
▸ Core semantic model
▸ report definitions
▸ ETL + rebind notebooks
identical artefacts in every stage
✗ never promoted
Outside the pipeline
▸ lakehouses — provisioned once per environment
▸ mirrored sources — land once, shared
code moves · data stays put
// datasource rules rebind the model at each stage — no manual fix-ups
stage · dev
Domain_Gold_Dev
bound to Domain_LH_Gold_Dev
rule → test
stage · test
Domain_Gold_Test
auto-rebound on deploy
rule → prod
stage · production
Domain_Gold_Prod
auto-rebound on deploy
● live
// the same code lands in every stage — only the binding changes
rules are configured once · every deploy after that is push-button repeatable
07 / 09 Deployment pipeline rules — code artefacts promote; lakehouses stay per environment
Embedded UAT sign-off — reviewers approve production-shaped reporting in the portal
Reports in the Test workspace read prod-shaped data and are embedded into the consuming portal's UAT environment, so reviewers sign off the real experience before promotion to the live portal.
// 01 · test stage
workspace · test
Domain_Reports_Test
▸ Core semantic model
▸ reports · release candidate
reads prod-shaped data
what reviewers see is what
production will look like
embed
// 02 · uat — in the consuming portal
portal · uat environment
Industry portal UAT
reports reviewed in place —
inside the pages users know,
not a BI workspace they
will never open
○ sign-off pending
sign-off
// 03 · live
portal · production
Industry portal
reports served to
end users, embedded
● released
// uat happens where the reports are actually read
reviewers approve the production experience — layout, access and data shape included
08 / 09 Embedded UAT sign-off — reviewers approve production-shaped reporting in the portal
Handover controls — runbooks, report register, lineage and operational checks
Four governance deliverables that make the platform maintainable after handover: operational runbooks, a report register, documented lineage, and scheduled operational checks.
// handover is a deliverable — four controls your team keeps
G.01
Runbooks
▸ refresh + failure procedures, step by step
▸ access requests · capacity changes
▸ written for your team, not for us
owned in your repo · versioned
G.02
Report register
▸ every report · owner · audience · purpose
▸ tiered access recorded per report
▸ retire-by-default when unused
no orphan reports · no mystery access
G.03
Lineage
▸ source → lakehouse → model → report
▸ impact analysis before any change
▸ generated from the platform, not drawn by hand
answers "what breaks if we change this"
G.04
Operational checks
▸ refresh monitoring + alerting
▸ capacity right-sizing reviews
▸ scheduled access reviews
problems surface before users notice
// the platform stays maintainable without us
leave teams capable, not dependent — governance ships with the code, not after it
09 / 09 Handover controls — runbooks, report register, lineage and operational checks