Git Repository Structure and Metadata Management with UDE
Git Repository Structure and Metadata Management with UDE
Introduction
In the previous parts of the series, we created our UDE environment, installed the required tools, configured Visual Studio, and completed our first X++ development.
Up to this point, we have focused mostly on getting the development environment up and running. In a real project, however, writing the code is only one part of the job. How the code will be shared within the team, which change was made by whom, how to return to an older version when necessary, and which source the build process will use are at least as important as development itself.
This is exactly where Git and the Azure DevOps Repository structure come into play.
Using Git is also particularly important on the UDE side. This is because custom metadata now resides on our local machine, and multiple developers can connect to the same UDE environment. Therefore, the source code needs to be kept in a single, traceable reference.
In this article, we will mainly look at the following topics:
- Where custom metadata should be stored within the repository
- How the repository folder structure can be designed
- The approach to metadata, Visual Studio projects, build files, and .gitignore
- Branch structure options based on the size of the project
- The Pull Request, branch policy, and hotfix approach
- A developer’s daily Git workflow and metadata conflicts
The Metadata Approach That Changes with UDE
In classic Dynamics 365 Finance & Operations development VMs, Microsoft standard metadata and the custom metadata we developed were stored under the same PackagesLocalDirectory structure.
For example, the folder we had been accustomed to seeing for years was:
Inside this folder, Microsoft packages, ISV solutions, and our custom models could exist side by side.
With UDE, this distinction becomes much clearer.
In the metadata configuration in Visual Studio, we define two separate locations:
- Folder for your own custom metadata
- Folders for reference metadata
The first field points to the folder containing the X++ models we develop ourselves, while the second field points to Microsoft standard metadata and, if applicable, other reference models.
In my opinion, this separation is one of the most useful aspects of UDE.
In practice, it provides us with the following advantages:
- Microsoft standard metadata does not become part of the repository.
- We can limit the repository to only our custom code and project files.
- Switching branches and synchronizing code becomes cleaner.
- Microsoft updates and custom code are separated from each other more clearly.
- Which files the build pipeline will use becomes more controlled.
The basic rule I use here is:
Recommended Local Folder Structure
In the previous parts, we used the following folder for custom metadata:
