Dynamics 365 Finance and Operations - TFVC, git, Azure DevOps pipeline Tasks, Github actions

[landro]

Hi there,

Our organization has been using Azure Devops for all things VCS and CI/CD in the past, but a year ago we started transitioning to Github, and our goal is to get rid of Azure Devops entirely. The only project we now have left on Devops is related to D365 Finance and Operations. In the past we have been told by various people, that finance and operations only supports DevOps, but I was wondering if that is actually so. Is it viable to only use Github and Github actions for version controlling, building and deploying code etc for managing our d365 environments?

I have the following questions:

1. The team is currently using TFVC instead of git - is there a good reason they're doing this, or is it viable to use git when doing a finance and operations project?
2. The team is currently using the Dynamics 365 Finance and Operations Tools DevOps extension in pipelines and releases. They use tasks like
   • Create Deployable Package
   • Add Licenses to Deployable Package
   • Task to upload assets to the LCS asset library
   • ...
     Can d365fo.tools be considered a replacement for the Dynamics 365 Finance and Operations Tools? If yes, can your powershell modules be used from a Github Action running linux (our preferred build platform), or do you require windows? Any other considerations/limitations?
3. Is it viable to switch off Azure Devops completely?

[FH-Inway]

Hi, welcome to the repo and good questions.

TLDR

So, the TLDR answer to your question is: Yes, it is viable to use Git and GitHub for version control and CI/CD for D365 Finance and Operations projects. I've done it partially myself and see no blocking issues to do it fully.

The long answer

There is a lot to consider, so this answer will be a bit longer. Grab a drink of your choice and let's dive in.

First, let me address the questions:

Git for D365 Finance and Operations

The reason teams are still using TFVC is probably due to historic reasons and lack of knowledge and skills in Git to make the switch. For a long time, Microsoft has been (and still is) supporting TFVC directly for D365FO implementations. However, it has always been possible to use Git as well and there are several blogs and videos out there on how to do it. Microsoft themselves have been using Git internally for a long time for D365FO development. More recently, they also started recommending Git and providing documentation for it. One such documentation is the Git walkthrough in their business applications playbook.
So to answer the second part of the question: Yes, it is viable to use Git for D365FO projects.

Replacing Dynamics 365 Finance and Operations Tools with d365fo.tools

The Dynamics 365 Finance and Operations Tools DevOps extension consists of several pipeline tasks to support the deployable package creation and deployment process. To that end, it also adds a new service connection type to facilitate the authorization with LCS.
Can d365fo.tools replace all that? Unfortunately, no, not everything 😢 (@Splaxi correct me if I'm wrong here). But there are ways around the missing parts. So let's go through each part to see what's there, what's missing, and what can be done about it.

LCS Service Connection

The LCS service connection for DevOps provides the authentication with LCS for the Dynamics 365 Finance and Operations Tools. d365fo.tools has Set-D365LcsApiConfig and Get-D365LcsApiToken to facilitate the authentication with LCS. Still, you need a place to store the credentials securely. Without the service connection, you can use GitHub secrets or an Azure Key Vault to store the credentials. This is a bit more work than just setting up a service connection, but it is doable.

Create Deployable Package

Probably the most important part of the extension and unfortunately, d365fo.tools does not cover it.
This could be the most difficult part to address that gap. There are several ways to go about it, in increasing order of difficulty:

• Easy: If you use a self-hosted build server, you do not need the deployable package task. The build server comes with a GeneratePackage.ps1 script. Just install a GitHub runner on the build server and run the script as part of the build process. Note that deploying a self-hosted build server from LCS requires Azure DevOps. However, this can be a dummy DevOps to fulfill the requirement, but not be used for anything else.
• Easy-ish way: Use FSC-PS for GitHub. This is another community project that actually builds on top of d365fo.tools to provide the necessary parts in GitHub (kinda like it was written for your scenario 😄). The RunPipeline action of FSC-PS produces a deployable package. You can look at one of the build executions of the D365FinanceToolbox (which uses FSC-PS) for an example. Easy-ish because setting up FSC-PS takes some time and the documentation is a bit lacking. And it comes with the same caveat as d365fo.tools: it's community-driven (mostly by 1-2 people) and not officially supported by Microsoft.
• Hard way: Reverse-engineer the deployable package creation process. You can download the Dynamics 365 Finance and Operations Tools DevOps extension as .vsix file, which is just a zip file with a different extension. Inside, you will find that the tasks are basically just PowerShell scripts. If you have someone with PowerShell and D365FO expertise, they can probably recreate it as a GitHub action with several days of effort.

Add Licenses to Deployable Package

If you don't have ISV solutions with licenses, you can ignore this part.
d365fo.tools does not cover this. However, it is just a question of adding the license file in the correct place in the deployable package. So it should be pretty easy to reverse engineer as GitHub action. Note that FSC-PS does not seem to cover this part either (@onikolaiev correct me if I'm wrong here).

Task to update model version

Not covered by d365fo.tools. Pretty easy to reverse engineer, because it's just a change of the version number in the descriptor file of a D365FO module. If a self-hosted build server is used, there is also a UpdateModelBuildNumbers.ps1 script available and the extension task is not needed. I'm not sure if FSC-PS covers this (@onikolaiev ?).

Task to upload assets to the LCS asset library

Covered by Invoke-D365LcsUpload.

Task to download assets from the LCS asset library

Covered by Get-D365LcsAssetFile.

Task for LCS asset deployment

Covered by Invoke-D365LcsDeployment.

Linux and other considerations

The build process for D365FO depends on some dlls and executables by Microsoft. As far as I know, those only work on a Windows operating system with Visual Studio. So you cannot use Linux. d365fo.tools also depends on Windows, because it has some dependencies and loads some assemblies that are Windows only.

See below for other considerations.

Switching off Azure DevOps

Personally, I would answer that yes, it is viable to switch off Azure DevOps completely. It will take some doing and introduce some risk and maintenance effort you would otherwise not have. On the other hand, there are a lot of advantages by moving to Git and having everything on one platform.

Thoughts on the future

My answer so far has been about the current state of things. However, Microsoft is currently in the process of transitioning from LCS to the Power Platform as hosting platform for D365FO. This comes with a lot of changes, including the build and deploy process. So if you transition now to GitHub, chances are you will have to change a lot of stuff once LCS is no longer available (which currently seems to be in a 1-2 year timeframe). So you might want to consider that in your decision. If you want to learn more about that, I recommend the One Dynamics One Platform series of TechTalks, especially the latest three. Note that the latest one about ALM places a heavy focus on using Git.

My recommendation would be: Switch to Git as soon as possible. Apart from lack of knowledge and skills, there is no reason to stick with TFVC and Git comes with a lot of benefits over TFVC. Continue to use Azure DevOps for now. A hybrid model might make sense where parts (e.g. the repository) are already moved to GitHub, but the CI/CD is still done in DevOps. Keep an eye on the One Dynamics One Platform story and once it seems stable enough, make the switch to it and as part of it, switch to GitHub fully as well.

Disclaimer

You can probably tell I'm a fan of Git. I'm also a contributor to d365fo.tools and FSC-PS. So take my answers with a grain of salt and listen to the concerns of your D365FO team.

Happy to discuss further if you have more questions. I've been doing D365FO projects with Git since 2019 and our company never had a reason to regret the move from TFVC to Git. We also started using GitHub for some things, but have not done a D365FO project on it. My experience with that is mainly with FSC-PS and the open source projects that use it.

[AurelienClere-365]

Hello, with the move from LCS to PPAC I am considering that myself. GIT vs TFVC : OK 👍, GitHub vs DevOps : somehow. I was thinking about creating a sample / template GitHub project to start CI/CD for FinOps. After all, we will need to deploy/release through PAC CLI and not anymore LCS API (already the case for UDE environment)
So we "just" need - like you said - to have the way to replace the DevOps extension on the build side only. (Like tasks : create Unified Deployable Package, adding ISV licenses etc...) . If we have it in d365fo.tools maybe we will be good in this case 😊 . For Power Platform / CE / CRM - we can already build and deploy using GitHub already.

Will check the hard way 😅

[landro]

Thanks for this fantastic and most elaborate answer @FH-Inway! I really appreciate it!