Getting started in Dynamics 365 For Finance and Operations as a Developer or Tech Lead can be challenging.

We'll walk through getting Azure DevOps Setup, configured, creating your first repo with TFVC (Team Foundation Version Control), connecting in Visual Studio and preparing everything for others to join the dev party.

Getting Started

First, let's create an Azure DevOps instance for the organization. Go to https://azure.microsoft.com/en-us/services/devops/ to get started. You can have as many instances as you like and as many projects in each instance that you like. Licensing is per 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.

First, let's get signed up.

Give your name an instance. As of this writing, this name will resolve to Dev.Azure.com/NAME as well as NAME.visualstudio.com.

Once you hit continue, you will be prompted to create your first project. Don't create a project using this screen. Instead, wait for the email from Azure DevOps (AZDO) to be sent to you letting you know your instance is ready. This will include a link that will let you configure the advanced settings which is what we need.

You should see options like this

Select Private then select "Team Foundation Version Control" Under version control. The default is Git which is not a supported version control system for Dynamics 365 for Finance and Operations as of this writing. Give the project a name and hit create project.

You now have a project that should look like this.

Set Policies

Please refer to my article on policies that I think you should be using. For all setup of ALM activities, I typically create a task work item called "Misc ALM Activity" and associate all changesets there. 

Creating Branches

Next, you'll want to create a dev Repo. I typically build my repos in TFVC like so:

The above is just one of many ways to do it and this is specific to TFVC. I'll write another article on using Git. Next, we'll want to connect to our newly created project. As a way to section off what type of work I am doing, I will typically map everything locally on my laptop for code management and leave any development environment just for development. Not a requirement but just a mnemonic to keep different types of work in different work streams. Open Visual Studio, version 2015 or later is preferred. Open the Team Explorer tab then click on manage connections. 

Click Servers then add the instance you just created

Next, select your project and hit connect.

Next, open source control explorer from the Team Explorer tab and map the project locally.

From Source Control Explorer, perform the following:

• Add a folder called Trunk
• Commit
• Create folder in Trunk called Main
• Commit
• In Main, create a folder called Projects
• In Main, create a folder called Metadata
• Right click on the Truck folder, select "Branching and Merging" then "Convert to Branch"
• commit
• Right click on the Trunk branch, select "Branching and Merging" then select "Branch" calling this branch "Release".
• Commit
• Right click on the Trunk branch, select "Branching and Merging" then select "Branch" calling this branch "Dev".
• Commit

When you are done, it should look like this:

Connect In a Developer Environment

Connecting from a developer environment is fairly easy but we have a 2 primary differences on how we do that depending on the environment type. We'll cover Cloud-hosted and the environment Image (VHD).

Mapping Projects

Regardless of environment type, projects will always be mapped to the same location. To map projects, open VS, connect to your instance of AZDO and select the project. Next, select /dev/main/project then click on "Not Mapped" and map it to C:\Users\<Your User>\Documents\Visual Studio 2015\Projects

Cloud Hosted

Map /Dev/Main/Metadata to K:\AosService\PackagesLocalDirectory. See note and screen below on trailing metadata value in path.

Environment Image

Map /Dev/Main/Metadata to C:\AosService\PackagesLocalDirectory. Make sure to delete the trailing metadata from the path prior to mapping.

Create your first package and model

Create the package and model for the project for the specific customer, client and/or initiative to cover the scope of your engagement. If you are with a partner or a customer, chances are the outcome will be the same. If you are working with Contoso Limited Inc, chances are you'll have a package and model called "CLIExtensions" where CLI is the code for Contoso Limited Inc.

Next, create the projects.xml file in your projects directory. Below is an example. This should be in the root of your projects directory. Add this file to source control.

<?xml version="1.0" encoding="utf-8"?>
<Projects xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
  <Project>
    <Type>Metadata</Type>
    <Name>CLIExtensions</Name>
  </Project>
</Projects>

From our newly created package and model, we want to only add two folders and ignore the rest (if present). We want to add the name of the model we created, such as CLIExtensions, and the descriptor directory. 

Merge this changeset everywhere

Once you have created the package, model and your projects.xml file and merge it to all branches. This is just committing the empty folders for the package. I suggest you do this because this will just lay the groundwork for work later. If you merge a folder add as well as a file add in a changeset, then rollback the folder add, it also removes the file in that folder. It's a corner case that I've run into once but it was difficult to untangle that mess so just push the folder structure everywhere and call it good. You can use the Azure DevOps Merge Template to help managed the changesets for where they are going with standard comments for review later. 

Setting Up The Build Server

By default, a cloud based project gets a build server for free as a standard environment slot in LCS. You can find details on how to set that up here. You can also have a cloud-hosted build box as a separate instance from the default build box or as a Azure hosted build box for an on-premise deployment. Also, if you would like to have an on premise build box, that is also an option. You can find those details here.

Setup Gated Checkins and Scheduled Builds

For more info, look at this and this to get started. Gated Check-ins and Scheduled Builds really only differ based on the trigger so you can do either or both, if you like. The scheduled builds make the most sense for Trunk and Release while Gated Check-Ins make sense for dev branches.

Setup Releases

Releases in AZDO is a generic term for releasing something to another system, not just releasing the latest code or binary for update somewhere. We can create tasks in AZDO to upload an asset, deploy an asset as well as a few others. In order to get this functionality, you'll need to install the plugin for it. It can be found here. Jos├⌐ Antonio Estevan wrote a great article on how to do release an asset to LCS. Some other links that are helps are below:

• 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/

Getting Ready for Development

Now we're ready to get some development started. Depending on how you set things up, you'll want to document everything and create an onboarding document for your developers to follow when getting their VMs setup including:

• Where to map to for them including the AZDO URL like https://nathanclouseaxgit.visualstudio.com/
• What packages to build after first sync like SpiffCoBase and SpiffCo
• If you are using gated check ins, what that experience will be like.

And that's about it. 

Conclusion

Once we have everything setup, configured, scheduled and triggers in place, the experience around D365 F&O is pretty good compared to older versions. From code to deploy, I can have all sorts of automation to get stuff built and/or deployed to specific environments with a quality bar that I can set which is pretty good. There are some areas for improvement, sure, but this overall provides the tools we have been lacking in past versions. We'll cover task management in AZDO next and getting your LCS project and your AZDO instance connected.