CI/CD & Test Automation for Dynamics 365 in Azure DevOps/VSTS -Part 5 – Master Data Deployment
In my previous blog, I wrote about how to set up a gated check-in, In this blog, we will see how to move the master data from source to target instance using our CI/CD pipeline.
Generally, we use the configuration migration tool to move the master data across multiple environments and organizations. Configuration data is used to define custom functionality in model-driven apps in Dynamics 365, such as Dynamics 365 Sales and Customer Service, and is typically stored in custom entities. Configuration data is different from end-user data (account, contacts, and so on). A typical example of configuration data is what you define in the Unified Service Desk for Dynamics 365 to configure a customized call center agent application. The Unified Service Desk entities, along with the configuration data that is stored in the entities, define an agent application.
Note: Disable plug-ins before exporting data and then re-enable them on the target system after the import is complete for all the entities or selected entities.
Define the schema of the source data to be exported: The schema file (.xml) contains information about the data that you want to export such as the entities, attributes, relationships, definition of the uniqueness of the data, and whether the plug-ins should be disabled before exporting the data.
Use the schema to export data: Use the schema file to export the data into a .zip file that contains the data and the schema of the exported data.
Import the exported data: Use the exported data (.zip file) to import into the target environment. The data import is done in multiple passes to first import the foundation data while queuing up the dependent data, and then import the dependent data in the subsequent passes to handle any data dependencies or linkages.
Instead of moving it manually we are going to automate this above process using Azure DevOps.
Please make sure the latest configuration.xml(generated using DataMigrationUtility.exe tool) is generated and placed in the desired input location.
Please make sure we have updated the variables (correct connection string, CRM username, CRM password) in both the VSTS build and release definition.
We have to create a separate Build Definition for moving the master data from source to target instance. Once the solution movement is done this below build definition should trigger.
In my previous blog, I have explained how to create a new build definition. Please refer to that for creating a new build definition.
What will do – It will connect to the source instance and export the master data using the configuration.xml and push it to artifacts repository
In this Build Definition we have used the following MSCRM Build Tools tasks:
MSCRM Tool Installer – Installs the Dynamics 365 tools required by all of the tasks
MSCRM Export config migration data – Exports data from a CRM instance using a Configuration Migration schema file (How to prepare configuration schema file).
You have to update the connection string variable name and select the configuration.xml input location.
Publish build artifacts – Publish build artifacts to Azure Pipelines
Once the above definition gets succeded, this Release Definition will trigger automatically and performs the following tasks:
MSCRM Tool Installer – Installs the Dynamics 365 tools required by all of the tasks
MSCRM Import config migration data – Import data exported using Configuration Migration Tool into a CRM instance
You have to update the connection string variable name and select the exported data zip from the artifacts repository(drop).
This will import the master data/configuration data into our Dynamics Online sandbox instance.
In my next blog, we will see how to integrate the unit testing framework with the VSTS Build definition.
If you are interested in this topic and would like to do some further self-study I encourage you to check out my blog on this.
