AX Development Under Control

Do you often struggle in Microsoft Dynamics AX with issues around sharing objects on a single project between multiple developers?

Has the time and energy spent organizing the building and deployment of new batches of development to the customer's target environment become unsustainable?

Do you often find yourself sorting out ambiguities or bugs in deployed development directly with the customer?

If you answered yes to any of these questions, I have a few tips for you, based on my own many years of experience, on how to avoid situations like these.

Get Clear on What Kind of Development Environment Your Project Needs

For smaller projects, where only a handful of developers are involved and it's unlikely they'll frequently need to work on the same objects, a single shared development environment will do.

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

For large projects, again use the distributed development environment model, where each developer has their own environment that they regularly sync with a central repository (see below), and to which they also commit their own work — usually once a self-contained piece of it is finished.

Use Version Control

Using version control brings a range of benefits:

• Gives you a clear view of every change made to every object, and who made it and when
• Lets you attach a descriptive comment to every code change
• Makes it easy to quickly understand the history of any given object
• Significantly boosts communication efficiency within a team of developers working on the same project

The Microsoft Dynamics AX environment offers several ways to version each developer's code changes.

For the shared development environment model, you can use the version control built directly into AX (MorphX VCS).

In this case, when a developer starts working on an object they check it out, which prevents others from making changes to it. The object is only unlocked again once the developer has committed their changes to version control.

Use at least two test environments for every project — one for the main development branch, and another for hotfixes.

With the distributed model, before starting work you need to pull all objects on the local development environment from the global version repository. Developers can then work on the same object at the same time without issue. Conflicts in the code can arise, however, when work is committed back to the global repository. Most of these conflicts can be resolved automatically by the tool being used. When automatic resolution isn't possible, the developer has to resolve the conflict manually at that point.

A good example of a global repository tool is Team Foundation Server (TFS), developed by Microsoft, which among other things has a built-in ticketing system. This lets you view all code changes related to a given request in one place.

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

A batch/release management tool (hereafter RM — Release Management) significantly improves efficiency when building a new batch of development intended for deployment to a test or production environment. Besides a fast, error-free build, it also gives you a clear record of who built the batch, when, and which requests it contained.

Directly connecting RM with the ticketing system (TS) also prevents a lot of ambiguity and miscommunication between members of the delivery team.

From the outset, the TS clearly defines which requests should be included in a given batch.

The build process might then look like this:

• The person building the batch checks, by request number, that the request is in the correct state in the TS and that the development version for each request has been committed in RM (ideally RM has automated support for this check).
• If everything checks out, they build the new batch in RM. Before doing so, they send an informational notice by email to the customer and selected team members with all the necessary details — especially about the need to restrict traffic on the target environment during deployment. A dedicated BUILD environment is used to build the batch.
• Ideally, the delivery team has PowerShell scripts ready that script out the sequence of steps for deploying the batch all the way to the target environment. A simplified example of such a sequence might be: AOT compilation, Full CIL compilation, model store export, stopping the target AOS instances, model store import, Data Dictionary synchronization, restarting the target AOS instances, and sending an email to the customer and other stakeholders confirming the successful deployment of the new batch.

Distinguish Between Building a Batch and Deploying a Batch

If the deployment process for a built batch can't be fully automated, don't leave the entire build-and-deploy process to one person. Since deployments often happen at night, splitting the roles reduces the risk of errors.

It's best to have someone from the team of programmers working on the project build the batch. They're able to resolve any ambiguities related to the committed code, and can clearly summarize any additional technical information the deployer needs for that particular deployment — such as the need to run initialization jobs after deployment, or changes to scheduled job settings on the batch server, and so on.

The person performing the deployment doesn't have to be a developer — it can be a trained, reliable member of the Operations team.

Use Test Environments

The batch deployment process is also tied to the environment model you use.
Besides the development environment (DEV), the build environment (BUILD) and the target production environment (PROD), a test environment (TEST) is essential for handing development over to the customer error-free.
Ideally you should have at least two test environments — one for testing batches already planned in the TS, and another for deploying hotfixes. The second TEST environment should essentially be a copy of production.

Involve the Customer in the Deployment Process

To avoid as many ambiguities and unnecessary conflicts as possible, involve the customer in approving and testing requests within the ticketing system.

To minimize ambiguities and unnecessary conflicts with the customer arising after a batch is deployed to production (or even to test), it's important to set up the process so the customer — represented by their responsible key user — is involved in approving requests and testing.

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

If any ambiguity arises, the full history for each request is clearly traceable in one place.

I hope these tips help you achieve higher customer satisfaction and greater efficiency within your team.

Vladislav Nový — Dynamics AX developer at Blue Dynamic with experience managing the deployment of development batches.