2.2 Core Workflows and Decision Points

The Two-Loop ALM Model

Application lifecycle management in Fabric is built from two complementary mechanisms. Do not confuse them — questions reward knowing which one does what.

Git integration (the inner loop) connects a single workspace to a single branch in Azure DevOps Git or GitHub (these are the only two supported providers). Developers commit item definitions to source control and update the workspace from Git, giving branching, pull requests, and diff history. Items are serialized to text — for example, a warehouse becomes a SQL database project (DDL), and a lakehouse stores shortcut and OneLake-security definitions but not its table data.

Deployment pipelines (the outer loop) move content between workspaces — typically Dev -> Test -> Prod — without touching Git. A pipeline has up to 10 stages. You promote (deploy) items forward, and Fabric shows which items differ between stages.

A mature setup uses both: developers work against Git-bound feature workspaces, and a deployment pipeline promotes the integrated content through Test to Prod.

The commit/update and sync cycle

Git integration tracks two directions. Commit pushes workspace changes into the branch; Update pulls branch changes into the workspace. The workspace's source-control panel shows each item as Synced, Modified, Conflict, or Uncommitted, and you resolve conflicts before syncing. Because each workspace binds to exactly one branch, the common team pattern is a separate (often isolated) workspace per developer or per feature branch, then a shared integration branch that the deployment pipeline draws from.

Deployment Rules, Parameters, and What Is Not Copied

When you promote an item, environment-specific values must change — a Test lakehouse should not point at a Dev data source. Fabric provides two tools:

• Deployment rules: per-item rules that swap values during deployment, for example pointing a semantic model at the production data source or setting a parameter value for that stage only.
• Parameters / variable libraries: reusable values (connection strings, lakehouse IDs) resolved per stage so the same item definition behaves correctly in each environment.

Critically, data source credentials are never copied during deployment. Each stage keeps its own secured connection so a promotion cannot overwrite production secrets. The first deployment of a new item into an empty stage copies the item; after that, only the differences flow, and the target's stage-specific rules re-apply.

A second exam favorite: deployment pipelines for a lakehouse can be configured to copy schema and shortcuts but not the table data — data is environment-specific and stays put. Always read the stem for the word credentials or data; if it appears, the answer usually involves "not copied / stays stage-specific."

Layered Access: Roles, Item Permissions, OneLake Security

Access is decided by three layers working together. Workspace roles grant broad rights:

Item-level permissions then refine access to a single item via sharing (for example, granting Read or ReadData on one lakehouse to someone who is not in the workspace). OneLake security roles add row-, column-, and folder-level RBAC over the data itself; only Admin or Member can create them. A Viewer reads tables through the SQL analytics endpoint but does not automatically get raw OneLake file access when OneLake security is enforced.

Orchestration: Pipeline vs Notebook

For moving and coordinating work, choose by primary need. A data pipeline owns orchestration — scheduling, control flow (ForEach, If), retries, parameters, and multi-activity sequencing. A notebook owns code-heavy transformation with Spark, custom libraries, and distributed compute. A pipeline can invoke a notebook as one activity, which is the canonical pattern: the pipeline schedules and retries, the notebook does the heavy Spark work.

Pipeline activities and monitoring you should recognize

A data pipeline is assembled from activities: Copy data (the bulk data mover between sources and sinks), Notebook, Dataflow Gen2, Stored procedure, Script, and control-flow activities like ForEach, If Condition, Until, and Invoke pipeline. Each activity supports a retry count and retry interval, and activities are wired by On success / On failure / On completion / On skip dependencies, which is how you build error handling. Pipelines run on either a schedule trigger or an event trigger (for example, a file-arrival event).

Choosing a pipeline over a bare scheduled notebook matters precisely because the pipeline gives you these retries, dependencies, parameters, and centralized monitoring.

ALM quick recap

• Git integration connects a workspace to Azure DevOps or GitHub and version-controls item definitions (not data); it supports one branch per workspace.
• Deployment pipelines promote content across up to 10 stages (e.g., Dev → Test → Prod), copying metadata only — source data and credentials are never moved.
• Use deployment rules and parameters to repoint data sources per stage so promoted items bind to the right environment.