D365 Finance & Operations Development Workflow using
Visual Studio and Azure DevOps Git
This document outlines the standard procedure for developers to set up their local development
environment, work on features using Git branches, and submit changes for review using Pull
Requests in Azure DevOps.
Prerequisites:
Visual Studio installed with Dynamics 365 development tools.
Access to the Azure DevOps project and Git repository.
Appropriate permissions in Azure DevOps.
Developer VM configured with D365 F&O.
Steps:
1. Connect to Azure DevOps and Clone the Repository:
o Open Visual Studio.
o Go to Team Explorer (usually found under the View menu or as a tab).
o Under "Local Git Repositories", if you haven't cloned the repository before, click
Clone Repository....
Figure 1 Clone repository.
o In the "Clone a repository" dialog, click Azure DevOps under "Browse a
repository"
Figure 2 Open Azure DevOps explorer.
o Visual Studio will connect to your Azure DevOps organization(s). Browse and
select the correct Azure DevOps server, project (e.g., D365 On-premises
implementation project), and the specific repository to clone (e.g., D365FO).
Figure 3 Select repository to clone.
o Verify or change the local Path where the repository code will be downloaded
(e.g., C:\Workspace\D365).
o Click Clone.
Figure 4 Specify local workspace folder.
o Visual Studio will download the repository content to the specified local path.
Once complete, Team Explorer will show the connected repository context.
Figure 5 Connected to azure project.
2. Set up Symbolic Links (Required for D365 Development):
o Open PowerShell as Administrator: Search for "PowerShell" in the Windows
Start menu, right-click "Windows PowerShell", and select "Run as administrator".
Figure 6 Run PowerShell as admin.
o Navigate to your Workspace: Change the directory to the root of your cloned
repository or a designated workspace folder. In this example, the path
C:\Workspace\ is used.
o cd C:\Workspace\
Figure 7 Navigate to the local workspace folder.
o Create Symbolic Link(s): For each custom model in your repository, create a
symbolic link from the standard AOS Service PackagesLocalDirectory (usually
on the K: drive or equivalent on a dev VM) to the corresponding model folder
within your cloned repository's source structure.
Example: Linking the Armccor model located in
C:\Workspace\D365\[Link]\us\models\Armccor to the standard package
location. Adjust the target path based on your repository structure.
o New-Item -ItemType SymbolicLink -Path
"K:\AosService\PackagesLocalDirectory\Armccor" -Target
"C:\Workspace\D365\[Link]\us\models\Armccor"
(Note: Ensure the path specified in -Path corresponds to a folder that does not
already exist in PackagesLocalDirectory. The command creates the link itself.
The folder specified in -Target must exist in your cloned repository.)
Figure 8 create a symbolic link to deployable package.
o Repeat this step for all custom models within your cloned repository that you
need to work on. (This image shows PackagesLocalDirectory structure for
context).
Figure 9 Module appearing under package local directory.
3. Refresh Models in Visual Studio:
o Go back to Visual Studio.
o Click on the Dynamics 365 menu.
o Select Model Management > Refresh models.
Figure 10 refresh models to observe new model.
o
This step ensures Visual Studio recognizes the models linked via the symbolic
links.
4. (Optional) Perform an Initial Build:
o It's often a good practice to build the models you intend to work with to ensure
the initial setup is correct.
o In Visual Studio, go to Dynamics 365 > Build Models....
o Select the relevant models (e.g., Armccor).
o Click Build.
Figure 11 search for custom model.
5. Create a Feature Branch:
o Open the Git Repository window in Visual Studio (View > Git Repository).
Figure 12 navigating to git repositories
o In the Git Repository window, expand the Branches section.
o Right-click on the base branch you want to branch from (typically main or
develop).
o Select New Local Branch From....
Figure 13 create new branch for development
o Enter a descriptive name for your new branch (e.g., feat-med-benefits). Use a
consistent naming convention (e.g., feat/, fix/, userstoryID/).
o Ensure the "Checkout branch" option is ticked.
o Click Create.
Figure 14 input descriptive name for new branch.
o You are now working on your new local feature branch.
6. Perform Development Work:
o Make the necessary code changes, add new elements, etc., within Visual Studio
related to the feature or fix you are working on.
o Build the solution/project periodically to check for errors.
o Commit your changes locally to your feature branch using the Git Changes
window in Visual Studio. (This step is not explicitly shown in the images but is a
standard part of the workflow).
7. Push the Feature Branch to Azure DevOps:
o Once you have committed your changes locally and are ready to share them or
create a Pull Request.
o In the Git Repository window, right-click on your feature branch (e.g., feat-med-
benefits).
o Select Push.
Figure 15 publish newly created branch.
o
This will upload your local branch and its commits to the remote Azure DevOps
repository.
8. Create a Pull Request (PR):
o After successfully pushing your branch, Visual Studio often shows a notification
with a link to create a Pull Request. Click this link.
Figure 16 create a pull request for code review.
o Alternatively, navigate to your project in the Azure DevOps web portal, go to
Repos > Pull requests, and click New pull request. Ensure your feature branch
is selected as the source and the target branch (e.g., main) is correct.
o Fill in the Pull Request details:
Title: Provide a clear and concise title summarizing the changes (e.g.,
"Added medical aid benefits").
Description: Add details about the changes, the reason for them, and any
specific testing instructions.
Reviewers: Add the required individuals or groups (e.g., "Code Review
Team") who need to approve the changes.
Work Items: Link the relevant work item(s) (e.g., Task, Bug, User Story)
that this PR addresses. Search by ID or title.
Figure 17 pull request overview.
o Click Create.
9. Pull Request Review and Completion:
o Once created, the Pull Request will trigger any configured branch policies, such
as automated builds (e.g., "D365FO Build in progress").
o Reviewers will be notified to examine the code changes.
o Address any feedback by pushing additional commits to your feature branch
(these will automatically update the PR).
o Once the build is successful, feedback is addressed, and reviewers approve, the
Pull Request can be completed (merged) into the target branch by authorized
personnel, usually via the Azure DevOps web interface.
Figure 18 reviewers added automatically.