Running Dynamics 365 Configuration Data Mover jobs in VSTS builds

Lucas Alexander — Tue, 12 Sep 2017 12:00:00 GMT

In today's post I will show how to use my Dynamics 365 Configuration Data Mover utility for synchronizing configuration data between CRM orgs as part of a Visual Studio Team Services build.

Download the latest version of the Configuration Data Mover utility's CLI tool from my repository on GitHub here: https://github.com/lucasalexander/AlexanderDevelopment.ConfigDataMover/releases.
Any version from 2.2 onward should work, and make sure you get the "AlexanderDevelopment.ConfigDataMover.Cli.zip" file.
Extract everything from the zip archive and add the entire directory to your source code repository. I have historically used a "tools" directory that contains various utilities, so I keep the Data Mover CLI tool in its own subdirectory there.
Add a directory to your source code repository to hold configuration data mover job files and JSON data extracts. I call mine "data."
Set up a data mover job using the GUI tool. You can create a job that syncs data between two CRM orgs or a job that reads from a file source. I prefer to use file sources for deployments because then I don't have a dependency on the development org, and also the configuration data can be kept under source control. You can also save your connection parameters in the job file or pass them to the Data Mover at run time.
After you create and test your data mover job, save a copy of the XML job file to your source control "data" directory.
(This step is only required for file sources when you are saving the connection parameters in the job file.) Open the XML file in a text editor and find the node toward the bottom. There will be a "source" attribute that you need to make sure is set to a relative path to the JSON data file from the location of your AlexanderDevelopment.ConfigDataMover.Cli.exe assembly. Because of how I have my directory structure set up in source control, the a JSON file named "alm-test.json" has "....\data\alm-test.json" as its relative path. Here's a screenshot of my directory structure for reference:
Commit your changes to your VSTS instance. I am using Git, but this should work for TFS, too.
Create a new build and add a batch script step.
Configure the batch script step to run the AlexanderDevelopment.ConfigDataMover.Cli.exe assembly you pushed to source control in step #7.
Set the arguments to include the relative path to your job configuration file. For this example, it is -c ....\data\alm-test-import.xml
(This step is only required if you are not saving the connection parameters in the job file.) Add source and target arguments, too. The source argument is -s, and the target argument is -t. The values will look just like the source/target attributes from a job configuration file where you have saved the values.
Set the working folder value to the directory that contains the AlexanderDevelopment.ConfigDataMover.Cli.exe assembly. You can see that setting in the screenshot above.

At this point you should be able to save and queue the build. Assuming everything is set up properly, you should get a nice result like this:

If you do get an error, it's probably something simple like the paths not being set correctly, and a quick review of the output logs should point to the solution.

That's all there is to it. Are you using automated builds in VSTS for your Dynamics 365 projects? Do see value in managing configuration data like this? Share your thoughts in the comments!

Unit testing Microsoft Dynamics CRM code

Lucas Alexander — Fri, 01 Apr 2011 00:00:00 GMT

If you're developing code that runs against Dynamics CRM, you know you should be testing it, right? As a developer first and foremost, I always believed that tests and documentation got in the way of the important - and more fun - stuff, but as I transitioned into a management role with responsibility for my company's Dynamics CRM system, I began to appreciate the value of the less-fun stuff.In this post I'll give you an overview of our continuous integration environment and offer a conceptual example of how to unit test your CRM code without having to execute tests against a running CRM system.Our full build and unit testing process used the following:

NAnt for builds
NUnit for unit tests
Subversion (SVN) for version control
CruiseControl.NET (CC.NET) for continuous integration
Rhino.Mocks for mock object framework

Whenever a developer made a commit to SVN, CC.NET would execute the correct NAnt build target (different ones for production, testing, etc.), then it would run the NUnit tests. The results of the build (broken/successful) and the results of the NUnit tests were all reported through the CC.NET web interface so you could see a historical view. CC.NET also has a desktop notification app that is green when all builds are good or red when all builds are bad that you can use to easily check up on your development team.

Originally our NUnit tests ran against our CRM staging server and staging database, but we found that it was a problem keeping the staging system populated with "real" data, and our staging system was underpowered, so unit tests took a long time to execute. We solved this by using Rhino.Mocks to setup a mock CRM framework to verify that our code would send the correct calls to CRM without actually having to make the calls against an actual system.

Here's a conceptual example from version 4, but it will work similarly in 2011. Let's say we want to test code that deactivates an account. First, the test method sets up a mock object to represent the CRM service. Second, we set up an object to retrieve the setstate request object that the production code will pass to CRM. Third, the test method runs the production code against the mocked CRM service and captures the request object. Finally, we test the properties of the request object using an Assert.AreEqual call.

If you're ready to dig into the technical details of Rhino.Mocks + CRM, take a look at this excellent blog post with code samples: http://www.develop1.net/public/post/Unit-Testing-Dynamics-CRM2011-Pipeline-Plugins-using-Rhino-Mocks.aspx.

continuous integration - Alexander Development

Running Dynamics 365 Configuration Data Mover jobs in VSTS builds

Unit testing Microsoft Dynamics CRM code