Automated deployment has always been a bit of a problem in the Dynamics world to say the least, and, of course, we hit exactly the same walls while working on the most recent project. Here is what we came up with – you might (or might not) find it useful..
In the core of this approach is the idea of “packages”. Apparently, it’s been around for a while in different forms, but have a look at the diagram below:
In the package preparation step, we are aiming to define the package as a set of solutions, data, and corresponding actions.
Our Build step is all about converting that definition into something that can be later deployed into the target Dynamics environment.
And in the Deploy step we are actually doing the deployment.
Imagine that you’ve done it for one package, then for another, etc. And, then, imagine that you have at least 3 environments:
Dev – UAT – Prod
Ideally, you should have more, but it’s another story.
So, you keep preparing the packages in Dev and deploying them packages to UAT. You’ve done it for the first one, for the second one, etc.
At some point, you want to bring production up to date.
You already have packages, so all you need to do is repeat the same deployment steps – deploy the first package to production, deploy the second one, and so on until your production environment is up to date. As you are deploying each of the solutions, you also need to repeat the same actions (run data migration workflows, delete attributes and entities, etc)
There are different tools in the SDK that seem to be doing part of what we need (Configuration Migration tool, solution packager, package deployment..), but there is always something missing there. For example, Configuration Migration tool does not seem to be able to export team roles, yet data export cannot be fully automated – the data package has to be prepared manually.
So I came up with another tool – it’s on GitHub:
https://github.com/ashlega/ItAintBoring.EZChange
It’s a windows application that you can compile in Visual Studio and run.. Though don’t expect a commercial-grade product at this point. Some things are simply missing – at the very least, I still need to add progress bar indicators
However, here is what you can do with that tool so far.
1. Create a package and save it to a file. Save all your packages to the same folder – this will allow the tool to run those packages to various environments as required. Every package can use variables (this is how you can run the same package to different environments without having to update the connection strings in the package itself. Variables are stored in a separate file)
2. Add solutions to the package(can be solutions from the source environment or from a file) and define different actions for each solution
3. Build the package – for now, at least, orderedpackages.txt file and variables.xml file have to be created manually
4. Run the package from the UI or from the command line
If running from the UI, use Build->Run option to run the current package.
If running from the command line, use the following command:
ItAintBoring.EZChange.exe <Path to the packages folder> <Environment Name>
5. You can define the order of your packages in the orderedpackages.txt file:
6. You can define environment-specific variable values in the variables.xml file:
7. As for the available actions, here is what’s in there so far:
– Export data (it’s a build –time action which will use FetchXML to export data from the source)
– Import data (it’s a run-time action which will import data to the target environment)
– Workflow action (run-time action to run a workflow on a set of records identified using FetchXML)
– Metadata action (run-time action to delete attributes/entities/workflows/etc)
– Deploy solution action (run-time action to actually deploy a solution)
8. The tool is extendable
Even though the code is on GitHub, you don’t always have to modify the base code. For example, if you realize that you need more “actions”, you can create a new .NET dll, implement a class that’s inherited from BaseAction in that dll, put that dll into the “Extensions” subfolder, and the tool will pick it up next time you run it. That’s how the “Core” pack covering Dynamics is implemented anyway.