Using version control for development in the ERP system MS Dynamics AX is a rather controversial thing. Someone does not use it at all, someone uses the built-in version control system MorphX.

My name is Igor Glukhov, I am a MS Dynamics AX developer at Lamoda. In this article, we’ll talk about how we got started using Team Foundation Server and Azure DevOps for version control in Dynamics AX 2012 and how we got started using version control to prepare for releases.

Below I will tell you all the details:

– History of changes: where to start;
– Version control: synchronization and connection of the development environment;
– Connecting Test and Prerelease to version control;
– How is the release assembly going now and what results were obtained at the output.

History of changes: where to start

Let’s start with the fact that earlier we were developing in one common Dev environment. To make one modification, it was necessary to make changes to the system objects (tables, classes, forms, etc.) that grouped the project. One project in Axapta is one modification for us.

All code that was developed within the project was marked with a comment with the project name.

This concept did not track the history of object changes. If we forgot to include a comment or put the name of the wrong project, then it was difficult to determine which task the code belonged to.

We also transferred modifications between applications using projects. The process turned out to be time-consuming and required care: it was necessary to compare all objects within the project and pick up only the code that belongs to the current project.

As a result, large projects could take over 30 minutes to migrate. And in the release, where there are 20-30 projects, it took already 8 hours and sometimes even more.

To get rid of these problems, we decided:
1. Implement a version control system to track the history of object changes,
2. Speed up the process of transferring modifications and building the release.

Version Control: Synchronizing and Connecting Development Environment

The version control system was selected according to the following criteria:

Built-in Axapta support without customization.
Easy to install and maintain.
The functionality will allow you to implement a new process for transferring modifications.

Team Foundation Server (TFS) was our team’s first choice, but it was too labor intensive to set up and maintain. The idea of using Azure DevOps seemed more attractive to us: it allows you to create a repository of the same TFS, while not requiring separate configuration and administration of the server itself.

Let’s take a closer look at how the synchronization process looks in the Axapta application with the selected version control.

Sequence of steps:

First, we create a local file directory to store Axapta objects as files.
Next, we start a version control repository, organize a new development directory there to save our changes and also configure it in the application.
Synchronization is started from Axapta and starts comparing the version of the file in the local directory with the version of the object in the repository.
If there are new objects or other changes in the repository, the local file directory is updated first, and then it is synchronized with the Axapta application.

Initial synchronization of Axapta with version control takes over 3 hours. This is due to the fact that about 20 thousand objects are synchronized: first with the file directory, then with the application. Further synchronization is 10-15 minutes. During this time, only those changes that we made in version control since the last update are pulled.

The standard version control connection scheme assumes that there is one application and one local file directory for synchronization with version control. We made a change to the Axapta standard and added the ability to work in one Dev-application with several file directories with the ability to start synchronization for each developer.

In the process, we noticed that there were synchronization conflicts. This resulted in code loss. Therefore, we decided to return to the standard Axapta scheme, which has one application, one file directory and one version control directory.

For each developer, we deployed a separate virtual machine, set up individual development environments for them, and once again did the initial setup of local directories and a version control repository.

Now we were able to track the changes of objects, this scheme was debugged and there were no more crashes.

After implementing version control, we looked at the new version of the Dynamics 365 system, where the release build is done by transferring changesets to Visual Studio, and decided to try to do the same.

With the advent of version control in TFS, we got access to such elements as:

A changeset is a collection of object changes stored in version control.
Work Item is a task that can combine several changesets.

In the new concept, we moved away from the idea that one task is one project, to the idea that one task is one Work Item.

Connecting Test to the Dev version control directory

Since all modifications are tested in the Test application, the code for releases should be taken from it. So, Test also needed to be connected to version control.

We considered several connection options with their pros and cons and chose one where the Test application connects to the same Dev version control directory as all DevBoxes.

Thus, all objects in version control become common for all DevBoxes and for the Test application. All changes made in DevBoxes and uploaded to version control will also go to the Test application.

Before connecting, we did the preparatory work:

In our case, due to the loss of code on Dev, there were differences between Dev and Test applications. Therefore, it was necessary to align them so that after connecting Test to Dev version control and starting synchronization, the different code was not lost.
It was also necessary to implement the Axapta login for users who do not have a TFS account (these are business users and consultants), and make other minor improvements.

Synchronizing version control in Test

All developers need sync access so they can port their code. This means that everyone would have to set up a local directory.

However, when several local folders were connected, objects were updated in only one directory. If every developer started synchronization, objects would be loaded again, which increased the load on the system and the risk of errors or crashes.

We decided to create a separate technical account, set up a local directory for it and organized the Axapta client launch under this user with automatic start of version control synchronization. Thus, every developer was able to start synchronization. It always runs as a single user, and we only need one local directory.

Connecting Prerelease to version control

Prerelease is the application on which we build the release.

The first configuration steps were done in Visual Studio:

The Dev directory of version control has been converted to a Branch. This is necessary in order to further create a hierarchy from this directory.

Created a new branch from the Dev directory for Prerelease. It was important to choose the right date. Subsequently, when transferring changesets, you can see only those that were made since that date.

Got the branch hierarchy from the Dev directory:

Further down in the Prerelease application, we configured versioning options for this new branch.

When creating a branch hierarchy for the Prerelease branch, all objects of the Dev branch with the version on the selected date were copied. But Dev and Prerelease applications are completely different applications, so you couldn’t take these versions of objects. We removed all generated objects from the Prerelease branch and started adding the usr model to source control.

Synchronizing version control in Prerelease

Unlike synchronization on DevBoxes and the Test application, for Prereleases, when transferring changesets, objects in the local directory are updated to the latest version. When synchronizing, Axapta pulls in only those objects whose version in the local directory differs from the version in version control. In the case of one configured local directory, the system will not find changes during synchronization and will not update anything in the application. To avoid this problem, we created a separate local directory for transferring changesets. Thus, we made two local folders: one for transferring changesets, and the other for starting version control synchronization in Axapta.

How is the release build going now

Azure DevOps has a list of Work Items. Each Work Item contains a list of changesets, where there is a list of all changes related to the task.

We first used Visual Studio 2010 as Axapta 2012 only supports it for TFS integration. Since we created a separate directory for transferring changesets, we subsequently started using Visual Studio 2017.

The transfer of changesets to the release itself looks like this: in Visual Studio, we launch the Merge on the Dev branch. We indicate the Dev branch as the source, the Prerelease branch as the destination, and choose to transfer specific changesets.

Next, we see a list of changesets that are available for transfer, select the required one and apply it, then check-in the changes.

After transferring all changesets for all tasks to the release, we launch synchronization with version control in Axapta in order to pull up all the transferred changes into the application.

The process is schematically as follows:

What happened in the end

We now have version control, which means a history of improvements.
We’ve made it faster and easier to migrate modifications from the Dev app to the Test app. If earlier it took 30 minutes or more to transfer a large project, now the changes of all developers get to Test in about 5-10 minutes, since there is no need to load projects and compare objects. Moreover, we got away from manual work, and this allowed us to avoid errors associated with transferring or overwriting someone else’s code due to carelessness or carelessness.
And, most importantly, we managed to reduce the time for preparing the release. If earlier it took about 8-10 hours, now it takes less than 4. And the release itself has become easier, since there is no need to unload and load projects, everything happens in Visual Studio.