::: Uma's Blog :::: Power BI Premium Deployment Pipelines

The deployment pipelines tool enables BI creators to manage the life-cycle of organizational content. The deployment process lets you clone content from one stage in the pipeline to another, typically from development to test, and from test to production. The separate dataset refresh is required because data isn't copied from one stage to another.

Power BI also applies the configured deployment rules to the updated content in the target stage.

The tool is designed as a pipeline with three stages:

Development: This stage is used to design, build, and upload new content with fellow creators. This is the first stage in deployment pipelines.
Test: You're ready to enter the test stage after you've made all the needed changes to your content. You upload the modified content, so it can be moved to this test stage. Here are three examples of what can be done in the test environment
- Share content with testers and reviewers
- Load and run tests with larger volumes of data
- Test your app to see how it will look for your end users
Production: After testing the content, use the production stage to share the final version of your content with business users across the organization.

Let’s see how to create a pipeline. A pipeline is created for a workspace, in this case Development Team is a workspace name with premium capacity.

It creates 3 workspaces for each stage, by default the naming convention will same as below.

If you need a custom name, you can rename these workspaces under Workspace Settings

When you deploy a content to this workspace, this will deploy to the stage based on your settings that you define when you crated the pipeline. In here it deployed in Development stage as shown below. In this case Development Team workspace, which is development stage.

There are two ways to deploy the content from one stage to the next one. You can deploy all the content or you can select which content items to deploy.

You can select which content items to deploy

You can also deploy content backwards, from a later stage in the deployment pipeline, to an earlier one. Deploying to a previous stage works only if the previous stage is empty. When deploying to a previous stage, you can't select specific items. All content in the stage will be deployed.

Once you delete the previous content in Test, you will see the Deploy to previous stage option available.

Auto-binding

When you use selective deploy to deploy Power BI items, deployment pipelines checks for dependencies. The deployment will either succeed or fail, depending on the location of the item that provides the data that the deployed item relies on.

Linked item exists in the target stage - Deployment pipelines will automatically bind the deployed item, to the item it relies on in the deployed stage. For example, if you deploy a paginated report from development to test, and it's connected to a Power BI dataset that was previously deployed to the test stage, it will be automatically connected to that database.
Linked item doesn't exist in the target stage - Deployment pipelines will 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 Power BI dataset, the deployment will fail. 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.

Auto-binding works only with Power BI items that are supported by deployment pipelines and reside within Power BI. To view the dependencies of a Power BI item, from the item's More options menu, select View lineage.

Create deployment rules

There are two types of deployment rules:

Dataset rules - Defined on data sources and parameters, in each dataset. These rules 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 deployment rule, and will always apply as long as the rule is unchanged and valid.
Paginated reports - Defined for the data sources of each paginated report. You can use these rules to determine the data sources of the paginated report.

After modifying the report

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.

Let’s do a modification one of the reports

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.