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 2)

Friday February 24, 2023
Reading time: 6 minutes

In the previous blog on GIT and Dynamics 365 Finance & Supply Chain Management , we briefly described GIT basics and initial configuration for Dynamics 365 Finance & Supply Chain Management to help you get started with GIT. Once you have source control set up and you can push code into Azure DevOps, there is so much more that can be done with your code.

In part two of GIT for Dynamics 365 Finance & Supply Chain Management series, we’ll focus on best practices utilizing GIT and related tools for Dynamics 365 Finance & Supply Chain Management application lifecycle management (ALM).

Dynamics 365 Finance & Supply Chain Management Application Lifecycle with GIT

With Visual Studio setup and coding done on feature branches merged into the main branch, we can release code to other environments by downloading and preparing packages locally and then applying it to the Dynamics 365 environment. But what if you can take this process to the next level? What if you can automate builds and releases or even enforce code review using GIT? I’ll share some tips on how to make the best out of GIT.

Application Lifecycle Requirements for Dynamics 365 Finance & Supply Chain Management

The application lifecycle requirements include:

  • Code documentation and traceability (what code belongs to which item).
  • An enforced code review process.
  • Automated builds to validate code integrity outside developer’s environment.
  • An easy code release process between environments.
  • An automated release process to testing and pre-production environments.

By implementing these application lifecycle requirements, you can ensure the success of automated builds and releases.

How to Achieve Code Documentation with GIT

To achieve code documentation with GIT, you should take the following tips into account:

  • Use feature branches for every feature.
    • Avoid working on the master branch because that code will not be connected to work item and will not be documented.
  • Each code committed to the feature branch should have a meaningful name and ideallythe work item number listed.
  • Use pull requests to merge feature branches into the master (pull requests will create a link between commits into the master branch and work items).
  • Use pull requests to enforce the code review process.
    • No changes should go into the master directly.
  • Pull requests should be only completed by the lead developers that review the code being pushed.

Automated Build Options for Dynamics 365

There are two options to build code with Dynamics 365 – Azure hosted build and build virtual machines (VM). Following are some features of each:

Manual testing Automated testing
  • Fast build that is run on Azure hosted pipelines, no dedicated environment needed
  • Validates X++ code integrity and add-on packages for compile errors and version compatibility.
  • Produces all-in-one packages.
  • Does not validate data structure integrity.
  • Allows multiple Finance & Supply Chain Management platform versions to be used for different branches.
  • Requires dedicated cloud-hosted VM.
  • Single version usually, one build VM for all branches.
  • Validates X++ code, add-ons, and database schema.
  • Produces all-in-one packages.
  • Can run automated testing after each build.

From our experience, an Azure-hosted build is easier to maintain a solution compared to build virtual machine. The only advantage of build virtual machine is that it allows you to check for database synchronization errors. How useful is that? Working with Git source control and with the hosted builds for a few years already, we have had only a handful releases failing because of data structure errors – errors with data structure are not common. My advice would be to use Azure-hosted builds because it’s just easier to set up and maintain and it runs way faster than build virtual machines. On top of that, it has a smaller cost impact on the project budget.

How to Set Up Automated Build Pipelines

The process of setting up automated build pipelines is usually quite clear and there are great examples provided by Microsoft on GitHub and Microsoft learn.

What needs to be considered before setting up the pipelines is that each release branch should have a dedicated build pipeline: one for TEST environment package, one for User Acceptance Testing (UAT) and one for production or for live environment.

Here are some pro tips that Microsoft doesn’t tell you about:

  • Set up automatic triggers on every release branch to run build with every commit to validate code.
  • Use different naming for each branch’s yaml files to dedicate a pipeline for the desired branch and help setting up build triggers.

How to Set Up Automated Release Pipelines

To set up automated release pipelines, you could download the package and upload it manually but that’s cumbersome, so why not automate the process? Luckily, there’s also a way to automate the release pipeline. It can be done by creating a trigger based on the build pipeline output and it automatically releases the built code. The release pipeline tasks are simple and consist of three major steps:

  • Authentication. Deployment pipeline must always authenticate against Lifecycle Services (LCS) Project. For this action, the pipeline must have a task that installs MSAL.PS.
  • Uploading the package to LCS. Pipeline should always get the latest package from the desired build pipeline and upload to the project’s LCS asset library. This task is well documented in MS Learn.
  • Deploying the package to a designated environment. As a result of the previous step, the package should be uploaded to the project’s LCS asset library and as a last step, the pipeline should apply the package to a desired D365 Finance & Supply Chain Management environment. This can be easily done by adding a package deployment task to the release pipeline. This is well documented in MS Learn.

We have found it useful that release pipelines allow scheduling, allowing you to schedule the release outside of working hours or even overnight.In doing this, you can ensure that the updates won’t cause any disruptions to ongoing projects. To add even more automation, you can also include tasks that automatically produce release notes with work items included in release, or add some testing steps. The setup we described is just a bare minimum of what’s possible with Azure pipelines and D365 Finance & Supply Chain Management.

Following the setup that we have described in this blog series, you should have a decent GIT setup in your D365 Finance & Supply Chain Management project that starts with documented and linked code changes, convenient setup of source control for developers and convenient build and release processes. Once set-up, feel free to experiment on your own and add extra steps to the pipelines, invent different branches and make any other improvements that could benefit your D365 Finance & Supply Chain Management project.

Hopefully, we managed to bust those misconceptions that you might have about GIT and you will now be able to use it successfully in your projects.

If you need any help with the GIT and Dynamics 365 project, our experienced team is here for you.

In case you’ve missed our latest webinar on this topic, you can watch the recording here.

Paulius Brezgys
Latest posts by Paulius Brezgys (see all)

More about Finance and Supply Chain Management

Anaxco

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

Learn more
Companial