AX development under control.

You fight in an environment Microsoft Dynamics AX often having problems with sharing objects on one project between multiple developers?

Is the time and energy invested in organizing the build and deployment of new batches with development to the customer's target environment already prohibitive for you?

Do you often resolve ambiguities or errors in deployed development directly with the customer?

If you answer yes to any of these questions, I have some tips for you, based on my personal experience of many years, on how to avoid such situations.

Clarify what type of development environment you need for the project

For smaller projects, where fewer developers are involved in development and where it is unlikely that they will need to work on the same objects frequently, you can use a single shared development environment.

For larger projects, use the distributed development environment model in combination with Team Foundation Server.

For large projects, on the other hand, use a distributed development environment model, where each developer has their own environment that they regularly synchronize from a central repository (see below). They also submit their development to the central repository (usually when they have completed a complete part).

Use version management

There are many advantages to using version control:

• Provides an overview of each change on each object and also who made the change and when
• Allows you to enter a factual description for each program change
• It allows you to quickly find out what happened historically on each object
• Significantly contributes to the effectiveness of communication in a team of developers working on the same project

Environment Microsoft Dynamics AX solution offers several options for to version the program changes made by each developer.

For a shared development environment model, version control can be used, which is directly integrated in AX (MorphX VCS).

In this case, the developer will reserve the object when starting work, preventing others from making changes to it. This is only possible after the developer commits changes to the object to version control, when the object is unblocked.

Use at least two test environments for each project. One for the main development branch, the other for hotfixes.

In the case of a distributed model, you need to restore all objects on the local development environment from the global version repository before you start working. Developers can then work on the same object at the same time without any problem. However, conflicts may then arise in the code when committing the work to the global repository. However, most of these conflicts can be resolved automatically by the tool used. If automatic resolution is not possible, the developer has to handle the conflict manually at this point.

As a global repository you can use e.g. the very good tool Team Foundation Server (TFS) developed by Microsoft, which has an integrated ticketing system. It is then possible to view all program changes related to a given request.

Use a deployment management tool, ideally in combination with a ticketing system

Release Management Tool (RM) significantly increases the efficiency of the work when setting up a new batch with development intended for deployment to test or production environments. In addition to a fast and error-free build of the batch, it again provides a clear overview of who built the batch and when, and what requirements were included in it.

Direct connection of RM to the ticketing system (TS) also prevents many confusions and misunderstandings in communication between members of the delivery team.

At the beginning, the TS makes it clear which requirements are to be included in a given batch.

The build procedure can then be as follows:

• The builder checks against the request number that the request is in the correct state in TS and the development version for each request is committed in RM (ideally there is an automated supporting functionality in RM for this).
• If everything is OK, the RM will build a new batch. Before doing so, it sends an informative email to the customer and selected team members with all the necessary information - especially about the need to restrict traffic on the target environment during the deployment. It will use a special BUILD environment to build the batch.
• Ideally, the delivery team has PowerShell scripts ready to program a sequence of steps to deploy the batch to the target environment. A simplified example of such a sequence might be as follows: compile AOT, Full CIL compilation, export modelstore, stop target AOS, import modelstore, synchronize Data dictionary, restart target AOS, send email to customer and other stakeholders about successful deployment of new batch

Distinguish between batch set-up and batch deployment

If the batch deployment process cannot be fully automated, do not leave the entire batch build and deployment process to one person. Since deployment often takes place at night, the the risk of errors is reduced by splitting the roles.

To build a batch, it is ideal to involve someone from the programming team working on the project. This person is able to resolve any ambiguities related to the submitted code and also to provide the deployer with additional technical information related to the deployment (the need to run initialization jobs after deploying the batch, making changes to the settings of scheduled jobs on the batch server, etc.).

The deployer then does not have to be the developer directly, but can be a trained and reliable member of the Operation team.

Use a test environment

The batch deployment process is also linked to the model of the environments used.
In addition to the development environment (DEV), the build batch environment (BUILD) and the production target environment (PROD), a test environment (TEST) is also necessary for the error-free delivery of the development to the customer.
The ideal is to have at least two test environments. One for testing batches pre-scheduled in TS and the other for deploying hotfixes. The second TEST should basically be a copy of the production environment.

Involve the customer in the deployment process

To avoid as much confusion and unnecessary conflict as possible, involve the customer in the approval and testing process of the ticketing system.

In order to avoid as much confusion and unnecessary conflicts with the customer as possible after deploying a batch to a production environment (but also to a test environment), it is important to set up the process so that the customer (his responsible key-user) is involved in the requirements approval and testing process.

The workflow settings in the TS used should then ensure that the batch can only be deployed to PROD when all related requests are in the "Tested and approved by customer" state.

In case of confusion, all the history for each request is clearly traceable in one place.

I believe that these tips will help you to achieve higher customer satisfaction and also to increase the efficiency of your team.

Vladislav Nový - Dynamics AX developer in the company Blue Dynamic with experience in managing developmental batch deployment.