In today’s environment, the need for developers to control, automate, and monitor the lifecycle of their data analytics products is crucial to the success and health of any business. Power BI Deployment Pipelines give developers the ability to do all three in a single, easy-to-use interface from directly within the Power BI Service.
In this blog, I’ll describe what Power BI Deployment Pipelines are and why they are useful, and then provide step-by-step directions on how to set them up.
What are Power BI Deployment Pipelines?
Deployment Pipelines is a native feature accessible within Power BI Service (Premium licenses only) that enables developers to manage the development lifecycle of Power BI content within their organization’s tenant. The tool is designed to be an efficient and reusable pipeline that automates the movement of content through the development stages.
Typically, there are three stages of development (listed below), and until recently, these were the only three stages that were available when setting up a deployment pipeline (more on that later).
- Development – design, review, and revise content in a development workspace.
- Test – test and validate the accuracy and functionality of content in this preproduction workspace.
- Production – the workspace content has been tested and is ready to be consumed by your end-users either in a Power BI Workspace App or with direct access to the workspace.
Note that the different stages of a pipeline each have their own associated workspace and that it is not possible to assign multiple workspaces to a single pipeline stage.
This method allows you to separate content in different stages of development physically – you wouldn’t want an end-user who only has View access to your dashboards to view a dashboard that is currently in the development phase.
The screenshot below shows a pipeline with the three typical stages of deployment. Each stage in this pipeline represents a real workspace with the content in the list below the stage actually in that workspace.
Developers select the content from one stage and click the green Deploy button at the bottom of that stage to deploy it to the next.
Clearly, this feature makes deployment extremely easy. Other benefits include the ability to monitor content across the workspaces associated with a deployment pipeline.
In the screenshot above, you can see that the gap between each workspace has either a green checkmark or an orange “X.” These two symbols are meant to denote whether or not the content between the workspaces matches.
The green checkmark represents that all of the content in the two workspaces is a one-for-one match. Everything from the preceding workspace has been promoted to the next stage.
- The orange “X” denotes that a change has occurred and that the content needs to be promoted to the following workspace to reflect the latest version. If this is the case, a user can simply click on the Compare button to view what is different from one workspace to another.
Why are Deployment Pipelines Important?
The major benefit of a deployment pipeline is the automation of promoting content from one workspace to another. Before this feature existed, teams needed to download a PBIX file and republish it to the next stage.
Another useful function that deployment pipelines offer is the ability to automate the task of replacing a dataset’s data source. Teams will often use development or test data when developing their dashboards and then change that data source to use production data when the dashboard is ready to be used by the end users.
The process can be automated by creating a deployment rule using the window in the screenshot below so that when a dataset is promoted to a new stage, the data source automatically changes.
Note that developers can also change the value of a parameter with deployment rules as well.
Tips and Reminders for Power BI Deployment Pipelines
- Whenever possible, use nonproduction data in preproduction workspaces and configure deployment pipeline rules to automate the transition of data sources between workspaces.
- Provision workspace access to the different development lifecycle stages, as well as the deployment pipeline itself, accordingly.
Additionally, users can see the deployment history, as shown in the following screenshot.
How to Create Power BI Deployment Pipelines
Creating a deployment pipeline is inordinately easy and only takes a couple of minutes. The first thing you need to do is make sure that the workspaces that you want to use for each stage have been created and are either a Premium Per User or Premium Capacity workspace, and then follow these steps:
- Click on the Deployment Pipelines icon in the left panel of the Power BI Service home screen and then the green Create pipeline button on the following screen.
2. Provide your pipeline with a name and an option description, and then click Next.
3. The next pop-up window is where you will create the different stages of your pipeline. There is a minimum of 2 and a maximum of 10 stages.
4. In the next screen, assign workspaces to each of the stages. If you don’t see them, double-check that they are Premium workspaces. If changes to this step need to be undone, you will need to delete the pipeline and start over.
Closing
Power BI has tons of features beyond just data visualization, especially since the release of Microsoft Fabric. Power BI is a suite of tools that can fully serve an organization’s data and analytics practice when leveraged properly.
The ability to effectively monitor and control data products throughout their lifecycle is necessary and made extremely easy with Power BI deployment Pipelines.
Have more Power BI questions? Our team of Power BI experts is here to help!
FAQs
No, if you need to edit the stages, add, or remove stages, then you will need to delete the pipeline and recreate it with the new requirements.
Those with “Admin” access to the deployment pipeline are the only ones who can use it or edit it in any way. Those with Admin access to a pipeline do not automatically inherit ANY level of access to the associated workspaces, and those with ANY level of access to the associated workspaces do not inherit access to the deployment pipeline. These two accesses are completely independent of each other.
