Exploring DEV / TEST / PROD Environments in Power BI - Data Ideology

Table of Contents

    Exploring DEV / TEST / PROD Environments in Power BI

    Exploring DEV / TEST / PROD Environments in Power BI

    Most corporate IT/BI departments utilize Development, Test, and Production environments to release reports to the business. Here’s how to accomplish that in Power BI.

    While Power BI doesn’t offer one specific method to work through this progression, there are several options that can be utilized via Workspaces and Apps. The two main options are suggested by Melissa Coates in the Microsoft whitepaper for deployment:

    Handling Dev/Test/Production Environments Option 1

    This option offers the most straightforward and simplistic model. It involves setting up on singular Workspace to be utilized as a “Dev” environment. Here, the report creator (and other collaborating members) can publish a report to the Workspace and make changes without end users being able to see. When the development team is finished with their changes, they can push to the corresponding App, which acts as a “Prod” environment.

    The biggest issue with this method is that there isn’t a designated “Test” environment. Technically the report creator(s) could do a direct report share with Test users during the UAT phase. The downside with this option is that while UAT is going on, no additional development can happen without the testers immediately seeing the changes. Also, if the report needs to reference different database connections (Dev, Test, Prod), this option makes it unable to reference both Dev and Test.

    Handling Dev/Test/Production Environments Option 2

    The second option offers a more robust solution with entirely different Workspaces for Dev/Test/Prod, including corresponding Apps for Test and Prod. A report would be created and published to a Dev Workspace. Once ready, it would then be re-published to a Test Workspace (with new database connections, if necessary). The App would be created to allow testers for the UAT phase. When that phase is complete, the report would finally be re-published to a Prod Workspace. A Prod App would be created to allow for the end users to view the report.

    While this is certainly the more ideal way to handle the report progression, it also involves much more upkeep. The first method involved managing two elements (1 Workspace, 1 App), but this method involves managing five elements (3 Workspaces, 2 Apps). Remember that all of this setup is for one subject matter and/or end users. If you’re in a BI team that creates reports for Finance, Marketing, HR, etc., this five-element setup needs to be multiplied for each of those groups.

    Our Recommendation

    While those are the two main options suggested in the white paper, there is another solution that could be a happy-medium. This option includes a Development Workspace where the initial report would be published. When ready for UAT, the report would be re-published in a separate Test Workspace and testers would be given access to the report. Once vetted, the report would be pushed to the App, which would serve as a Production environment where end users would be given access.

    This option offers a designated place for all three phases, while limiting the amount of upkeep. And if you want to limit the upkeep even more, you can reuse the Development workspace as a repository for all reports in development, regardless of the subject matter.