We live in a busy and stressful era. In our daily business we can not wait for weeks, months or even longer to get our insights. So we need to deliver faster. Therefor we are working agile to realize continuous delivery of results. The agile approach helps us to deliver small artifacts to the end-user in a continuous flow. But by continuously pushing new content to our end users, the chance for mistakes is growing exponentially.

To avoid mistakes, we need to add some structure to our development process. We can do this by working in a multi-tier developing process. But how do we realize that with a self-service tooling like Power BI?

Integrate multi-tier in Power BI development

You might know DTAP (in the Netherlands known as OTAP), the acronym for Development, Testing, Acceptance, and Production. This multi-tier developing process is very common in IT. But in an upcoming industry of self-service IT, this process is used only a very little. Power BI, which is positioned as a self-service data analytics tooling, does not have a standard integrated capability to apply a multi-tier architecture.

In some cases, the DTAP-street has two additional stages which are Education and Backup. In this blog we will only look at the most common four.

Development
Let’s start with the continuous delivery part. By creating Power BI reports and data modeling in Power BI, we have to do that in Power BI Desktop. In the past, it was possible to do a lot of this work in the Power BI Service as well. But more and more Microsoft pushes all the development work back to Power BI Desktop, which is a good thing in my opinion! Simply because Power BI Desktop has a lot more to offer then the functionalities which are available in the Power BI Service. So Power BI Desktop will be your development environment where you can do your data wrangling, transformations, modeling and of course create your report.

Test 
After we are done in Power BI Desktop, we publish the content to the Power BI Service. In case you want to share your content, it is a best-practice to publish to an App-Workspace, instead of publishing to your My Workspace and directly sharing. By publishing to an App-Workspace, only members and owners of a workspace will have access to the published content. So that is our test environment.

Acceptance 
To also create an acceptance environment in your App-Workspace, we will use the same content as used for testing. But, we need to add a few more people to the workspace to give them the ability to verify the results for acceptance. So you can add some key-users to the workspace as well and assign them to a member role in the old workspaces. Make sure your workspace settings are set to Members can only view Power BI content. In case your using the new (preview) workspace experience, you have to assign a contributor role to your key-users. The view-only role for workspaces does not exist yet in the new workspace experience, so you are taking more risk here.

Learn all about the new (preview) workspaces by reading the documentation. 

Production
Last but not least, the production environment.After your done with testing and accepted by your key-users, it is time to push the content to production. We will do that by publishing the app and grant access to all end-users. Make sure that you have selected all content in the workspace you want to publish in the app. Even more important, check if you have unselected the content you do not want to show to your end-users.

Best practice
There is one more really important thing to be aware of. Now you have published your report to the end-users, the use and popularity of your report will grow. This may result in access requests of new users. In case you want to grant access to new users, you have to update your published app in the workspace. By doing that, you will also push the last updated content which is available in the workspace. Possibly, this means that you publish content which is still in the testing and acceptance phase. You do not want to show that to your end users! So what to do now?

We have to make sure that we have a separate report which is published in the app to the end-user. To do that, we split each report into at least two separate Power BI Desktop files which are both published to the workspace.

First, we need to have a report which is the one selected to be included in the app. The name of the report will be visible for the end user, so be aware of the naming. Afterwards, we create a second Power BI Desktop file which is published to the workspace for testing and acceptance. Make sure you also give a logical name to the second Power BI Desktop file. Make sure you have unselected the Include in App toggle for all content accept your production content.

Possibly your workspace will look like this:
It is up to you if you want to create separate files for testing and acceptance as well. Personally, I develop in Power BI desktop and only publish my content to the Power BI Service if it is ready for testing and acceptance.

After your done with testing and the results are accepted by your end-users, you can publish exactly this version to the Power BI service with the production name and replace the existing production content. Do not forget to update the app to push the production content to the end-users. If you only want to grant access to additional users, you can simply update the app without unintentionally pushing your test and acceptance content to your end-users.