Press "Enter" to skip to content

Category: Source Control

Multiple Workspaces and Microsoft Fabric Git Integration

Kevin Chant can’t stop at one:

In this post I want to cover working with Microsoft Fabric Git integration and multiple workspaces. By highlighting one method that you can use in the real-world.

I must admit that I have been very keen to test this particular way of working with Microsoft Fabric Git integration and multiple workspaces.

By the end of this post, you will know one way that you can work with Microsoft Fabric Git integration and multiple workspaces. Based on real-world working practices. Including multiple branches and pull requests.

Click through to see what Kevin has in mind usingg Azure DevOps.

Comments closed

Git Integration for Power BI Reports in Microsoft Fabric

Kevin Chant gives GIt integration a try:

To manage expectations, this post covers:

  1. Brief overview of Microsoft Fabric Git integration.
  2. How I converted a Power BI report to a Power BI Desktop project containing metadata files.
  3. Converting the folder that contains the Desktop project into a Git repository.
  4. Synchronizing the Git repository with Azure DevOps.
  5. Setting up Microsoft Fabric Git integration.
  6. Initial tests.
  7. Interesting workaround to deploy a second Power BI report using metadata.

Read on for Kevin’s thoughts.

Comments closed

Power BI: Git Integration vs Deployment Pipelines

Marc Lelijveld notes a chemical reaction:

Together with the introduction of Microsoft Fabric a long-awaited feature for Power BI also became available. Git integration now allows us to connect your workspace to a git repository to sync the meta data from your Power BI dataset and report between the workspace and the repository.

At the same time, Power BI deployment pipelines are around. The pipelines help you to move content between workspaces from Development to Test and finally to Production. The question that arises, when to use what? And how do they complement each other, or maybe even clash with each other?

Read on for Marc’s thoughts across these two topics.

Comments closed

Power BI Report Deployment with Connections to Shared Datasets

Rayis Imayev does some large-scale deployment:

Let’s say you have a collection of Power BI .pbix files stored in a git-based source control system (GitHub, Azure DevOps, or any other system). Among these files, one is your data model, while the others are Power BI visual reports and dashboards connected to the published dataset from your data model. Your published dataset is located in a separate workspace dedicated to shared content, and the visualization Power BI reports are placed in another workspace with appropriate permissions to access them.

Now, let’s consider an additional complexity: you have this collection of files not only in one development environment but also in two others. These environments support your Power BI reporting testing (UAT) and the release of your Power BI reports to end-users (Production).

The questions that arise are: How do you deploy your solution, and most importantly, how do you automate it?

Click through for an architectural diagram, as well as the answer to this question.

Comments closed

Power BI Projects and Git Review

Teo Lachev wants to wait:

But to digress from Fabric, let’s take a look at two developer-oriented and frequently requested features that fortunately doesn’t require Fabric: Power BI Desktop projects and workspace integration with Git. The video in the link is a good starting point to understand how these features work.

Basically, the first feature lets you save a Power BI Desktop file as a *.pbip file which generates a set of folders with human-readable text files, such as the model.bim file (has the model definition described in JSON). Next, you can put these files under source control both in Power BI Desktop using any source-code enabled tool, such as Visual Studio Code or Visual Studio. Currently in preview, Power BI projects is an experimental feature (in fact, the Publish button is disabled so you can’t publish a project to Power BI Service).

Click through for Teo’s thoughts. This is something that I wish had been done 8 years ago, and as Teo points out, there’s still room to grow. But I do consider it a step forward from only being able to save PBIX files.

Comments closed

Creating an Azure DevOps YAML Pipeline for SQL Server Deploys

Oilivier Van Steenlandt updates to the new Azure DevOps model:

In one of my previous blog posts, I used the SQL Server database deploy task to deploy my DACPAC to SQL Server. Unfortunately, this task became deprecated in Release Pipelines. In this blog post, I would like to share the alternative.

Additionally, we will be moving from a Classic Release pipeline to a YAML pipeline. The YAML pipeline will be responsible for building and deploying our Database Projects.

Click through for the walkthrough.

Comments closed

The Importance of the New Power BI Project

Paul Turley lays out an explanation:

Back in December, I posted this short article about how Power BI can participate in Continuous Integration & Continuous Deployment (CI/CD), from simplified code sharing and version control all the way up to fully-automated Build automation & deployment scenarios. However, since the product inception, there have been significant challenges in orchestrating versioning and code sharing with a single PBIX file. Achieving DevOps and CI/CD was possible but it required creative work-arounds and manual steps. In April of this year, Nathan Hales contributed this post, showing how to use Tabular Editor to manually decompose a PBIX file into a Model.bim and then create a Git repo and Azure DevOps project.

Although the essential pattern is the same, the need for manual steps and work-arounds is eliminated with this new feature release!

This is really good news, and Paul shows you how to enable the feature (currently in preview) and use it.

Comments closed

Thoughts on Postgres File Layout and Migration

Dian Fay shares some advice:

I’ve used several migration frameworks in my time. Most have been variations on a common theme dating back lo these past fifteen-twenty years: an ordered directory of SQL scripts with an in-database registry table recording those which have been executed. The good ones checksum each script and validate them every run to make sure nobody’s trying to change the old files out from under you. But I’ve run into three so far, and used two in production, that do something different. Each revolves around a central idea that sets it apart and makes developing and deploying changes easier, faster, or better-organized than its competition — provided you’re able to work within the assumptions and constraints that idea implies.

Read on for thoughts about three tools: sqitch, graphile-migrate, and migra.

Comments closed

Source Control and Change Management for Postgres

Ryan Booz relives an older story:

For those of you that don’t know, those ER tools were really expensive (probably still are for the ones that exist) and only a few developers had access to the tool. They didn’t have a great DX either.

Aside from the lack of automation and ability of our developers to be more integrated into the process, there was always the one looming issue that we just couldn’t reconcile.

If Joe left and joined the circus (see, I got you there), we were stuck.

We knew this was a bottleneck for some time and we had tried multiple times to change the process. Our ability to iterate on new feature development went through one person and a set of 15-year-old scripts. It didn’t match our otherwise Agile process of front-end code and data analysis projects.

Read on for Ryan’s thoughts on database change management. Some of the tools mentioned work with multiple database platforms, whereas others are specific to Postgres.

Comments closed

Feature Branching and Hotfixes for Azure DevOps

Vytas Suopys covers a bit of source control strategy:

Have you ever deployed a release to production only to find out a bug has escaped your testing process and now users are being severely impacted? In this post, I’ll discuss how to deploy a fix from your development Synapse Workspace into a production Synapse Workspace without adversely affecting ongoing development projects.

This example uses Azure DevOps for CICD along with a Synapse extension for Azure DevOps: Synapse Workspace Deployment. In this example, I assume Synapse is already configured for source control with Azure DevOps Git and Build and Release pipelines are already defined in Azure DevOps. Instructions on how to apply this this can be found in the Azure Synapse documentation for continuous integration and delivery.

The specific example covers Synapse, though the general principle applies no matter what you’re deploying.

Comments closed