Deployment Pipelines in Power BI and Fabric were released in public preview way back in May 2020 and then made Generally Available in September 2020.
Even with how long they have been out, I rarely see them talked about when they are a very handy tool for Developers to ensure reports and Fabric content are safely moved between workspaces.
Plus it provides some helpful tools for collaborating with other developers.

Let’s look into how Development Pipelines work and can be of use to you.

 

 

CONTENTS

    1. Setting up a Deployment Pipeline
    2. Using a Deployment Pipeline
    3. Useful Tools within a Deployment Pipeline
    4. Limitations of Deployment Pipelines

 

 

Setting up a Deployment Pipeline

To set up our first deployment pipeline, we want to find where we can build one.
In the Power BI service, you can find the tab for them on the left hand menu as shown below:

 

 

Next, we want to click the ‘New Pipeline’ button and enter a name for our pipeline.
Then we get a popup window asking us to ‘Customize your Stages’.

 


The ‘Stages’ in this sense are basically what path you want your Fabric Items to go through.

—————————————————————————————————————————————

*Note:
Whilst Deployment Pipelines are a Power BI experience feature, you can use it for Fabric content as well as Power BI reports.
The Full list of Fabric content that can be used in Deployment Pipelines as of 26/03/2024 are:

  • Data Warehouses
  • Data Lakehouses
  • Data Pipelines
  • Notebooks
  • Dataflows
  • Datamarts
  • Semantic models (Datasets)
  • Reports
  • Paginated reports
  • Dashboards

—————————————————————————————————————————————

In this example, our Fabric items will go through the staging path of:

Development -> Test -> Production

Meaning the selected Fabric item will start in the ‘Development’ workspace, then be promoted by a user to the ‘Test’ workspace, and then be promoted by a user to the ‘Production’ workspace.

You can have up to 10 stages in your deployment pipeline as shown in the screenshot above.
Not sure why you’d need 10 stages in your pipeline, but it’s good to have the option haha.

We’ll stick with the default three stages in this example.

 

Once that’s made you should get a screen that looks like this:

 

1. Shows the Stages we just made.

2. Where we assign a workspace to each individual stage.

 

Now we want to assign a workspace to each individual stage.
I’ve gone with a typical Dev, UAT (User Acceptance Testing) and Prod pipeline as shown below:

 

 

—————————————————————————————————————————————

*Note:
If you can’t see the workspace you want to assign, there is an in list of the limitations of Deployment Pipelines further down in this blog, but there are three key ones that can cause you to not see the workspace:

– You need to be an admin of the workspace to assign it.

– The workspace must reside on a Fabric capacity.

– The workspace can only be in one Deployment Pipeline, so if the workspace is already being used in another Deployment Pipeline, you can’t use it in a new pipeline.
(You also can’t use the workspace even if you don’t have access to the other Deployment Pipeline that is already using said workspace.
There’s no pop-up or alert to tell you it is being used, so in this scenario, you won’t even know that this is what’s causing the error).

—————————————————————————————————————————————

Perfect! We’ve now set up the Deployment Pipeline.
Now we can get into how to use it.

 

Using a Deployment Pipeline

I’ve made some test Fabric content to demonstrate the Pipeline process, specifically a Data Warehouse, a Report, a Semantic Model and a Dashboard.

The first helpful visual you get is a display of what Fabric content is in the workspace and how many of said Fabric content there is.
You can navigate with the arrows on the left and right and as you can see, I have one Semantic Model and one Report.

 

 

If you click the ‘Deploy’ button now, it will deploy everything you have in the workspace.
However if you click the show more button it will give you a list of every individual item in the workspace.
Here you can select individually what items you want to promote and which ones you don’t.

I’ve promoted the report and the associated semantic model to the ‘Test’ stage and as you can see those Fabric items are still in the previous stage.
As you can see, this is a significantly faster and safer way to move between workspaces then downloading and republishing the report.

You can also delete the report from the previous workspace if you wish by clicking on the ellipsis next to the item and clicking ‘Delete’.

 

Useful Tools within a Deployment Pipeline

You can view the change you’ve just made by clicking on the ‘Deployment History’ button in the top right corner.

 

This area is excellent for collaboration.
I can see exactly what items have been deployed to what stage, at what time and date, who deployed it and can even view any notes they left when deploying the content as shown below.

 

 

There is also a handy compare tool you can click in between two stages that will show you whether an Item is different, new or not in the previous stage, as you can see:

 

 

Plus if an item is different you can hover over the item and a ‘Review Changes’ button should appear.
If you click that button, you’ll get a side by side comparison of the code with the differences highlighted for both items.

 

This code comparison feature is unfortunately not available for Reports.

 

Overall some useful change tracking tools to help manage the pipeline!

 

Limitations of Deployment Pipelines


A full list from Microsoft regarding the limitations of Deployment Pipelines can be found here at the bottom of the web page.

But I’ll add it here with some additional notes

  • You need to be an admin of the workspace to assign it.
  • The workspace must reside on a Fabric capacity.
  • The workspace can only be in one Deployment Pipeline, so if the workspace is already being used in another Deployment Pipeline, you can’t use it in a new pipeline.
    (You also can’t use the workspace even if you don’t have access to the other Deployment Pipeline that is already using said workspace.
    There’s no pop-up or alert to tell you it is being used, so in this scenario, you won’t even know that this is what’s causing the error).
  • To assign a workspace, you need at least workspace member permissions for the workspaces in its adjacent stages.
    (In my test this didn’t work and you had to be an admin, maybe this is a bug and has been fixed or I was doing something wrong).
  • A workspace containing Power BI samples cannot be assigned to a pipeline stage.
  • You can’t assign a template app workspace to a Pipeline Stage.

I think the biggest limitation is only being able to use a workspace in one Deployment Pipeline. I’m currently looking for some workarounds as there always is.

 

 

But incorporating Deployment Pipelines is a big step to productionise into your Power BI and Fabric solutions. You can even go the extra mile and start incorporating GIT as well.

Hopefully this blog will give you the information you need to start using Deployment Pipelines in your Fabric solutions!

Tags: ,