In this post I want to share some things to consider when choosing Azure DevOps or GitHub for Microsoft Fabric Git integration.
Since you can now choose either Azure DevOps or GitHub as a provider for Git repositories. As shown in the below diagram.
I wanted to do this post since I get asked a lot whether people should choose Azure DevOps or GitHub. So, I want to highlight some key points when deciding which one to work with. Along the way I share plenty of links.
If you need help with any jargon used in this post, then I recommend that you read one my other posts. Which is a Microsoft Fabric Git integration jargon guide for Fabricators.
One thing I must stress is that the contents of this post are subject to change.
Azure DevOps and GitHub versions
Before I go any further, I want to point out that there are multiple versions of Azure DevOps and GitHub.
Azure DevOps has two main versions. Either the cloud-based Azure DevOps Services version or Azure DevOps Server. Azure DevOps Server is the version that you can install on your own servers.
At this moment in time, Microsoft Fabric Git integration only supports the cloud-based Azure DevOps services. Microsoft provides a guide that compares Azure DevOps Services and Azure DevOps Server.
GitHub has various plans available (also known as products). However, GitHub Enterprise is considered the most comparable to Azure DevOps. Due to its enterprise readiness.
It is no secret that GitHub Enterprise has become more popular over the years. Partly due to the introduction of new features such as GitHub Actions and GitHub Codespaces.
You can find more details about the various GitHub products in the Microsoft Learn module which serves as an introduction to GitHub’s products.
For now, the key point to be aware of is that Microsoft Fabric Git integration only supports cloud-based GitHub plans/products (also known as GitHub.com)
Similarity between Azure DevOps and GitHub
In reality, there is a lot of feature parity between Azure DevOps and GitHub.
For example, both can store Git repositories. Azure DevOps orchestrates deployments via Azure Pipelines whereas GitHub has GitHub Actions. Plus, Azure DevOps manages work items with Azure Boards whereas GitHub has GitHub Issues.
I could go on, but this is not a product comparison post. However, I will highlight the fact that it is perfectly feasible to work with both products together. For instance, you can manage work items in Azure Boards which are linked to GitHub repositories.
Plus, GitHub Advanced Security is now available in both offerings. Which I strongly recommend looking at.
With so many similarities it can be hard to decide. Which is why the next section highlights some key points to consider when choosing either Azure DevOps or GitHub for Microsoft Fabric Git integration.
Choosing Azure DevOps or GitHub for Microsoft Fabric Git integration
When choosing Azure DevOps or GitHub for Microsoft Fabric Git integration there are various factors to consider.
First thing to consider is if the cloud-based versions of Azure DevOps or GitHub are already established in the environment. If the answer is no, then various factors need to be considered before you make a choice.
For example, the familiarity of either product or the future vision. Because if the business is already planning to adopt GitHub it might not make sense to recommend Azure DevOps and vice versa. Unless there is strong business case to do so.
Plus, how both offerings are supported within Microsoft Fabric. Along with any other applications and services the product is intended for.
Another thing to consider is the culture of the company. Azure DevOps is a well-established product in the enterprise. Whereas GitHub is popular amongst the open-source community and the familiarity level is high.
However, GitHub is gaining popularity within enterprises.
Location of Azure DevOps and GitHub repositories when working with Microsoft Fabric Git integration
Another key factor is where you want your Git repository to reside. Because when you create an Azure DevOps organization you can decide which region your organization is created in.
Whereas when you create a GitHub repository in any of GitHub cloud-based offerings (often referred to as GitHub.com) they are stored in one or more servers worldwide for caching purposes.
As per the below statement by GitHub in the export overview section in the GitHub and Trade Controls page.
The cloud-hosted service offering available at GitHub.com has not been designed to host data subject to the ITAR and does not currently offer the ability to restrict repository access by country. If you are looking to collaborate on ITAR- or other export-controlled data, we recommend you consider GitHub Enterprise Server, GitHub’s on-premises offering.
Which is why at this moment in time the admin setting to allow users to export items to Git repositories in other geographical locations only applies to Azure DevOps.
You can look to provide various workarounds. Like potentially allow access to repositories stored in GitHub Enterprise Server. However, that introduces both complexity and risk.
Governance
Another point I want to make when choosing between Azure DevOps or GitHub is about governance. When you work with Azure DevOps services you get a lot of enterprise ready governance settings in-place. Which you can configure further with additional settings.
To get the same level of governance settings with GitHub you ideally should be looking to work with either GitHub Team or GitHub Enterprise Cloud.
Ideally the latter. Because as much as I appreciate the fact that we can test Git integration with GitHub repositories created in personal accounts for individuals I believe that GitHub Enterprise is so much better from a governance perspective.
Authentication
Another factor to consider when choosing between Azure DevOps or GitHub for Microsoft Fabric Git integration is authentication.
When you select Azure DevOps as a Git provider you authenticate with your Microsoft Entra user account. Whereas you currently can only authenticate to GitHub repositories using personal access tokens.
I personally believe it is far easier to manage authentication with Microsoft Entra ID (formerly Azure AD) accounts than personal access tokens. Plus, it is my personal belief that managing access via user accounts is more secure than relying on secure storage of personal access tokens.
Sure, authenticating with personal access tokens makes it a lot easier for cross-tenant scenarios. Which is great for simple scenarios with a small number of users and branches.
However, for more complex scenarios multiple personal access tokens may need to be created and managed. Like the one in the below diagram from my post about security considerations.
Plus, when working with a strategy that requires multiple people to create personal access tokens you must be comfortable with them creating their own personal access tokens.
Fortunately, the personal access token will also work if they look to branch out to a new workspace. So, no need for them to create a new personal access token for each branch.
However, you must be confident that they will save the personal access tokens somewhere secure instead of keeping them in notepad.
Personally, I hope that eventually GitHub support for Microsoft Fabric Git integration will include the ability to support Microsoft Entra ID accounts.
Even if it means connecting your Git repository to an application. Like you must do when connecting to a GitHub organization in Azure Synapse Analytics.
Final words about choosing Azure DevOps or GitHub for Microsoft Fabric Git integration
I hope this post about choosing Azure DevOps or GitHub for Microsoft Fabric Git integration helps some of you decide which to work with.
Because I think that it is important to know the points in this post before you make a decision. Especially if choosing for a greenfield environment.
Of course, if you have any comments or queries feel free to reach out to me. Plus, those of you attending the European Microsoft Fabric Community Conference are more than welcome to discuss this post with me there.
Hi Kevin. First thanks for all your contributions to us fabricators. I am in the middle of setting up a more advanced solution in fabric involving many workspaces and metadata driven architecture. The reason behind is security. The data is highly sensitive so separating the lakehouses into their own workspace makes security demands a bit easier. In this articke you mention that devops has the possibility to choose regions. That is a must for my customer. Thanks for that clarity. But my customer has separate tenants for devops and fabric which puts me into a problem. I can’t reach the devops project from fabric. I have two different users for each part. The reason for this may be an issue alone but how to solve this? Adding the devops user as a guest user in the tenant where fabric is? can that solve this?
In my architecture we can end up in 6 to 10 workspaces (dev,test,prod with their bronze, silver and gold layer with lakehouses). It may be possible to join bronze and silver reducing the number of workspaces.
The next part is how to put all things in GIT. I believe I need separate folders for bronze, silver and gold with separate git connections. Developing in this Bronze Dev must be connected to Git/devops, the same Silver Dev and so on. There must be 3 separate deployment pipelines one for each layer, but there may be a stressful manage process to keep everything in order. In devops pipelines I guess you can solve this better
Thinking otherwise so will the development mainly be developing data factory pipelines and notebooks. Having that in a workspace could be a way of solving this. The bronze to gold workspaces would be data stores and more clean.
the metadata driven process needs of course to be parameterized. Both notebooks and copy activities has now the possibility to add parameter for connections, lakehouses and more.
Puh, this was much I know. Hope to have a comment of my thoughs and hopefully some good advices from a very experienced contributor.