Power BI

7501 bookmarks

Custom sorting

Power BI implementation planning: Develop content and manage changes - Power BI

This article helps you to develop content and manage changes as part of managing the content lifecycle.

Group changes into distinct releases with version history.

Depending on how you author content, you'll make different decisions about how to manage it. For instance, for Power BI reports and semantic models, a Power BI Desktop (.pbix) file has fewer options for version control compared to the Power BI Desktop project (.pbip) format. That's because a .pbix file is a binary format, whereas the .pbip format contains text-based human-readable content and metadata. Having human-readable content and metadata allows for easier tracking of model and report changes by using source control. Source control is when you view and manage changes within content to its code and metadata

Excel: A client tool for pivot tables and live connected tables that work with a semantic model. Power BI Report Builder: A desktop application for creating paginated report (.rdl) files.

You can develop and test content without affecting the content that's currently in use. This avoids changes that can cause unintentional disruption to content in production. You can use separate resources for developing and testing content, like using separate data gateways or Fabric capacities. This avoids that resources used for development and testing disrupts production workloads, causing slow data refreshes or reports. You can create a more structured process to develop, test, and release content by having discrete environments for each of these stages. This helps you to improve productivity.

Test and production workspaces

Private workspace with Git integration When delivering business-critical content, each developer can also use their own, private workspace for development. In this scenario, a private workspace allows content creators to test content in the Fabric portal, or use features like scheduled refresh without risking disruption to others in the development team. Content creators can also develop content in the Fabric portal here, such as dataflows. Private workspaces can be a good choice when you are managing content changes by using Git integration together with Azure DevOps.

Alerts: You should set up alerts for when others add, remove, or modify critical files. Scope: Clearly define the scope of the remote storage location. Ideally, the scope of the remote storage location is identical to the scope of the downstream workspaces and apps that you use to deliver content to consumers. Access: You should set up access to the remote storage location by using a similar permissions model as you have set up for your deployment pipeline permissions and workspace roles. Content creators need access to the remote storage location. Documentation: Add text files to the remote storage location to describe the remote storage location and its purpose, ownership, access, and defined processes.

Fabric Git integration has some limitations with the supported items and scenarios. Ensure that you first validate whether Fabric Git integration best suits your specific scenario, or whether you should take a different approach to implement source control.

Use branches Content creators achieve collaboration by using a branching strategy. A branching strategy allows individual content creators to work in isolation in their local repository. When ready, they combine their changes as a single solution in the remote repository. Content creators should scope their work to branches by linking them to work items for specific developments, improvements, or bug fixes. Each content creator creates their own branch of the remote repository for their scope of work. Work done on their local solution is committed and pushed to a version of the branch in the remote repository with a descriptive commit message. A commit message describes the changes made in that commit.