Skip to content

Initial tests of Git integration support for Microsoft Fabric Data Warehouses

Reading Time: 4 minutes

In this post I want to share the results of my initial tests of Git integration support for Microsoft Fabric Data Warehouses.

Since I noticed that is was available in a Microsoft Fabric workspace where Git integration is configured when I returned from Data Point Prague this weekend.

By the end of this post, you will see the results of my initial tests. Along the way I share plenty of links.

If you need help with any jargon used in this post, you can read my other post. Which is a Microsoft Fabric Git integration jargon guide for Fabricators.

One key point I want to highlight is that Microsoft Fabric Git integration is currently in preview and the contents of this post are subject to change.

Git integration support

I first noticed that Git integration is now supported for Data Warehouses when went into a workspace where I had previously deployed a Data Warehouse and configured Git integration.

Due to the fact that the Git status for the Data Warehouse was uncommitted. Instead of the previous state of unsupported.

Data Warehouse showing Uncommitted instead of Unsupported
Data Warehouse showing Uncommitted instead of Unsupported

In addition, there was a notification in Source control. So, I clicked on it and committed the change.

Performing initial commit of the Microsoft Fabric Data Warehouse
Performing initial commit of the Data Warehouse

Which highlights one key point I want to make about good working practices.

When you are working in a workspace that has Git integration I recommend writing good commit messages. Especially for workspaces you share with colleagues.

In addition, make sure you commit as often as possible. So that the entire team can see all the updates easier.

Viewing the Git integration support in Azure DevOps

Once I had committed the change, I then went into the Azure DevOps Git repository that is connected to the workspace.

I then expanded the Warehouse subfolder in root of the repository. In order to view the contents as below.

Viewing the metadata for the Warehouse in Azure DevOps
Viewing the metadata for the Warehouse in Azure DevOps

There is a good reason why some of the files may look familiar to some of you. It is due to the fact that some of these files are recognizably part of a Database Project.

Which I have covered in various posts. With the most recent one being about how to download a Microsoft Fabric Data Warehouse database project to perform CI/CD using Azure DevOps.

In fact, when I compared this to the zip file that I downloaded in that post only one file is different. Which is the “.platform” file that is part of Git integration. Which contains the below metadata/code.

{
  "$schema": "https://developer.microsoft.com/json-schemas/fabric/gitIntegration/platformProperties/2.0.0/schema.json",
  "metadata": {
    "type": "Warehouse",
    "displayName": "CICDDemoDW"
  },
  "config": {
    "version": "2.0",
    "logicalId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
  }
}

To confirm that it is a working database project, I cloned it locally and opened it in Azure Data Studio. I then confirmed that I could open up the database project for the Data Warehouse in Azure Data Studio.

Viewing the database project in Azure Data Studio whilst performing initial tests of Git integration support for Microsoft Fabric Data Warehouses
Viewing the database project in Azure Data Studio

Adding new table to test of Git integration support for Microsoft Fabric Data Warehouses

I then tested that I could update the Data Warehouse with the local copy of the database project via Git integration. First, I checked out the dev branch in Azure Data Studio. Which is the branch the workspace has been configured to work with within Git integration.

I then created a new table and copied a schema from an existing table into it.

Afterwards, I then saved the database project in Azure Data Studio. From there, I went into source control and committed the change to the local Git repository. Azure Data Studio then prompted me to synchronize the change with the repository in Azure DevOps.

I then went into Microsoft Fabric to approve the update. Afterwards, I went into the Warehouse Editor and verified that the schema for new table was there.

New table in the Data Warehouse whilst performing initial tests of Git integration support for Microsoft Fabric Data Warehouses
New table in the Data Warehouse

Which confirms that there is now another way to get a Data Warehouse updated in Microsoft Fabric after updating local database project. In addition to the other method that I covered in another post about performing CI/CD for Microsoft Fabric Data Warehouses using YAML Pipelines.

Plus, this method aligns closer with the way that you can update Power BI reports based on a local Power BI project.

Git integration tests for multiple workspaces and deployment pipelines

However, I must admit that when I tested updating Data Warehouses by following the steps I covered in my post about working with Microsoft Fabric Git integration and multiple workspaces I encountered some issues.

Due to the fact that I get an error about a Datamart not being found. However, I did discover a workaround for this by waiting a few minutes and then disconnecting the second workspace from Git.

Afterwards, I connected to the same branch again and when prompted select the option to sync content from Git. Which resolved the issue.

Option to sync content from Git

I also tested deployment pipelines, which worked fine.

Final words about my initial tests of Git integration support for Microsoft Fabric Data Warehouses

I hope that my coverage about my initial tests of Git integration support for Microsoft Fabric Data Warehouses has made for an interesting read.

Personally, I am glad that Data Warehouse support for Microsoft Fabric Git integration has finally become available.

Of course, if you have any comments or queries about this post feel free to reach out to me.

Published inAzure DevOpsMicrosoft Fabric

4 Comments

  1. Hi Kevin,

    I have some scripts that insert metadata into a table. In SSDT, I can set those to “do not build” and include them in a post-deployment script. I can pretty much do the same in Azure Data Studio, but I cannot find the do not build property, so the build fails. Any ideas?

  2. Thanks for the link!
    The build still fails (which means the .sql file is still included in the build process), saying the script cannot contain multiple statements per batch.

    This seems very different than SSDT, where you can exclude scripts from the build and it doesn’t complain about multiple statements in the post deployment scripts.

  3. “Working database project” seems to be a bit of a stretch. CREATE SCHEMA scripts are not included. Trying to build the project in Azure Data Studio fails (without an error being logged). There’s still a long road ahead of us…

Leave a Reply

Your email address will not be published. Required fields are marked *