Announcing buildThingsCraig SeymourJuly 20th 2018
Nathan Hawkins and Craig Seymour (two of our cloudThingers) introduced a set of VSTS build and release tools that they've been working on. We've been able to make them freely available on the VSTS Marketplace and to release the source on GitHub (under GPL), so this is a quick catch-up of the 'Things' we are offering...
We've had the go ahead from our lovely Board to make them freely available on the VSTS Marketplace and to release the source on GitHub (under GPL), so this is a quick catch-up for those who weren't at the meeting (Why not? Where were you?!) as well as an update for those that were.
There are several tool sets out there for automating parts of the process of releasing to CRM/Dynamics 365 (and now Common Data Service for Apps) and there are several manual tools that help fill in the gaps that the automated tools don't fill. But there is no easy way to do a full 'hands-off' deployment of a Solution to a target environment.
There are also some obvious gaps: there is no way to include Access Team Templates in a Solution, neither is there the ability to duplicate them from one instance to another or duplicate published Data Duplication Rules (that's not a tautology…). There are some less obvious ones too; for example, what happens if you have set a Plugin Step's Impersonation User to be a particular user, but that user doesn't exist in your target instance?
So, we decided to fill the gaps. We ploughed through our 'Manual Deployment' documentation and identified all the steps which could be automated and put in place VSTS tasks for each one.
We also decided that v1 of the tools should be aimed at allowing us to clone a known good 'master' instance to another instance - more on that later.
Microsoft provide a nice tool for migrating configuration data between instances - the appropriately named 'CRM Configuration Migration' tool. To date, it's always worked flawlessly for me, except for Duplicate Detection rules – we’ll come to that later…
However, if your configuration data is continually changing, there is quite a bit of clicking and waiting to rebuild the data file; and you need to move it between instances with different admin users, there is even more clicking about. Microsoft have provided PowerShell cmdlets to help automate deployment of configuration data files via the Package Deployer, but there are no tools to automate creating the configuration data file. The final nail in the coffin for us was that you can't choose which items to bring over - you must take all records in the entity.
You start off by specifying the name of the configuration entity and the view that contains the records and fields you want to copy over. After that, you can also choose whether toupsert, delete and create, or create only so that it creates new records in the target environment with the same GUID as the source.
It doesn't give ahootabout dependencies on other entities (cue the violin)- that part is up to you. Much like the MS tool, we've not (yet) paid much attention to what happens when you move large amounts of data, so don't use it for that!
Nathan would like you to be able to choose to specify FetchXML instead of a name and view.I'm not sure that's necessary. Only one of us will be victorious…
If we’re being honest, Duplicate Detection Rules are just really annoying. You can use the Configuration Migration tool, but it will only fetch unpublished rules. So, in the general case where you tested that they all work, you must then turn them off before you can export them. Consequently, our 'Configuration Data' tool doesn't then work because the Duplicate Rule Conditions entity doesn't have views.
The tool grabs all published duplicate detection rules and the associated conditions and creates them in the target with the same Global Unique Identifiers (GUIDs).
This one is interesting, trust me. You can move Word Templates simply by treating it as Configuration Data but as noted by Gayan Perera of Magnetism Solutions, the Word Templates reference the Entity Type Code, and this can change between instances. Tanguy Touzard has implemented a version of his code to fix that in XrmToolBox, and both have kindly agreed that we can re-use it as well.
The tool copies all the Word Templates from the source instance to the target, updating the embedded Entity Type Code if required.
As mentioned above, we have workflows with a specifically defined owner and in our case, the target can be in a different AD tenancy, and therefore, really doesn't exist… In this case the Solution Importer will default the owner to the user who is importing the Solution, which may be OK, or it may not. Similarly - plugin steps are set to run as a particular user:
The Solution importer considers that it’s worth taking the time to warn you about it, so you should give it some thought. We gave this behaviour some thought but decided that we didn’t like the cut of it which resulted in us creating a tool to fix it.
This tool looks for every plugin step/workflow in the source instance set to run as the specified user and sets the corresponding step in the target instance to be the user specified for the target. Simples!
The only planned changes that you may have would be to set the step to a designated user before then reverting it to simply run as the calling user, which we did. In light of this, we'd like to change the tool to see if the target step's designated user differs from the source and figure out which user to use instead.
Access Teams – these are tricky devils. You've enabled Access Teams on an entity, meaning you've created your templates and added a sub-grid to set the members.
However, you can't use the Configuration Migration Tool to move them and if you create them by hand they get a new GUID, so you have to go and re-bind the sub-grid to the template.
So what does our tool do? Our tool looks for all entities with an Access Team enabled, copies over the templates and creates them with the original GUID.
We have a situation with one customer where we've done an integration with the Google Maps API to show multiple addresses associated with an entity. However, they want to use a different Google API Key in each instance so that they can track which API Key is being used for what instance.
To start, we've defined the API Key as a record in our standard general purpose Configuration item (Group/Key/Value), and have given it a default ‘failover’ value in our master instance. Then for each environment we release into, we update the value to the one that is supposed to get used in that environment.
So, what does this tool do? Well, all you need to do is supply a fetchxml expression which retrieves the single record you want to update, the name of the field you want to update and the value you want to change it to. Currently the tool doesn't gracefully handle what happens if the fetchxml returns more than one record. Also, it seems to me that there could be a simpler version for which you could just specify the entity, record name/GUID, field and value. How easy would that be?!
We noticed that occasionally Business Rules were set in our target solution as a draft; we suspect a side effect of earlier failures in the deployment process was the reason for this becoming a draft, but regrettably we didn't keep the logs.
Very simply, this tool activates all Business Rules in the target (remember that we are 'cloning' our master solution, and we so far haven't had any requirements to keep draft Business Rules in our master).
The next steps for us are to do cosmetic fixes (proper logo, fixing Nathan's spelling mistakes …) and release them to VSTS and GitHub. Feel free to reach out to us on Twitter (@cseymr and @Dynamics365Man) if you have any questions in the meantime and we will be more than happy to assist!
Craig is one of cloudThing's CRM Solution Architects and Nathan is one of the Solution Architects at cloudThing, so you know you'll be in good hands!