Get started with deployment pipelines (preview)

• 05/06/2020
• 8 minutes to read
• • 
  • 

This article walks you through the basic settings required for using deployment pipelines.

Accessing deployment pipelines

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

• You're a Power BI Pro user

• You belong to an organization that has Premium capacity

• You're an admin of a new workspace experience

Step 1 - Create a deployment pipeline

To create a deployment pipeline, do the following:

1. In Power BI service, from the navigation pane, select Deployment pipelines and click Create pipeline.

2. In the Create a deployment pipeline dialog box, enter a name and description for the pipeline, and click Create.

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

Step 2 - Assign a workspace to a deployment pipeline

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.

You can assign one workspace to a deployment pipeline. Deployment pipelines will create clones of the workspace content, to be used in different stages of the pipeline.

Follow these steps to assign a workspace in a deployment pipeline:

1. In the newly created deployment pipeline, click Assign a workspace.

2. In the Choose the workspace drop-down menu, select the workspace you want to assign to the pipeline.

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

Workspace assignment limitations

• The workspace must be a new workspace experience.

• You must be an admin of the workspace.

• The workspace is not assigned to any other pipeline.

• The workspace must reside on a premium capacity.

• You cannot assign a workspace with Power BI samples to a pipeline stage.

Step 3 - Deploy to an empty stage

Any Pro user that's a member or admin in the source workspace, can deploy content to an empty stage (a stage that doesn't contain content). The workspace must reside on a capacity for the deployment to be completed.

When deploying content to an empty stage, the relationships between the items are kept. For example, a report that is bound to a dataset in the source stage, will be cloned alongside its dataset, and the clones will be similarly bound in the target workspace.

Once the deployment is complete, refresh the dataset. For more information, see deploying content to an empty stage.

Deploying all content

Select the stage to deploy from and click the deployment button. The deployment process creates a duplicate workspace in the target stage. This workspace includes all the content existing in the current stage.

Selective deployment

To deploy only specific items, click the Show more link, and select the items you wish to deploy. When clicking the deploy button, only the selected items are deployed to the next stage.

Since dashboards, reports and datasets are related and have dependencies, you can use the select related button to check all items that those items are dependent on. For example, if you want to deploy a report to the next stage, clicking the select related button will mark the dataset that the report is connected to, so that both will be deployed at once and the report will not break.

Backwards deployment

You can choose to deploy to a previous stage, for example in a scenario where you assign an existing workspace to a production stage and then deploy it backwards, first to the test stage, and then to the development one.

Deploying to a previous stage works only if the previous stage is empty of content. When deploying to previous stage, you can't select specific items. All content in the stage will be deployed.

Step 4 - Create dataset rules

When 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 dataset rules enables you to allow changes to content, while keeping some settings intact.

Dataset rules are defined on data sources and parameters, in each dataset. They determine the values of the data sources or parameters for a specific dataset. 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 dataset rules, and will always apply as long as the rule is unchanged and valid.

Create a dataset rule

1. In the pipeline stage you want to create a dataset rule for, click Deployment settings.

   

2. From the Deployment settings pane, select the dataset you want to create a rule for.

   

3. Select the type of rule you want to create, expand the list, and click Add rule.

   

Dataset rule types

There are two types of rules you can create:

• Data source rules The data source list is taken from the dataset of the source pipeline stage. From the data source list, select a data source to be replaced. Use one of the following methods to select a value to replace the one from the source stage:

  1. Select from a list.

  2. Click Other and manually add the new data source. You can only change to a data source from the same type.

• Parameter rules Select a parameter from the list of parameters; the current value is shown. Edit the value to the value you want to take effect after each deployment.

Dataset rule limitations

• You must be the dataset owner to create a dataset rule.

• Dataset rules cannot be created in the development stage.

• When an item is removed or deleted, its rules are deleted too. These rules cannot be restored.

• If the data source or parameters defined in a rule are changed or removed from the source dataset, the rule will not be valid and the deployment will fail.

• Data source rules can only be defined for the following data sources:

  • Analysis services
  • Azure SQL Server
  • Azure Analysis services
  • Odata Feed
  • Oracle
  • SapHana
  • SharePoint
  • SQL server
  • SQL Server Analysis Services (SSAS)
  • Teradata

  For other data sources, we recommend using parameters to configure your data source.

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. 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, click 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.

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

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

Overriding content

When you deploy after making changes to content in the source stage, the content you changed in the target stage is overwritten. After clicking deploy, you'll get a warning listing the number of items that will be overwritten.

You can learn more about which items are copied to the next stage, and which items are not copied, in Understand the deployment process.

Next steps