Deployment Pipelines in MS Fabric
Inkey Solutions, February 17, 202673 Views
Microsoft Fabric’s deployment pipelines tool provides developers with a production environment where they can collaborate with others to manage the lifecycle of organizational content. Deployment pipelines enable creators to develop and test content in the service before it reaches the users.
When you deploy content from one pipeline stage to another, there are limited items that are supported in deployment.
Link: Supported Items
Prerequisites to Create Deployment Pipeline
- You should have a Microsoft Fabric subscription
- You must be admin of a Fabric workspace
Pipeline structure
You can decide how many stages you want in your deployment pipeline. There can be anywhere from two to 10 stages. When you create a pipeline, the default three typical stages are given as a starting point, but you can add, delete, or rename the stages to suit your needs.
By Default, Stages:
- Development
- Test
- Production
Item pairing
Pairing is the process by which an item (such as a report, dashboard, or semantic model) in one stage of the deployment pipeline is associated with the same item in the adjacent stage. Pairing occurs when you assign a workspace to a deployment stage or when you deploy new unpaired content from one stage to another (a clean deploy).
A good understanding of pairing is crucial to help you understand when items are copied, when they’re overwritten, and when a deployment fails.
If items aren’t paired, even if they appear to be the same (have the same name, type, and folder), they don’t overwrite on a deployment. Instead, a duplicate copy is created and paired with the item in the previous stage.
Paired items appear on the same line in the pipeline content list. Items that aren’t paired, appear on a line by themselves
Create a Deployment Pipeline
Reference Link :-
Autobinding
In Fabric, when items are connected, one of the items depends on the other. For example, a report always depends on the semantic model connected to it. A semantic model can depend on another semantic model, and can also be connected to several reports that depend on it. If there’s a connection between two items, deployment pipelines always tries to maintain this connection.
Autobinding in the same workspace
During deployment, deployment pipelines checks for dependencies. The deployment either succeeds or fails, depending on the location of the item that provides the data that the deployed item depends on.
- Linked item exists in the target stage – Deployment pipelines automatically connect (autobind) the deployed item to the item it depends on in the deployed stage. For example, if you deploy a paginated report from development to test, and the report is connected to a semantic model that was previously deployed to the test stage, it automatically connects to the semantic model in the test stage.
- Linked item doesn’t exist in the target stage – Deployment pipelines fail a deployment if an item has a dependency on another item, and the item providing the data isn’t deployed and doesn’t reside in the target stage. For example, if you deploy a report from development to test, and the test stage doesn’t contain its semantic model, the deployment fails. To avoid failed deployments due to dependent items not being deployed, use the Select related button. Select related automatically selects all the related items that provide dependencies to the items you’re about to deploy.
Limitations
- The maximum number of items that can be deployed in a single deployment is 300.
- The maximum number of stages that can be created in a single deployment pipeline is 10.
- Downloading a .pbix file after deployment isn’t supported.
- Microsoft 365 groups aren’t supported as pipeline admins.
- When you deploy a Power BI item for the first time, if another item in the target stage has the same name and type (for example, if both files are reports), the deployment fails.
- The deployment fails if any of the items have circular or self dependencies (for example, item A references item B and item B references item A).
- PBIR reports aren’t supported.
Semantic Model Limitations
- Datasets that use real-time data connectivity can’t be deployed.
- A semantic model with DirectQuery or Composite connectivity mode that uses variation or auto date/time tables, isn’t supported.
- During deployment, if the target semantic model is using a live connection, the source semantic model must use this connection mode too.
- After deployment, downloading a semantic model (from the stage it was deployed to) isn’t supported.
- If autobinding is engaged, then:
- Native query and DirectQuery together isn’t supported. This includes proxy datasets.
- The datasource connection must be the first step in the mashup expression.
- When a Direct Lake semantic model is deployed, it doesn’t automatically bind to items in the target stage. For example, if a LakeHouse is a source for a DirectLake semantic model and they’re both deployed to the next stage, the DirectLake semantic model in the target stage will still be bound to the LakeHouse in the source stage. Use datasource rules to bind it to an item in the target stage. Other types of semantic models are automatically bound to the paired item in the target stage.
Dataflow Limitations
- Incremental refresh settings aren’t copied in Gen 1.
- When you’re deploying a dataflow to an empty stage, deployment pipelines creates a new workspace and sets the dataflow storage to a Fabric blob storage. Blob storage is used even if the source workspace is configured to use Azure data lake storage Gen2 (ADLS Gen2).
- Service principal isn’t supported for dataflows.
- Deploying common data model (CDM) isn’t supported.
- If a dataflow is being refreshed during deployment, the deployment fails.
- If you compare stages during a dataflow refresh, the results are unpredictable.
- Autobinding isn’t supported for dataflows Gen2.
