Prepare Azure DevOps for Microsoft Fabric Git integration

Reading Time: 7 minutes

In this post I want to cover how you can prepare Azure DevOps for Microsoft Fabric Git integration. To help you avoid any issues.

I want to stress that this post mainly focuses those of you who have created their own Microsoft Fabric environment. Specifically those who have created a Microsoft 365 Developer Account like I covered in a previous post.

However, some aspects I cover will apply to those who want to work with Azure DevOps and Microsoft Fabric together in other environments as well. For example, I cover how to initialize a Git repository properly.

In reality, I covered some aspects of this post in my other post about creating your own Microsoft Fabric environment. However, this post also contains additional material to help prepare Azure DevOps for Microsoft Fabric Git integration. Including the below:

• How to change an Azure DevOps organization owner.
• Setting up a Git repository in Azure Repos.
• Setting up Azure DevOps to run CI/CD pipelines.
• Advice about self-hosted Azure Pipelines agents.

Plus, this post contains plenty of links.

One key point to note is that Microsoft Fabric is now generally available. You can read more about this in detail in the official post by Ryan Majidimehr.

About Microsoft Fabric Git integration

To clarify, Microsoft Fabric Git integration allows you to synchronize supported items in a Microsoft Fabric workspace with a Git repository stored in Azure DevOps.

This gives you the flexibility to work with various items in multiple workspaces. For example, the code for a Power BI report can be stored in a Git repository and synchronized with one or more workspaces.

Below is a diagram to help visualize this.

At this moment in time, the supported items for Microsoft Fabric Git integration are Lakehouses, notebooks, reports, paginated reports and semantic models(datasets).

However, Amir Netz (t) from Microsoft has stated in a tweet that other artifacts will be able to support CI/CD in the future. Which hopefully means that more items will be supported for Git integration.

Joining an existing Azure DevOps organization

Anyway, if you have configured your own Microsoft Fabric environment by creating a Microsoft 365 Developer Account you have some interesting choices as far as Azure DevOps organizations are concerned.

Because you can either join an existing organization or create a new one.

When you setup the Microsoft 365 Developer Account the administrator account immediately has an Outlook mailbox configured.

You can see this for yourself by opening a new tab in the same browser session you run Microsoft Fabric in and going to the Outlook web site.

Because this account has a mailbox it can accept invites from other Azure DevOps organizations.

In order to send an invitation from another Azure DevOps organization the account needs to be added as a user to that organization first. Which is done by going to the Organization settings and selecting ‘Users’.

If you registered a Microsoft 365 Developer Account, then I recommend inviting the administrator account that you can see in your dashboard. Just to make your testing easier.

If you use join an existing organization, you can create a new repository and access its contents elsewhere. Plus, it won’t expire, unlike any organization you create with your Microsoft 365 developer account.

Creating your own Azure DevOps organization instead

However, you can also create your own Azure DevOps organization with the administrator account that got created instead.

You can do this through various methods. Including going to a new tab in the same browser as your open Fabric session and going to https://dev.azure.com/. From there you can complete the wizard.

Creating an Azure DevOps organization within the same tenant allows you to easily bind it to the Azure Active Directory tenant that gets created with the trial subscription. Like in the below example.

On the downside, once your 365 Developer trial is over you will not be able to access that Azure DevOps organization anymore. Unless you detach from that Active Directory and assign it a new owner.

You can change the owner by going to ‘Organization settings’ and then selecting ‘Overview’. Note that the new owner must exist in the organization beforehand.

From experience, I recommend waiting for around fifteen minutes for this change to take effect. To avoid any anomalies.

Setting up a Git repository for Git integration properly in Azure DevOps

In Microsoft Fabric you can configure Git integration at the workspace level by going into workspace settings.

As you can see in the Git integration screen above, you must specify a branch. Which means that the Git repository must already be initialized in Azure Repos. In other words, something must have already taken place in the repository and a branch must exist.

To clarify, Azure Repos is the service in Azure DevOps which stores the Git repositories.

If this is an existing repository that was synchronized from elsewhere then it is already initialized. However, if this is a brand-new repository that you are creating in Azure DevOps there are two simple ways to initialize it.

First option is to select the option to add a README file when you first create the repository in Azure Repos.

However, if you do not select this there is still another way to initialize it. By scrolling down to the bottom of your repository screen.

You can think of this option as a reprieve if you forget to do it the first time.

Preparing to run pipelines

In reality, there are some very good reasons why you might be considering running CI/CD pipelines in Azure DevOps.

Right now, you can run a pipeline in Azure DevOps to deploy schema updates to Microsoft Fabric Data Warehouse. Just like the method I showed in my other post about migrating dedicated SQL Pool objects to a Microsoft Fabric Data Warehouse.

In addition, you might be looking to future proof your Azure DevOps environment. So that if there are any future announcements relating to performing CI/CD through pipelines you are ready.

If you are using Azure DevOps in an existing organization there is a very good chance that you can run pipelines straight away already.

However, if you have created your own Azure DevOps organization like the example covered earlier it is not possible to run pipelines straight away. Due to the fact that Microsoft have temporarily disabled what is known as the free grant of parallel jobs in new organizations.

In other words, you do not get to use the free Microsoft-hosted agents immediately anymore. If this applies to you then there are two ways that you can get to run pipelines for free.

Fill out a form to use the free tier

First option is to fill out a Azure DevOps Parallelism Request form. You must then wait until Microsoft approves the request and provides you with a free tier so that you can run pipelines using a Microsoft-hosted agent.

You can read more about this in the Microsoft document on how to configure and pay for parallel jobs.

Create a self-hosted agent instead

Second option is to create a self-hosted Azure Pipelines agent instead.

If you do create your own agents, I recommend creating an Agent pool at the organization level and adding new self-agents there. Just in case you decide to experiment with multiple Azure DevOps projects.

I have used this option myself. Because it makes it easy to test newer versions of applications like SqlPackage.

However, there is nothing stopping you installing some of the latest software on a Microsoft-hosted agent whilst a pipeline is running. In fact, I covered how to do that for SqlPackage in a previous post.

Related posts

I previously published a post about post creating your own Microsoft Fabric environment. It covers how you can setup both Microsoft Fabric and Azure DevOps in your own personal environment. Based on a Microsoft 365 Developer account.

If you want to find out more about using it with the new Power BI projects I recommend my other post about initial Microsoft Fabric Git integration tests for Power BI Reports.

In addition, to see how you can work with branches and multiple workspaces I recommend my other post that covers Microsoft Fabric Git integration and multiple workspaces.

To get a better idea how you can work with Power BI projects to deploy to multiple workspaces in Microsoft Fabric I recommend reading the last two posts together.

Final words about preparing Azure DevOps for Microsoft Fabric Git integration

I hope this guide on how you can prepare Azure DevOps for Microsoft Fabric Git integration helps some of you.

Because I want to make sure everybody makes the most of their own Microsoft Fabric environment and my Azure DevOps background puts me in a good place to help with that.

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