Git integration and deployment pipelines
Fabric has two lifecycle tools that are often mixed up. Git integration versions the items of one workspace. Deployment pipelines copy content between workspaces that represent stages.
Git integration
A workspace connects to one branch of one repository, optionally to a folder in it. Supported providers are Azure DevOps and GitHub (plus GitHub Enterprise). You need:
- Azure DevOps: organization, project, repository, branch and folder.
- GitHub: a repository URL and a connection (a personal access token or the Fabric GitHub app) with the Contents read and write permission to commit.
After connecting, changes show as Uncommitted in the workspace. You Commit workspace changes to the branch, and Update to pull changes from the branch into the workspace. A commit includes only the items you select, so changes to multiple items can be split into several commits.
The usual team pattern is one workspace per developer on a feature branch, then a pull request to main. The repository stores item definitions (for example a notebook as files), not the data.
Deployment pipelines
A pipeline has up to ten stages; the common layout is Development, Test, Production, each assigned to a workspace. Key behaviour:
- Deploying is always from one stage to the next; you can deploy all items or select some.
- Items are matched by name and type. New items are created, existing items are overwritten.
- Select related adds dependencies, such as the semantic model behind a report, so bindings stay intact.
- Deployment rules change data sources, parameters or default lakehouse per stage, so Test does not point at Dev data.
- Folder structure is preserved, so moving an item to a folder in Dev moves it in the target on the next deploy.
- Data in items such as lakehouse tables is not copied, only the definition.
Unsupported items are skipped, so check the item support list when a design includes a less common item type. Lakehouses, warehouses, notebooks, pipelines, eventstreams and Eventhouses are among the supported ones.
Database projects
For a warehouse you can also use a database project (SQL database project in VS Code or Azure Data Studio). It builds the schema, validates references such as invalid object names, and publishes a dacpac. Use it when the question asks to verify invalid references before deployment.
Exam traps
- Git integration does not move content between environments; a deployment pipeline does.
- Git commits capture item definitions, not lakehouse data.
- Deploying only a report can break its binding; use Select related.
- Deployment rules are for per-stage settings; do not hardcode values in items.
- Committing needs write permission on the repository contents, not just read.
Practice questions
Choose an answer, then review the explanation to check your understanding.
1. You connect a workspace to an Azure DevOps repository. Which details must you provide?
Show answer
Answer: A.For Azure DevOps you pick the organization, project, repository, branch and folder. GitHub uses a repository URL and a connection with credentials.
2. You changed a report that is bound to a semantic model in Dev. You must deploy only what is needed and keep the report bound to the model in Test. What do you do?
Show answer
Answer: B.Select related adds the items the selected item depends on, so the binding survives with minimal deployment.
3. You changed three items in a Git-connected workspace but want to commit only one of them now. What can you do?
Show answer
Answer: B.The source control pane lets you select which changed items to commit, so one commit can cover a subset.
4. A stage in a deployment pipeline needs a different connection string in Test than in Dev. What do you configure?
Show answer
Answer: B.Deployment rules override data source and parameter values per stage when you deploy.