This post is a back-to-basics guide that shows three approaches to preparing a Git repository for Microsoft Fabric Git integration. In other words, prepare a repository in either Azure DevOps or GitHub in order to connect it to a Microsoft Fabric workspace.
To manage expectations, this post is aimed at those with little or no experience with preparing a Git repository for Microsoft Fabric Git integration. However, those with experience can learn things in this post. Because it lays the foundation for various topics and contains various links.
One main reason for this post is to highlight that Microsoft Fabric Git integration will only work with a Git repository that is initialized. If you create a Git repository and do not initialize it, it will not be an option when trying to configure Microsoft Fabric Git integration.
Another reason is because it is a natural follow-up to my Git introduction post.
Microsoft Fabric Git integration is essential when considering to implement CI/CD with either Azure Pipelines in Azure DevOps or a GitHub Actions workflow. Because the contents of the Git repository are the source for your deployments.
All the examples in this post are based on Azure DevOps. However, the same concepts can be applied to GitHub as well. You can read my other post that is a Git introduction for Microsoft Fabric enthusiasts to get a better understanding of Git beforehand.
Approach 1: Create and initialize in Azure DevOps
First approach is to create and initialize the Git repository directly in Azure DevOps. You can do this either manually or through APIs. When doing it manually you can initialize the repository by selecting add a README file.
You can remove the README file once there are more files in your Git repository if you so wish. However, if you intend to perform CI/CD with the repository I recommend keeping the README file. So that you can document your solution for others.
This approach lets you quickly get started with Microsoft Fabric Git integration. Because you can quickly create the Git repository and then configure Microsoft Fabric Git integration in a Microsoft Fabric workspace.
If you do this approach, I do strongly recommend you specify that your items will be stored in a workspace subfolder when you configure Microsoft Fabric Git integration. In case you expand the needs of your Git repository. For example, to setup the Git repository as a source for a YAML pipeline in Azure DevOps.
This is very effective for single workspace setup. However, you can take it one step further and create separate Git folders for workspaces that are connected together in the same repository. This is feasible if looking to perform updates on connected workspaces that require the same development lifecycle.
Multiple-workspace example
For example, workspaces a and b are in a development environment and connected to a development branch. Workspace a has a new item added and workspace b has a new report added that points to that new item. Both perform a commit in the development branch.
From there those updates can be deployed to the counterparts of workspaces a and b in the test environment simultaneously.
Just bear in mind that adding multiple workspaces as subfolders within the same branch of a Git repository creates dependencies between those workspaces. In addition, it can increase manageability and will increase your Git commit history.
However, this method still caters for multiple deployment methods. Especially those orchestrated by Azure DevOps or GitHub.
To summarize, this is ideal for connected workspaces that require the same development lifecycle. For workspaces that can be updated in isolation one Git repository per workspace can be more optimal.
Approach 2: Create in Azure DevOps and push
Second approach is to create the Git repository in Azure DevOps without initializing it. From there you can push the contents of an existing Git repository to it.
One thing I like about Azure Devops is that when you create a Git repository without initializing it Azure Devops still provides various options to initialize it.
For example, you can perform the below steps to populate the repository from your local machine:
- Create new Git repository in Azure DevOps.
- Create and/or initialize new Git repository locally.
- Add the Git repository in Azure DevOps as a remote locally.
- Push your changes to the remote repository in Azure DevOps.
- Refresh your screen in Azure DevOps to see the Git repository populated.
When looking to do this with Microsoft Fabric Git integration I recommend working with an application such as Visual Studio Code. Because it simplifies performing common tasks such as adding and removing remote repositories.
Doing this approach is ideal if you intend to work with files locally.
For example, when working with locally created Power BI Desktop Projects that you want synchronized into Fabric workspaces. Alternatively, you tested a deployment method you downloaded locally and now you want to test it within Azure DevOps or GitHub.
Another advantage of this method is that it allows you to organize your folder structure cleaner without the need to create a README file.
However, like I mentioned earlier if you intend to perform CI/CD with the repository you should keep the README file. So that you can update it with details relating to the deployment method of choice. This is especially true if you work with a solution such as fabric-cicd.
Approach 3: Import a Git repository for Microsoft Fabric Git integration
Final approach is to import a repository. Azure DevOps makes this easy to perform. Providing you can access the source repository. In fact, it does not even need to be a repository of the same name.
For example, say that I created the SuperDemo repository shown previously. I can then click on import and select my ADO-fabric-cicd-sample repository. As you can see below, the import worked even though the original repository has a different name.
As you can see, this repository already has a workspace folder which contains Fabric items. So I can connect it to a workspace with Microsoft Fabric Git integration and then select for items to sync with the workspace.
Doing this approach is ideal when you need to copy an existing repository. Whether it is to duplicate the items quickly or to test a solution like the one offered in my ADO-fabric-cicd-sample repository.
Which contains various YAML pipelines for fabric-cicd deployments, all of which you can select and customize in Azure Pipelines. As covered in my previous post on how to operationalize fabric-cicd to work with Microsoft Fabric and YAML Pipelines.
One thing to note is that an import is not the same as a fork. Imported repositories are independent and do not link to the source repository.
Final words about preparing a Git repository for Microsoft Fabric Git integration
Now that you know these three approaches you can decide which suits your requirements. Because there are benefits to all three and knowing which to apply can help with your CI/CD story.
For those of you looking at an efficient way to populate the README file, I strongly recommend GitHub Copilot. Either natively in GitHub or locally with GitHub Copilot in Visual Studio Code.
1 thought on “Three approaches to preparing a Git repository for Microsoft Fabric Git integration”