Breyta

Deila með


Assign a workspace to a Microsoft Fabric deployment pipeline

Deployment pipelines enable you to assign and unassign workspaces to any stage in a pipeline. This capability is important for organizations that already have workspaces that are used as different environments of a managed release. In such cases, you can assign each workspace to its corresponding pipeline stage, and continue working in your usual flow.

For more information about assigning workspaces and the implications regarding capacities and permissions, see The deployment pipelines process.

Important

The new user interface for Microsoft Fabric's Deployment pipelines is temporarily disabled. We are working to resolve the issue and will update this page when the new UI is available again. In the meantime, you can continue to use the original UI.

Assign a workspace to any vacant pipeline stage

To assign a workspace to a pipeline, the pipeline stage you want to assign the workspace to has to be vacant. If you want to assign a workspace to a pipeline stage that already has another workspace assigned to it, unassign the current workspace from that stage and then assign the new workspace.

Before you assign a workspace to a pipeline stage, review the limitations section and make sure that the workspace meets the required conditions.

Note

Before you assign or unassign a workspace to a pipeline, consider that every time you deploy to a vacant stage, a new workspace is created, and whenever you unassign a workspace, you lose all the stage deployments history and configured rules.

To assign a workspace to a pipeline stage, follow these steps:

  1. Open the pipeline.

  2. In the stage you want to assign a workspace to, expand the dropdown titled Add content to this stage.

  3. Select the workspace you want to assign to this stage.

    A screenshot showing the assign workspace dropdown in a deployment pipelines empty stage in the new UI.

  4. Select Assign.

Unassign a workspace from a pipeline stage

You can unassign a workspace from any pipeline stage. If you want to assign a different workspace to a pipeline stage, you first have to unassign the current workspace from that stage.

To unassign a workspace from a pipeline stage, follow these steps:

  1. Open the pipeline.

  2. In the stage you want to unassign the workspace from, select the three dots in the lower left corner.

  3. Select Unassign workspace.

    A screenshot showing the unassign workspace option in the new UI of deployment pipelines.

  4. In the Unassign workspace dialogue box, select Unassign.

    A screenshot showing the unassign workspace pop-up window in deployment pipelines. The unassign button is highlighted.

Item pairing

Pairing is the process by which an item in one stage of the deployment pipeline is associated with the same item in the adjacent stage. If items aren't paired, even if they have the same name and type, the item in the target stage isn't overwritten during a deploy. A deploy of an unpaired item is known as a clean deploy and creates a copy of that item in the adjacent stage.

Pairing can happen in one of two ways:

  • Deployment: when an unpaired item is copied from one stage to another using the Deploy button, a copy of the item is created in the next stage and paired with the item being deployed.

    The following table shows when items are paired when the deploying button is used in different circumstances:

    Scenario Stage A (for example, Dev) Stage B (for example, Test) Comment
    1 Name: PBI Report
    Type: Report
    None Clean deploy - pairing occurs
    2 Name: PBI Report
    Type: Report
    Name: PBI Report
    Type: Report
    If items are paired, then pressing deploy overwrites stage B.
    3 Name: PBI Report
    Type: Report
    Name: PBI Report
    Type: Report
    If items aren't paired, the report in stage A is copied to stage B. There are then two files in stage B with the same name- one paired and one unpaired. Deployments continues to succeed between the paired items.
  • Assigning a workspace to a deployment stage: when a workspace is assigned to a deployment stage the deployment pipeline attempts to pair items. The pairing criteria are:

    • Item Name
    • Item Type
    • Folder Location (used as a tie breaker when a stage contains duplicate items (two or more items with the same name and type)

    If a single item in each stage has the same name and type, then pairing occurs. If there's more than one item in a stage that has the same name and type, then items are paired if they're in the same folder. If the folders aren't the same, pairing fails.

    The following table shows when items are paired when a workspace is assigned in different circumstances:

    Scenario Stage A (for example, Dev) Stage B (for example, Test) Comment
    1 Name: PBI Report
    Type: Report
    Name: PBI Report
    Type: Report
    ✅ Pairing occurs
    2 Name: PBI Report
    Type: Report
    Name: PBI Report
    Type: Report
    ❌ Pairing doesn't occur (duplicates).
    ❌ Deployment fails.
    Name: PBI Report
    Type: Report
    ❌ Pairing doesn't occur (duplicates).
    ❌ Deployment fails.
    3 Name: PBI Report
    Type: Report
    Folder A
    Name: PBI Report
    Type: Report
    Folder B
    ✅ Deployment succeeds but
    ❌ this report isn't paired with dev
    Name: PBI Report
    Type: Report
    Folder A
    ✅ Pairing occurs using folder as a tie breaker for duplicates
    Name: PBI Report
    Type: Report
    No folder
    ✅ Deployment succeeds but
    ❌ this report isn't paired with dev

Note

Once items are paired, renaming them doesn't unpair the items. Thus, there can be paired items with different names.

See which items are paired

Paired items appear on the same line in the pipeline content list. Items that aren't paired, appear on a line by themselves:

Create nonpaired items with the same name

There's no way to manually pair items except by following the pairing rules described in the previous section. Adding a new item to a workspace that's part of a pipeline, doesn't automatically pair it to an identical item in an adjacent stage. Thus, you can have identical items with the same name in adjacent workspaces that aren't paired.

Here's an example of items that were added to the directly to the Test workspace after it was assigned and therefore not paired with the identical item in the Dev pipeline:

Screenshot showing adjacent stages with nonpaired items with identical names and types listed on the different lines.

Multiple items with the same name and type in a workspace

If two or more items in the workspace to be paired have the same name, type and folder, pairing fails. Move one item to a different folder or change its name so that there are no longer two items that match an existing item in the other stage.

Screenshot of a workspace assignment failing because there's more than one item with the same name and type.

Considerations and limitations

  • Only workspaces that can be assigned to a pipeline appear in the dropdown list. A workspace can be assigned to a pipeline stage if the following conditions apply:

  • 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 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.

Compare content in different stages.