Get started with deployment pipelines

Article
01/30/2023
6 minutes to read

APPLIES TO: Power BI Desktop Power BI service

This article walks you through the basic settings required for using deployment pipelines in Power BI service. It's recommended to read the deployment pipelines introduction, before you proceed.

You can also complete the Create and manage a Power BI deployment pipeline Learn module, which shows 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.

Accessing deployment pipelines

You'll be able to access the deployment pipelines feature, if the following conditions are met:

You have one of the following Premium licenses:
- You're a Power BI Pro user, and you belong to an organization that has Premium capacity.
- Premium Per User (PPU).
You're an admin of a Premium workspace.

Note

You'll also be able to see the deployment pipelines button, if you previously created a pipeline, or if a pipeline was shared with you.

A screenshot of the deployment pipelines landing page.

Step 1 - Create a deployment pipeline

You can create a pipeline from the deployment pipelines tab, or from a workspace.

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

Create a pipeline from the deployment pipelines tab

To create a pipeline from the deployment pipelines tab, do the following:

In Power BI service, from the navigation pane, select Deployment pipelines and then select Create pipeline.
In the Create a deployment pipeline dialog box, enter a name and description for the pipeline, and select Create.

Create a pipeline from a workspace

You can create a pipeline from an existing workspace, providing you're the admin of a workspace.

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

Note

If the workspace isn't assigned to your organization's Premium capacity, or to your PPU capacity, you'll get a notification to assign it to a capacity.

Step 2 - Assign a workspace

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.

Note

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

Step 3 - Deploy to an empty stage

When you finished working with content in a pipeline stage, you can deploy it to the next stage. Deploying content to another stage is usually 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 three options when it comes to deploying your Power BI content:

Deploying all content - Deploy all your Power BI content to the target stage.
Selective deployment - Select which Power BI content to deploy to the target stage.
Backwards deployment - Deploy your content to a previous stage in the pipeline.

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

Step 4 - Deploy content from one stage to another

Once you have content in a pipeline stage, you can deploy it to the next stage. Deploying content to another stage is usually 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. 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 test and production stage cards, you can see the last deployment time. This indicates the last time content was deployed to the 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 test and production deployments.

Step 5 - 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 dataset in a production stage to point to a production database, you can define a rule for this. The rule is defined in the production stage, under the appropriate dataset. Once the rule is defined, content deployed from test to production, will inherit the value as 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.

Compare stages

When two sequential stages have content, the content is compared based on the content items metadata. This comparison doesn't include comparing data or refresh time between stages.

To allow a quick visual insight into the differences between two sequential stages, a comparison icon indicator appears between them. The comparison indicator has two states:

Green indicator – The metadata for each content item in both stages, is the same.
Orange indicator - Appears if one of these conditions is met:
- Some of the content items in each stage, were changed or updated (have different metadata).
- There is a difference in the number of items between the stages.

When two sequential stages aren't the same, a compare link appears underneath the orange comparison icon. Clicking the link opens the content item list in both stages in Compare view. Compare view helps you track changes or differences between items, in each pipeline stage. Changed items get one of the following labels:

New – A new item in the source stage. This is an item that doesn't exist in the target stage. After deployment, this item will be cloned to the target stage.
Different – An item that exists both in the source and the target stage, were one of the versions was changed after the last deployment. After deployment, the item in the source stage will overwrite the item in the target stage, regardless of where the change was made.

Datasets with configured deployment rules that haven't been deployed, are also marked as different. This is because deployment rules are not applied until the datasets are deployed from the source stage to the target stage, which includes the configured rules.
Missing from – This label indicates that an item appears in the target stage, but not in the source stage.

Note

Deployment will not impact missing from items.

The comparison is designed to help you understand the difference between the stages. In the comparison display, items are arranged according to the logic listed below.

The source workspace items are ordered alphabetically within groups, based on their type. The groups are ordered according to the flow of data. For example, first datasets, then reports, and lastly dashboards.
The target workspace is ordered according to the source workspace. Each item resides in the same row as its equivalent item in the source stage.
Items that exist in the target workspace but not in the source workspace, are displayed at the bottom of their type group, in alphabetical order.