In this post I want to cover naming conventions for Microsoft Fabric Git integration repositories and branches.
Because I think it is an important topic. Even more so after recent updates within Microsoft Fabric. Such as the ability select GitHub as a provider for Git integration. Which I have covered in various posts already. Including one about my initial tests for GitHub support.
Because you can end up working with a large number of repositories and branches. Like in the below example which utilizes four branches.
By the end of this post, you will know my proposed naming conventions for repositories and branches that are created as part of Microsoft Fabric Git integration.
Including one set of recommendations when working with feature workspaces and Microsoft Fabric deployment pipelines, and another for more complex or unknown scenarios. 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.
Naming conventions for Microsoft Fabric Git integration repositories
Even though workspace naming conventions have been discussed many times over the years, I will mention them briefly here. Because workspace naming conventions can go hand-in-hand when looking to implement Git integration.
However, my main advice relating to workspace naming conventions is to be brave and use abbreviations if required. Because there is functionality to help keep track of the workspaces that are created now.
Like in the below example that shows a detailed workspace description and a domain.
Anyway, the main reason I wanted to touch on workspace naming conventions is because I propose that you align your repository name with your workspace name. In order to keep it as simple as possible.
However, I also recommend removing any environment names in your repository. To avoid limiting yourself to an environment when you name your repository.
For example, in my previous post about my initial tests of GitHub support for Microsoft Fabric Git integration I created a workspace called “GHGIDev”. To represent the fact that it was a development workspace.
However, I named the repository “MicrosoftFabric-GHGI” and left out the “Dev” reference. As you can see below.
My rationale behind the naming convention was to first give it a prefix of MicrosoftFabric to name the source application. Followed by GHGI, which stands for GitHub Git integration.
I did not reference the “Dev” part of the workspace name there because when working with Git integration the same repository can support multiple workspaces that represent different environments by using different branches.
Main takeaway from this section is to implement a naming convention that does not limit your repository.
Naming convention for Microsoft Fabric Git integration branches
Another key point I want to cover is naming conventions for branches. Because these really should represent the different environments that you are working with. To clarify, when I say environments, I mean environments that your workspaces represent.
Such as the industry standard Development, Test, Acceptance and Production (DTAP) environments. Which are the most common environments you work with when working with multiple environments.
I want to provide recommended naming conventions for two groups of scenarios here.
However, if in doubt which scenario your branches will fall under my advice is to work with the first scenario which caters for a smaller number of branches to begin with and change if additional branches are required.
Branch naming convention when working with feature workspaces and a deployment pipeline
My first recommendations applies when you intend to work with workspaces that represent features and merging changes with a branch that will represent a development workspace that is used as the first workspace in a Microsoft Fabric deployment pipeline.
For example, a development workspace which will be used to deploy updates to test and production workspaces in a deployment pipeline. Which will definitely only ever be orchestrated by Microsoft Fabric deployment pipelines. Like in the below diagram.
You can read more about this scenario in detail in a Microsoft post that covers exploring CI/CD Capabilities in Microsoft Fabric. Which has a focus on Data Pipelines.
For this scenario I recommend the below naming conventions. Since it aligns with the GitHub flow branch strategy which is practiced by many DevOps professionals.
- Feature-x, where x can be either a number, work item code or even a name. As long as it indicates that it is a branch for a specific feature. Ideally, a short-term branch that can be removed once the feature has been completed.
- Main, which can be used by the development workspace since that will be the final branch you work with in Azure DevOps. From there, the rest of the deployments are managed by deployment pipelines.
Outside of Microsoft Fabric Git integration, I also recommend working with this naming convention when looking to perform CI/CD for Microsoft Fabric Data Warehouses.
Like I showed in my previous post on how to perform CI/CD for Microsoft Fabric Data Warehouses using YAML Pipelines within Azure DevOps. Since it will keep your branch strategy simple.
Branch naming conventions for more complex or unknown scenarios
I recommend a different set of naming conventions for more complex or unknown scenarios.
For example, when looking to work with Microsoft Fabric Git integration and multiple workspaces. Like in the below example shown in a recent post about GitHub security considerations. Which covers working with multiple branches.
For scenarios that require multiple branches to represent different environments or where the strategy is unknown, I propose the following naming conventions for branches to allow your repository to cater for multiple environments. Since they tend to align more with the popular Git flow branching strategy.
- Feature-x, where x can be either a number, work item code or even a name. As long as it indicates that it is a branch for a specific feature. Ideally, a short-term branch that can be removed once the feature has been completed.
- Dev or development to represent your development environment.
- Test for your Test environment.
- UAT/Acceptance/Staging for your acceptance environment. Reason I show a few variants is because the name can vary depending on your way of working.
- Main/Prod for your production environment. If you have one production environment convention suggests sticking with the main branch. However, for consistency you can create a prod branch instead. Taking it one step further, you can make the Prod branch the default branch for your repository.
Example of multiple for Microsoft Fabric Git integration workspaces and branches
Apart from maybe the feature branches, you do not need to name your branches the full workspace name. Especially if you align the prefix of your workspace with your repository name.
For example, the below list when working with sales information:
- Name of the Git repository: Sales
- Development workspace: Sales-dev
- Test workspace: Sales-test
- Acceptance workspace: Sales-acc
- Production workspace: Sales-prod
- Feature workspaces copied from development workspace: Sales-Feature-{unique identifier}
- Development branch: dev
- Test branch: test
- Acceptance branch: acc
- Production branch: prod
- Feature branch copied from development branch: Feature-{unique identifier}; where {unique identifier} is the same identifier used to identify the created workspace.
Main takeaways from this section are to align your branch names to your environment names and avoid naming the branch the full workspace name.
Final words
I hope my proposed naming conventions for Microsoft Fabric Git integration repositories and branches helps some of you.
Because a good naming convention can help. Especially when working with a large number of workspaces and branches.
Of course, if you have any comments or queries about this post feel free to reach out to me.
Be First to Comment