AX Development Under Control

Do you often struggle with sharing objects among multiple developers on the same Microsoft Dynamics AX project?

Is the time and energy spent on organizing builds and deployments to the customer’s target environment becoming unsustainable?

Do you frequently resolve ambiguities or bugs in deployed development directly with the customer?

If you answered yes to any of these questions, here are several tips from my long-term experience on how to avoid such situations.

Define the Right Type of Development Environment for Your Project

For smaller projects with a limited number of developers, where it’s unlikely that multiple people will work on the same objects simultaneously, a single shared development environment can be sufficient.

For larger projects, use a distributed development environment model combined with Team Foundation Server.

For large projects, use a distributed development model where each developer has their own environment, regularly synchronized with the central repository (see below). Developers then submit their completed work back to the repository once they’ve finished a defined part of development.

Use Version Management

Version control offers many benefits:

• It provides a complete record of every change to each object, including who made the change and when.
• It allows you to document the purpose of each code modification.
• It helps quickly understand the historical evolution of each object.
• It improves communication efficiency among developers working on the same project.

The Microsoft Dynamics AX environment offers several options for versioning code changes made by each developer.

For shared development environments, you can use the built-in version control system (MorphX VCS) integrated in AX.

In this case, a developer reserves an object before editing it, preventing others from making changes until it’s checked in. Once submitted to version control, the object is unlocked again.

Use at least two testing environments for each project: one for the main development branch and one for hotfixes.

In a distributed setup, all objects must first be refreshed from the global repository before development begins. Developers can then work on the same object independently. When changes are submitted, code conflicts may arise — most can be resolved automatically by the tool, but some require manual resolution.

A suitable global repository is Microsoft’s Team Foundation Server (TFS), which also includes an integrated ticketing system, allowing you to link all code changes to specific requests.

Use a Release Management Tool, Ideally Integrated with a Ticketing System

A release management tool (RM) significantly improves the efficiency of building new deployment packages for testing or production environments. Beyond fast and error-free builds, it provides full transparency on who built the release, when, and which requests it contained.

Integrating RM with a ticketing system (TS) helps prevent many misunderstandings and miscommunications within the delivery team.

At the start, the TS clearly defines which requests are to be included in each release.

The build process can then follow this sequence:

• The builder verifies in the TS that each request is in the correct status and that the development version for each request has been submitted to RM (ideally, this check is automated).
• If everything is in order, they build a new release in RM. Before doing so, they send an informational email to the customer and team members with key details — including any downtime required during deployment. The build is created in a dedicated BUILD environment.
• Ideally, the delivery team has prepared PowerShell scripts that automate the deployment sequence. A simplified example might include: AOT compilation, full CIL compilation, model store export, stopping target AOS, importing model store, data dictionary synchronization, restarting AOS, and emailing stakeholders about successful deployment.

Differentiate Between Building and Deploying a Release

If full automation of the deployment process isn’t possible, avoid assigning both build and deployment responsibilities to one person. Since deployments often happen at night, splitting roles reduces the risk of errors.

It’s best for a developer from the project team to handle the build. They can address any code-related issues and provide clear technical notes for deployment, such as initialization jobs or changes to batch server settings.

The deployment itself can then be handled by a trained and reliable member of the Operations team, not necessarily a developer.

Use Testing Environments

The deployment process also depends on the environment model. In addition to the development (DEV), build (BUILD), and production (PROD) environments, you must also use testing environments (TEST) to ensure flawless delivery. Ideally, maintain at least two test environments — one for planned releases and another for hotfixes. The second TEST should closely mirror the production environment.

Involve the Customer in the Deployment Process

To avoid misunderstandings and unnecessary conflicts, involve the customer in approving and testing requests through the ticketing system.

To minimize post-deployment issues on production (and even test) environments, it’s essential that the customer’s key user participates in request approval and testing.

The workflow in the TS should ensure that deployment to PROD is only possible once all related requests are in the “Tested and approved by customer” state.

In case of disputes, the full history of each request remains clearly traceable in one place.

I believe these tips will help you improve both customer satisfaction and team efficiency.

Vladislav Nový – Dynamics AX Developer at Blue Dynamic, experienced in managing development release deployments.