Deploying customizations across Microsoft Dynamics AX environments

Today I would like to show how things are done right, it’s not XGH friendly, it takes some time to do things right but you can save a lot of trouble by deploying on the right environment with the right tools.

The following flowchart is the best to summarize this post:

Between Development and Test environment I would recommend a XPO to deploy customizations, it’s fast and simple but you have to Synchronize, Compile and generate Incremental CIL after that. Also it is not recommended if the project has many elements.

As the environment criticity grows, we should user other tools as model files and model store to avoid conflicts between Element IDs.

Between Test and Staging environments we should delete and then import specific model files from the respective layer. For example, if I made customizations on USR layer in the USR model, I will export it and then I will delete the USR Model on the Staging environment and then I will import it. Never forget to Synchronize, Compile and generate Incremental CIL after that.

Between Staging and Production environments, the best choice by far is to export the WHOLE Model Store from Staging, drop Model Store from Production and then import it. When we export the model store it comes with  all element IDs on the target system and because of that it is not necessary to Synchronize  or Compile after all!

Available Tools:

• XPO: A development artifact containing the metadata of one or more elements exported from the AOT. An XPO file is typically used to move metadata between developers. As I said before, this is the faster method to deploy between environments, but it’s recommended to use it only between development and test environment because of possible element ID conflicts and the file can’t be uninstalled, it has to be individually deleted.
• Model File: A model is a set of elements in a given layer. Each layer consists of one or more models. Each layer contains at least one system-generated model (Ex. USR, VAR). No element can belong to two models in the same layer, the top layer will always prevail, for example if I make a customization on CustTable it will exist on SYS and USR but only the code on USR will be valid. A model can be exported into a model file (.axmodel) by using either the AXUtil command-line utility or Windows PowerShell cmdlets as I have shown on previous posts.
• Model Store: The model store is stored in the Microsoft Dynamics AX model database and includes all of the application’s metadata – that is, all model elements, including customizations. This is perfect to deploy between staging and production environments because all element IDs on the target system become equal to the IDs stored in the model store file. Additional information about how to export/import model store can be found here.

Element IDs

It’s important to know what element IDs are because they are most times the source of many headaches you can have when deploying between environments.
When sharing metadata across environments, users must always consider Microsoft Dynamics AX element IDs. Microsoft Dynamics AX elements are associated with corresponding business data based
on their element ID. Element IDs are specific to each installation and are sometimes referred to as installation-specific IDs. In other words, the same method, class, or table may have a different element ID in different installations. When two Microsoft Dynamics AX environments share copies of the same business data (such as transaction, configuration, or master data), these environments also need to share the same element IDs. This is typical of staging and production environments. (MICROSOFT, 2013)

There is many more details which I recommend to read when you have a spare time, these details can be found on:
Microsoft Dynamics AX 2012 White Paper: Deploying Customizations Across Microsoft Dynamics AX 2012 Environments