Recently a fellow D365 developer, Lars Müller, wrote an article on how to Build a versioned XrmToolBox plugin.
I am taking this one step further, to show you how to create a complete CI/CD pipeline for your XrmToolBox tools.
Of course, the primary reason for creating an automated pipeline for Continuous Integration / Continuous Deployment is to standardize versioning, naming, and any other metadata about your tools. In addition to that, automated tests are performed during the build which will highlight any possible new bugs or vulnerabilities in your code.
This may seem like quite a long article, but all the steps are really simple and a lot of them are probably already in place for you, and there are a lot of nice pictures too.
1. Set up VSTS
Everyone should have their own VSTS tenant. It just makes life so much easier.
Go to visualstudio.com and register your own playground, if you don’t have one already.
Enter an existing Microsoft account to log in, or create a new.
Then you need to come up with a unique tenant name.
Then you can create a new project to host your builds and releases, or use an existing.
2. Prepare Build definition
In your VSTS tenant, go to Build and Release, and create a new Build definition.
Connect to source
First you need to select source for the build, which probably is GitHub (since all our awesome XrmToolBox tools are open source, right? 😉 )
Enter credentials for your GitHub account to authorize VSTS to access the code to build.
3. Customize Build definition
Now it’s time to start customizing the build definition for our needs.
As XrmToolBox plugins are published as NuGet packages, let’s add a NuGet Pack task after build and tests have been completed.
As the only artifact we are interested in is the NuGet package, update task Copy Files to: $(build.artifactstagingdirectory) with the highlighted settings. In this case I am not specifying the exact file name, I don’t really know the sub folder structure that is the result of the build and pack, so I make it easy for myself. I just know it will be the only file containing
LCG and ending with
For my own tools, I follow the versioning topology that Tanguy himself uses:
Pattern: 1.yyyy.mm.nn Example: 1.2018.5.3
The example above would mean the third build in May 2018.
To tell the build definition to use this topology, go to tab Options and edit the Build number format.
4. Prepare your tool
Experience has taught me a few things to remember when creating tools for XrmToolBox. These will make the delivery process smoother, and your tool more stable and less prone to interfere with other tools.
Yes, in the world of Dynamics 365 we often have to merge assemblies. We don’t like it, some refuse, some find other solutions.
But for your XrmToolBox tools that rely on assemblies not part of .net framework, CRM SDK or the XrmToolBox package, please ILMerge them into your assembly.
More than once, my tool has stopped working after some other tool with another version of the same dependency was installed, and vice versa.
For proper exposure of your tool, make sure you get the details of the NuSpec file correct.
<package > <metadata> <id>Rappen.XrmToolBox.TheCoolestTool</id> <version>1.0.0</version> <title>The Coolest Tool for XrmToolBox</title> <authors>Jonas Rapp, Sweden</authors> <owners>rappen</owners> <projectUrl>https://github.com/rappen/TheCoolestTool</projectUrl> <iconUrl>https://raw.githubusercontent.com/rappen/TheCoolestTool/master/images/LCG-150-transp.png</iconUrl> <requireLicenseAcceptance>false</requireLicenseAcceptance> <description>An XrmToolBox plugin to do extremely cool things in Microsoft Dynamics 365/CRM.</description> <summary>An XrmToolBox plugin to do extremely cool things in Microsoft Dynamics 365/CRM.</summary> <releaseNotes> * Improved Awesomeness * Azure integration deluxe </releaseNotes> <copyright>Copyright 2017-2018 Jonas Rapp</copyright> <tags>XrmToolBox Plugins TheCoolestTool</tags> <dependencies> <dependency id="XrmToolBox" version="1.2017.10.19" /> </dependencies> </metadata> <files> <file src="bin\Release\Rappen.XTB.TCT.dll" target="lib\net452\Plugins" /> </files> </package>
Note that the
version specified on line 4 can be anything, as version will be set during the build.
Make sure the
description are relevant, as they are presented in the Plugins Store of XrmToolBox, and cannot be changed on NuGet once the version is uploaded.
5. Build it!
When all code is committed, fire up a new build!
You do this by selecting Queue new on the build definition.
You can now investigate the artifact created, to verify the build.
Go to the build just created, Artifacts, Explore, and then Download the nupkg file.
6. Release the tool
In this tutorial I have separated the Build process from the Release process, as I like to be able to verify the build before going public.
Create Release definition
To create a Release definition to publish the created NuGet package, start with an empty process.
Verify the highlighted fields below.
To authenticate VSTS to your NuGet account, click the New button. Open a new tab in your browser, go to https://nuget.org and log in with your account. Go to the API Keys section under your profile.
The key that is generated will not be possible to find again, so make sure you copy it and store it in a safe place. Also, paste it into the API Key field in the new NuGet endpoint form. Add a name for the endpoint, and the url to the NuGet API.
Save the release definition and click the button to create a new Release.