Source control processes


Developers rely on source control to track code changes and discover differences among content that is created by various developers. finance and operations uses Azure DevOps for source control, which is accessible through a web browser or Visual Studio by using the Team Explorer.

Azure DevOps, formerly Visual Studio Team Services

Azure DevOps is a cloud-based offering, which is also backed by a 99.9 percent service level agreement (SLA). While the core services are the same between cloud and on-premises, cloud also offers immediate access to new features, improved connectivity to remote locations, and simplified server management.

Azure DevOps

Azure DevOps is used as the source control service when developing for finance and operations apps. If you are upgrading from previous versions of Dynamics AX, you may be aware of Team Foundation Services for source control, this has been replaced by Azure DevOps. As a developer, you will need to ensure Azure DevOps is set up and configured before you start developing.

To enable source control through Azure DevOps, you will need to go to and sign up for Azure DevOps to create your account. When you create your account, you will select a URL for it. This will be the URL that you will connect to from your development computer when you configure source control. When your account is created, or if you already have an account, create a new project.

To configure your Visual Studio environment to connect to your team project, follow these steps:

  1. Open Visual Studio as an administrator.
  2. Open the Solution explorer if it is not already displaying by selecting File > Solution explorer.
  3. Select the Team explorer tab at the bottom of the window.
  4. Select Manage connections.
  5. Select Connect to team project.
  6. Select Servers….
  7. In the Add/Remove Team Foundation Server window, select Add.
  8. You will need to paste the URL for your Azure DevOps project in the Name or URL of Team Foundation Server field.


It will likely look like this example:

  1. Select OK.
  2. Select Close.
  3. On the Connect to Team Foundation Server window, use the dropdown to select the project you just added.
  4. Select Connect.

When you are connected to the Team Foundation Server, you will need to map your Azure DevOps project to your local model store and projects folders.

  1. Open the Source Control Explorer from Team Explorer.
  2. Map the Metadata folder of your team project to the root folder of the model store on your local drive.
  3. Select Map.
  4. On the next dialog, select No.
  5. Repeat these steps for the Projects folder as well.

When creating a new Visual Studio project, you can add the project to source control. Source control enables version control on elements in Visual Studio. Version control forces you to check code out while developers are making changes to code.

Screenshot of the New Project page highlighting the Add to Source Control check box.

When you have finished making your changes, you must check in your changes. Each check-in creates a new version of that element. This process allows other developers to see who made changes, what changes were made to an element, and when the changes were made. It also allows you to revert code to a previous version if errors are found in the current version. When you check in code, other developers can also then perform Get latest to merge all the latest available versions of the code.

When you perform a Get latest, you might come across some change conflicts, where a new version of code conflicts with what you have currently built in your code base. You can view and resolve conflict in Visual Studio on the Resolve conflicts page.

Three panes are available on the Resolve conflicts page:

  • Left pane - Shows your current code
  • Right pane - Displays the new code
  • Bottom pane - Displays what the automatic merge code will look like

You can select to accept the automatic merge or individually accept which code will be merged or overridden.

Branching and merging

Finance and operations uses branching to isolate individual software assets, which allows you to work in parallel with other developers to increase productivity. Branching requires additional effort to merge code. No defined rule exists for how branches are set up, but there is usually a Development, Test, and Production or Release branch. A Development branch is used for code that isn't ready for testing; however, it is shared between developers. Some larger teams might use multiple developer branches. The Test branch is used to hold changes that are ready to be tested by other users. The Production branch will hold all the source code exactly as it's deployed in the production environment.

You must create a deployable package to move code changes from one environment to another. We recommend that you use a build environment to create deployable packages that contain all changes. You can create deployable packages from the development environment.

To create a deployable package, follow these steps:

  1. Select Dynamics 365 > Deploy > Create Deployment Package.
  2. Select the packages that contain your models.
  3. Enter a location to create the deployable package.
  4. After the deployable package is created, sign in to Lifecycle Services.
  5. Go to your Lifecycle Services project.
  6. Select Asset Library.
  7. Upload the deployable package that you created.

To deploy a package to a non-production environment or a production environment, you will use Lifecycle Services. The process to deploy the package differs between the two. Also, a deployment to a production environment requires the package to successfully deploy to at least one sandbox environment in the same project.

To deploy a package to a non-production environment, follow these steps:

  1. Open the Environment details view for the desired environment.
  2. Select Maintain > Apply updates.
  3. Use the filter to select the package to apply.
  4. Select Apply. The status in the upper-right corner of the Environment details view will change from Queued to In Progress.
  5. When the package has been applied, the environment status will change to Deployed and the servicing status changes to Completed.

To deploy a package to a production environment, follow these steps:

  1. Go to your project's asset library in Lifecycle Services.
  2. On the Asset library page, select the Software deployable package tab, then select the package that you want to move to production,
  3. Select Release candidate. This indicates that this package is ready for production deployment.
  4. Select the package you wish to apply in your production environment, and then Select Schedule to submit a request to apply it.
  5. Specify the date and time to schedule the package application.
  6. Select Submit, and then select OK to confirm.
  7. At the scheduled downtime, package deployment will start.
  8. After the environment is serviced, you can monitor the status. The Servicing status field indicates the status of package application. Additionally, a progress indicator shows the number of steps that have been run, out of the total number of steps that are available.
  9. After the deployment is successfully completed, the Servicing status field is set to Completed.


If package application isn't successfully completed, Microsoft will investigate the issue. The Servicing status field will indicate that package application has failed. The environment will be rolled back to a good state.

While the production environment is being updated, the environment will be unavailable. You can monitor the Servicing status field to monitor the status of the package application. When the deployment is complete, the servicing status will read Completed. The deployable package has now been applied to the production environment.