Blog |

Finance and Supply Chain Management

GIT and Dynamics 365 Finance & Supply Chain Management: How to Use Code Repositories in the Most Efficient Way (Part 1)

Friday, February 24, 2023
Reading time: 7 minutes

In recent years, the development and Application Lifecycle Management (ALM) experience for Microsoft Dynamics 365 Finance & Supply Chain Management (also known as Finance & Operations) has vastly evolved. While Azure DevOps and VSTS are popular options, GIT source control is an even better choice. Although GIT source control is not commonly used, we find it is superior to the other options in certain areas, such as code sharing and storage for multiple developers.

In this blog series, we’ll share how to use GIT with Dynamics 365 Finance & Supply Chain Management, starting with the basics and diving deeper into the main benefits. In addition, we’ll share pro tips on how to make ALM easy for Dynamics 365 Finance & Supply Chain Management solutions with GIT.

Common Misconceptions

There are a few common misconceptions about GIT for Dynamics 365 to reveal:

  • GIT is not recommended by Microsoft. This is a fair point, but while not being officially recommended and supported by Microsoft, Microsoft gives you all the tools needed to successfully work with GIT, including build and release pipeline templates for GIT and setup instructions.
  • GIT is cumbersome with Dynamics 365 Finance & Supply Chain Management. I have seen examples where it can really become cumbersome, but I’m sharing tips later in this blog on how to configure it and use it to its full potential more easily.
  • GIT is not properly integrated with Visual Studio for Dynamics 365. In earlier versions this is true, but since the release of Visual Studio 2019, GIT works perfectly in Visual Studio.

Despite these misconceptions about GIT for Dynamics 365, it is a powerful tool when properly configured and utilized. I’m here to prove it to you.

GIT Pros over Visual Studio Team Services (VSTS)

Let’s discuss what makes GIT better than VSTS.

First, you usually get easier merging. The key to easier merging is cherry-picking. This is due to the principles of how its source control works.

Second, GIT provides a clear branching strategy to easily maintain feature, master and release branches, and simply switch between them locally. Last, GIT is receiving significant investment from Microsoft.VSTS is considered a complete feature, so Microsoft has now shifted its attention and funds to GIT.

Getting Started with GIT for Dynamics 365 Finance & Supply Chain Management

Before getting into the set-up process, let’s have a quick look at the prerequisites needed to get started with GIT for Dynamics 365 Finance & Supply Chain Management:

  • Azure DevOps project where everything related to your implementation lives (tasks, code, and test scenarios).
  • Access to GIT repository in Azure DevOps project for all developers that will be working on the project.
  • At least one branch (it can be empty) where you will be starting to work (main branch or master branch).
  • Configured Visual Studio.

Visual Studio Configuration

Configuring Visual Studio and your local machine is quite easy. You need to create a local repository folder (i.e C:\DevOps) and map GIT local repository to it. You should not map GIT to the PackagesLocalDirectory as it would make switching branches cumbersome.

To map the repository, you first need to create the folder where the repository will live and then when you have the folder ready, you just open Visual Studio, select that you want to connect to the GIT repository, and map it to the local folder. In that way, the code will be cloned locally.

Pro tips:

  • Do not connect Git to PackagesLocalDirectory folder
  • Use symbolic links from C:\DevOps to PackagesLocalDirectory to link x++ source code

Mega pro tip: use PowerShell script to create and remove symbolic links to make switching branches easy.

gitignore Configuration

Properly configuring .gitignore can help maintain the cleanliness and organization of a GIT repository. When setting up .gitignore, it’s important to include files and directories that are specific to the local environment, such as:

  • X++ model directories, code only
  • Descriptor files for models
  • Reference .dlls
  • Complete directories for add-on packages (ISVs)

.gitignore Hacks

Standard .gitignore logic does not work as expected – that’s what we have learned the hard way. We put together a blog post where we explain how to make .gitignore work for Dynamics 365.

There are few principles to follow in order to make .gitignore work:

  • In the root level file, ignore all except desired model directory – this will leave Xref and .dlls excluded.
  • In the model directory, add a second .gitignore.
  • In the second .gitignore, ignore all except the x++ directory – this will skip bin directory for the model.

As you have GIT configured on your local machine, you can start building code and it will be detected automatically. You don’t need to add something to source control like you do in VSTS style source control.

Branching Strategies

Let’s say that you start coding, and everybody is working on the master branch. There is no immediate impact on the project; however, as the project gets bigger, it becomes inconvenient for everyone to work on a single branch. Thankfully, there are some good branching strategies that are available and are easy to implement with GIT.

Here are some recommendations for your branching strategy:

  • Main/master branch to hold all the code base
  • Isolated release branches for user acceptance and the production environments
    • These are the clean branches where stuff that’s ready to release goes in, and you need them to be isolated to keep code under control.
  • Developers should be able to work on the code base parts simultaneously with as little discomfort as possible.

Recommended Strategy – GitFlow

Over the years we have found that GitFlow strategy works best for Dynamics 365 projects. This strategy basically consists of a few branches: master, feature, and release.

Benefits of GitFlow:

  • Uses master branch as a central repository.
  • Feature branches enable developers to work separately from the master branch.
  • Features are merged into the master once complete, maintaining the common code base.
  • Dedicated branches for acceptance testing and production environments.

But how can you implement this strategy and use those branches? Let’s take a look at each branch separately:

1. Master Branch

The master branch contains all the code that is ready for testing, but is generally not yet fully tested. It is deployed to an integration testing environment for unit testing. The master branch has an ongoing lifecycle as it contains all code and is constantly growing. It’s important to highlight that all merges into it should be done using pull requests.

2. Feature Branches

Feature branches are dedicated to every feature that the developer is working on. They always start as a copy of the master branch and then modifications are added on top. Once complete, these feature branches should be merged into the master and can be deleted All the necessary code should now be in the master branch.

You should use pull requests (PR) to merge into the main branch to enable:

  • Code review process – PR should be completed by code reviewer.
  • Code traceability – PR should be linked to respective work item.
    • Linking PR to work item will automatically link all commits, builds and releases to work item.

3. Release Branches

We have dedicated branches for every environment. Usually, it’s User Acceptance Testing (UAT) for user acceptance and PROD for the production environment. There can be two strategies:

  1. You can have a single branch per environment with an infinite lifespan. Therefore, every time you’re making a release, you just push changes into the respective branch, make a new build and then release the new package to desired environment.
  2. Another strategy is to have a release dedicated to short-lived branches (like UAT_release_20221124). In this case, you make a copy of the latest branch and add features to this copy. This enables easier traceability of when and what feature was released to the desired environment.

This picture describes the purpose of commonly used released branches the best:

In this first installment of our blog series, we briefly described GIT basics and initial configuration for Dynamics 365 Finance & Supply Chain Management to help you get started with GIT.

Read part two of this blog series on GIT with Dynamics 365 Finance & Supply Chain Management where we focus on best practices utilizing GIT and related tools for Dynamics 365 Finance & Supply Chain Management application lifecycle management (ALM).

Still have questions? Don’t hesitate to contact us via service@companial.com

Paulius Brezgys
Latest posts by Paulius Brezgys (see all)

Meer over Finance and Supply Chain Management

Anaxco

Navigating the Dynamics 365 Transition: Anaxco's Journey to Operational Excellence with Companial's Support

Meer lezen