Update: Building buildThings for Dynamics 365 & VSTSCraig SeymourMay 14th 2018
At the last CRMUG at the Microsoft offices in in Thames Valley Park, Reading, UK, Nathan Hawkins and I introduced a set of VSTS build and release tools that we’ve been working on. In the time since that meeting, 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...
At the last CRMUG at the Microsoft offices in in Thames Valley Park, Reading, UK, Nathan Hawkins and I introduced a set of VSTS build and release tools that we’ve been working on.
In the time since that meeting, 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.
buildThings is the name for all the free, open source tools or add-ons that we produce at cloudThing for expediting continuous delivery. buildThings is a continuous investment by cloudThing and is intended to allow staff here to spend time working on projects they think would be useful for the wider tech community. With that in mind, we will be giving these away to the tech community in the hope it saves someone (somewhere!) some time. We’re going to be expanding buildThings into other technologies that others in the company work with going forward, but we are focusing on D365 and VSTS for now.
There are several toolsets 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?
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.
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 to upsert, 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 a hoot about 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…
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.
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!
You may have 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.
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.
Put simply, you 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?!
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.
This tool grabs all published duplicate detection rules and the associated conditions and creates them in the target with the same Global Unique Identifiers (GUIDs).
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.
Our tool looks for all entities with an Access Team enabled, copies over the templates and creates them with the original GUID.
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.
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).
Here’s an example of the end result, taken from a real customer environment.
You’ll notice that we’re using a couple of tools from Wael Hamze’s excellent xRM CI Framework – they don’t quite do what we want yet, so we plan to fork them or contribute back to them if the changes we want to make aren’t too specific.
The next steps for us are to do cosmetic fixes (proper logo, fixing Nathan’s sppellign 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!