Get started with deployment pipelines

This article walks you through the basic settings required for using deployment pipelines in Microsoft Fabric. We recommend reading the deployment pipelines introduction and understanding which items can be deployed before you proceed.

You can also complete the Create and manage a Fabric deployment pipeline training module, which shows you step by step how to create a deployment pipeline.

Note

In a deployment pipeline, one Premium workspace is assigned to each stage. Before you start working with your pipeline in production, review the capacity requirements for the pipeline's workspaces.

Prerequisites

To access the deployment pipelines feature, you must meet the following conditions:

Note

You can also see the deployment pipelines button if you previously created a pipeline or if a pipeline was shared with you.

Step 1 - Create a deployment pipeline

You can create a pipeline from the deployment pipelines entry point in Fabric, or from a specific workspace. If you create a pipeline from a workspace, the workspace is automatically assigned to the pipeline.

To create a pipeline from anywhere in Fabric:

  1. From the Workspaces flyout, select Deployment pipelines.

    A screenshot of the deployment pipelines entry point.

  2. Select Create pipeline.

    A screenshot of the create pipeline button.

  3. In the Create a deployment pipeline dialog box, enter a name and description for the pipeline, and select Next.

    Screenshot of the name and describe pipeline dialog.

  4. By default, the pipeline has three stages named Development, Test, and Production. You can accept these default stages or change the number of stages and their names. You can have anywhere between 2-10 stages in a pipeline. Select +Add to add another stage, delete stages, or rename them by typing a new name in the box. Select Create when you're done.

    Screenshot of the customize pipeline dialog. The Add and delete options are outlined, as is the name of the development stage.

For pipelines with more than three stages, use the arrows on the top-right corner to navigate between stages.

Screenshot of arrows in the top right corner of the deployment pipelines home screen for navigating between stages.

After the pipeline is created, you can share it with other users, edit, or delete it. When you share a pipeline with others, they receive access to the pipeline and become pipeline admins. Pipeline access enables users to view, share, edit, and delete the pipeline.

Step 2 - Assign a workspace

Note

If you're creating a pipeline directly from a workspace, you can skip this stage as the workspace is already selected.

After creating a pipeline, you need to add the content you want to manage to the pipeline. Adding content to the pipeline is done by assigning a workspace to the pipeline stage. You can assign a workspace to any stage.

Follow the instructions in the link to assign a workspace to a pipeline.

Step 3 - Make a stage public (optional)

By default, the final stage of the pipeline is made public. A consumer of a public stage who has no access to the pipeline sees it as a regular workspace, without the stage name and deployment pipeline icon on the workspace page next to the workspace name.

You can have as many public stages as you want, or none at all. To change the public status of a stage at any time, go to the pipeline stage settings and check or uncheck the Make this stage public box.

Screenshot showing the stage settings icon next to the name of the stage on the deployment pipelines page.

Screenshot of the stage settings with the make this stage public checkbox highlighted.

Step 4 - Deploy to an empty stage

When you finished working with content in one pipeline stage, you can deploy it to the next stage. Deploying content to another stage is often done after you've performed some actions in the pipeline. For example, made development changes to your content in the development stage, or tested your content in the test stage. A typical workflow for moving content from stage to stage, is development to test, and then test to production, but you can deploy in any direction. You can learn more about this process, in the deploy content to an existing workspace section.

Deployment pipelines offer two options when it comes to deploying your content:

After you choose how to deploy your content, you can Review your deployment and leave a note.

Step 5 - Deploy content from one stage to another

Once you have content in a pipeline stage, you can deploy it to the next stage, even if the next stage workspace has content. Items with the same name and type are overwritten. You can learn more about this process, in the deploy content to an existing workspace section.

To deploy content to the next stage in the deployment pipeline, select the deploy button at the bottom of the stage.

When reviewing the stages cards, you can see the last time content was deployed to each stage.

Deployment time is useful for establishing when a stage was last updated. It can also be helpful if you want to track time between deployments.

To examine the differences between the two pipelines before you deploy, see compare content in different deployment stages.

Step 6 - Create deployment rules (optional)

When you're working in a deployment pipeline, different stages may have different configurations. For example, each stage can have different databases or different query parameters. The development stage might query sample data from the database, while the test and production stages query the entire database.

When you deploy content between pipeline stages, configuring deployment rules enables you to allow changes to content while keeping some settings intact. For example, if you want a semantic model in a production stage to point to a production database, you can define a rule for this. Define the rule in the production stage under the appropriate semantic model. Once a rule is defined or changed, you need to redeploy the content. The deployed content will inherit the value defined in the deployment rule, and will always apply as long as the rule is unchanged and valid.

Read about how to define deployment rules.