Power BI

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.

You typically start the content lifecycle by performing BI solution planning. You gather requirements to understand and define the problem that your solution should address, and arrive at a solution design. During this planning and design stage, you make key decisions to prepare for the later stages.

Which item types do you expect to create, and how many of each? For instance, will you create data items like dataflows or semantic models, reporting items like reports or dashboards, or a combination of both? How is the content delivered to content consumers? For instance, will consumers use data items to build their own content, will they only view centralized reports, or a combination of both? How complex is the content? For instance, is it a small prototype, or a large semantic model that encompasses multiple business processes? Do you expect the scale, scope, and complexity of the content to grow over time? For instance, will the content encompass other regions or business areas in the future? How long do you expect the business to need this content? For instance, will this content support a key initiative of the business that has a finite timeline?

Using Semantic-Link-Labs to build the solution The good news is that Michael Kovalsky from elegantbi.com has created the Semantic-Link-Labs which allows this to be achieved using a Notebook. I first installed the Semantic-Link-Labs