Power BI DevOps

With any system development, following good DevOps processes is very important, and Power BI is no exception.

What is DevOps? It's a process of managing changes to software or systems in a controlled fashion, usually involving source code control, version control, testing and deployment processes. Wikipedia describes it as:

"DevOps is a combination of software development and information technology operations. DevOps is a set of software development practices that aim to shorten the systems development life cycle while delivering features, fixes, and updates frequently in close alignment with business objectives." (Wikipedia)

Yes it's true that Power BI doesn't have great support for DevOps processes, but we can still manage it with good development practices.

Source Control

First of all you need a source control system; you could use a number of tools, including Azure Devops Server (formally TFS) or Git, if you want an easy way of getting started with Git then try GitHub.

The point of this is every time you make a change to a Power BI Desktop file, you save the resulting PBIX file in your source control repository, with a comment explaining what has changed and why. You can then roll back to any version of the file in the future should you need to.

Note that PBIX files can become very large when you import data, so you may want to limit the size by saving the file as a PBIT, a Power BI Template. When you next load the PBIT it will load the data again. It's not ideal, but saves a lot of space. Just choose 'Save As' and change the type to 'Power BI template'.

Note that most source control providers also bring functionality such as automated change tracking, merging different branches, etc. which are not supported with Power BI. They'll just store your version history.

Testing

After making a change, you need to test it. the first step is to test it locally in Power BI Desktop, this should include testing to make sure new functionality works as expected, but also regression testing to make sure that new functionality has not broken or compromised existing functionality.

Then we need to deploy a version for UAT (user acceptance testing). This requires publishing the file to PowerBI.com, however we don't want to overwrite the old version of the report just yet, in case there are any problems.

So create a new Power BI workspace, called something suitable like 'UAT Workspace' or similar. This should be secured so that only authorised testers can access it, to prevent it from being used in production.

The UAT testers can then view this version of the report in parallel with the production report, and compare the difference.

Production Release

Once the new report has been signed off, deploy the new report from Power BI Desktop into the main production workspace. Don't forget to then delete the report (and associated dataset) from the UAT workspace, you don't want this one to be used going forward.

Do make sure that production reports are deployed into a shared App Workspace and not into your own personal Power BI workspace, yes it's easy to use 'My Workspace', but what if you leave your job, your account gets compromised, you want other people to modify the report, etc. etc. etc. - just don't do it!

Can this be automated?

Yes, and no!

There is limited support for Power BI through Azure DevOps. PowerShell can be your friend here and help, but it's a painful and very limited experience, and not one that we recommend.

Power BI Deployment Pipelines

If you have Power BI Premium (or Premium Per User) then you can make use of Power BI Deployment Pipelines, which are a huge step forward in release management.

Your developers work in a (Premium) development workspace, we recommend looking into Premium Per User for this, to help reduce the workload on your production Premium capacity.

Then their changes can be deployed into a (Premium) testing workspace, once it has been tested and approved then the changes can be deployed into a (Premium) production workspace.

This provides structure and incremental promotion of changes through the release process. It manages the promotion of multiple items in one go (reports, datasets, etc.), and you can even configure parameter values so that different dataset parameters are automatically applied in the promotion process; which enables you to configure different data sources or Power Query filters in different environments.

However it is not perfect:

• All three workspaces have to be Premium (or Premium Per User)
• Sensitivity Labels are not supported
• You lose the ability to download the PBIX following deployment
• There is no source control, version control or rollback

Find out more at https://docs.microsoft.com/en-us/power-bi/create-reports/deployment-pipelines-overview

Alternative Solution - Apps

If you use Power BI Apps, then you can perform UAT directly in your production Workspace, so long as your users don't have access to it, you only want your testers to see it.

Then once it's been tested and approved, you can update the App which will distribute it to the users.

We find this to be a very good solution, if your report distribution and consumption is largely App based, especially if you don't have Power BI Premium.

So what doesn't this cover?

The process above helps the testing and change control process for your process driven development team. However, there are some big limitations:

• It only works for your dev team who understand and embrace DevOps processes
• No change tracking
• No auditing of who did what
• No rollback

How do you apply this to your Power BI power users around the organisation; Mary in finance, Tim in production, Grace in marketing etc. - none of them have Git, or will ever want to follow DevOps processes.

So you end up with a partial DevOps implementation. This is still better than nothing, but you need something else, another level of protection when things go wrong.

And what about backups; you religiously adhere to DevOps processes for you database development, but you still back up your production environment don't you?

You also need to know which other reports may be impacted by the report/dataset/datasource that you're about to change. You can't easily see this from within Power BI.

Power BI Sentinel - To The Rescue!

Power BI Sentinel will automate your Power BI backups, giving you peace of mind that you have a roll-back plan and an audit/investigation process should you ever need it; for both your DevOps users and the power users who don't follow your process.

The change tracking feature helps identify when something was broken, pointing you to which version to roll back to, and Auditing shoes you who changed anything, and when.

Impact assessment

You can use Power Bi Sentinel's data lineage tool to determine which reports use a specific dataset or datasource. You can then very quickly assess the potential impact of making a change, without having to scour through hundreds of reports.

Documentation

With any development process, the documentation is usually the part most disliked by developers; and it's almost universally bypassed by non-developers! Power BI Sentinel automates your dataset documentation, leaving your developers to focus on what they enjoy doing, and filling in the missing gaps from your business users.

Power BI, DevOps & Power BI Sentinel - a good match?

Using DevOps processes where you can will help your developers create, test and deploy good functional Power BI reports in a controlled way.

Power BI Sentinel provides an additional layer of functionality, rollback, disaster recovery and documentation to your environment, for both your DevOps team and your business users.

Together they provide complete control, and comfort that your Power BI estate has minimal risk.

We're also working on exposing your Power BI lineage to you in a Power BI report, so you'll be able to easily determine the impact of any changes to help plan your testing and signoff process.