using Git Rather than TFVC is easy!

You can use Git for your Dynamics 365 for Finance and Operations rather than TFVC if you want. This path is not currently supported (as of 1/15/2020) but that is likely to change. Even if this is never supported, it's not something we can't plan and manage against as MSFT is using Git internally. If they can do it, so can you. 

Getting Started

First, we'll create an instance and a project for that instance in AZDO (Azure DevOps). Once you create your first organization, you will be prompted to create a project. Be sure to select "private".

This will default to using Git as your version control. Look at this article to see how you can change that - its a little hidden. You can have as many instances as you like and as many projects in each instance that you like. Licensing is per AZDO instance so keep that in mind. Visual Studio subscriptions follow those users around so they don't consume licensing in an instance if added with the VS license selected.

We'll also need the GitHub tools. This is a great article on how to configure this for VS 2017 but the same steps are required for VS 2015. You will also want to install a Git command prompt client. VS will prompt you to do that so just follow the directions for that. You can also pick one up from https://git-scm.com/download/win. 

Branching

Before we start commit code in Git, we'll need to setup how we plan to manage our code. Similar to TFVC, we'll want to plan out the lifecycle for where our code starts, how it gets reviewed, approved, built and tested. You can read more on TFVC here to get an idea on what we're planning for. The Git workflow is very different from TFVC. You can read more about that here and here. The key mindshift here is that in TFVC branches are long term but in Git they come and go rapidly.

Connecting to Git

Next, we'll want to follow this article to get it setup: https://robscode.onl/d365-migrate-from-tfvc-to-git/. This covers migrating but it will work also for a new project, too. We just won't have any code to migrate. My .gitignore file looked like this after I created a package called "AAXTest"

# Ignore everything
*

# You can be specific with these rules
#!/some/other/deep/path/**
!.gitignore
!/VSProjects

#include package, exclude binaries
!/AAXTest
/AAXTest/bin
/AAXTest/XppMetadata

!AXModulesBuild.proj
BuildProjectResult.err.xml
BuildProjectResult.log
BuildProjectResult.xml

Policies For Branches

Just like TFVC, Git has policies for what is allowed and what is not. Git policies are branch based. MSFT has great documentation on this that you can read here. You can chane repo policies in project settings.

Here are my recommendations.

Dev / Feature Branch

I suggest having no policies enabled here.

Trunk

I suggest having at least 1 reviewer other than the developer, require that a work item be referenced and force that all comments have been resolved before a pull request, or PR, will be accepted.

Release

My suggestion here is that you have at least 1 additional reviewer plus an automated code reviewer for a senior resource the confirm all changes going into the release branch. keep in mind depending on timing and criticality, we may be cherry picking hot fixes for large scale bugs that cannot wait until the next release so we'll want to plan for both.

Connect To The Correct Branch

Yup - this is here. Unlike TFVC which has monolithic and persistent branches, depending on the Git strategy you use, it's possible, and likely, that you will create and/or delete branches several times in a day. Consider a minor bug - a typo. This doesn't affect anything in terms of delivery other thing a less than perfect user experience. One workflow to address this typo is to:

• Create a work item, let's call it work item 123
• Create a bug fix branch, let's call it branch bug-fix-123
• connect to the branch
• fix the typo
• commit
• sync
• automated build
• create PR
• It get approved and merged
• delete branch bug-fix-123
• close work item 123
• Release during next schedule

Create Your First Package

Now we're ready to create our first package. For this, it's the standard process inside Visual Studio. For each new package you add, you'll need to modify your .gitignore file to include it. Otherwise, it will get ignored. Also, Git ignores empty directories. So while the package and model creation process will fully explode out and create all your directories for your artifacts and their deltas, Git will ignore them unless they have a file, any file, in them. That doesn't mean go create a bunch of files in the directories. This is just a call out on how things are different. TFVC looks at folders and files. Git just looks at files.

Build

Now that you can create and commit code, it's time to start building. Because of the switch in version control systems, we can will have to make a few changes to the pipeline and the build box itself. But first, we have to make it passed the first major issue. We cannot provision a build box against a repository that isn't TFVC based. I got around this by adding a TFVC repository to my project, running through the standard build server process (in LCS or Cloud hosted), and pointed to that repository. This created a pipeline tied to that TFVC repo so I'll have to clean that up. I relied heavily on this article but I'll be adding extra commentary:

https://robscode.onl/d365-azure-dev-ops-build-with-git-as-source-control/

I followed this basic process:

• Add TFVC repo to ADZO project
• provision build box against that repo
• updated the pipeline to refer to the GIT versions of stuff
• made misc changes to pipeline to address some weirdness that is planned ( article above )
• made misc changes to the dev box itself so it will now only ever work against Git and not TFVC
• make the TFVC repo not editable ( remove permissions, delete everything there, make it a waste land since we can't delete it )

Create the TFVC Repo

First, create the TFVC repo in your AZDO project. You can do this by going to the drop down for the repo you are currently in when viewing repos, like so.

As you can see, I already have two repos with the same name. The first one with the purple icon is TFVC and the second with the orange icon is Git.

Provision the Build Box

Please refer to in LCS or Cloud hosted articles.

Update Pipeline

We'll need to change a few things in the pipeline to make it work with Git. The article from Rob's Code will be referenced here as well.

Get Sources

The first is to make this a Git pipeline. For the "Get Sources" step, change this to use Azure Repos Git then select your project, repo and branch.

Set Model Versions

In the article referenced above, there is a Powershell script we'll want to run to address some stored settings. We'll also want to remove "\Metadata" from the arguments section of the Set Model Versions task.

Build the Solution

In the Build the solution task, we'll need the project to refer to AXModulesBuild.Proj directly. We'll also need to follow the article referenced above to modify and commit this file so that the build will execute properly.

Generate Packages

In the Generate Packages tasks, in the arguments section, there is a reference to "Metadata\" that we will have to remove.

Build Box Changes

In Rob's article above, there is a Powershell script. Run it if you haven't already.

Clean up TFVC

Unfortunately, we can't simply just delete this repo. Once a TFVC Repo is created, it is there for the life of the AZDO project. However we can destroy it. Destroy is not the same as delete. Destroy marks it but it is still there. You can destroy it with this command:

tf vc destroy $/TestProject

I just removed all access to it and rolled back all changesets. I don't think a destroy is called for but only time will tell.

Continuous Integration

TFVC has gated check-ins which I think are pretty cool. With Git, you can use Continuous Integration only. This will kick off a build in AZDO whenever a changeset makes it to the server. Keep in mind that because git is distributed, the build will start when the changeset makes to the server, not when it is committed. To enable this, simply enable continuous integration on the build definition in the triggers tab.

Conclusion

Now we can use Git rather than TFVC and we have the same level of ALM functionality and offerings. We can now develop with a more trunk focused approach delivering smaller bits of functionality more rapidly. For other ALM offerings, the configuration and setup is the same. More on that can be found here:

• https://community.dynamics.com/365/financeandoperations/b/newdynamicsax/posts/azure-devops-task-to-deploy-code
• https://www.linkedin.com/pulse/azure-devops-task-deploy-code-micosoft-dynamics-365-ghazvinizadeh/