I have put together a combination of scripts, tools and extensions to get the Dynamics “solution” under version control as well as incorporate continous integration (CI) and continous deployment (CD) using Visual Studio Team Services (VSTS).

Hopefully this post is helpful to others who wish to sprinkle some DevOps on their Dynamics 365 development, if you have any suggestions or ideas please feel free to share them in the comments below.

Note with the release of Dynamics 365 (online), version 9.0, the Microsoft Dynamics CRM SDK will no longer be available as a download.  The new name of the SDK, as it was known will be the Microsoft Dynamics 365 Customer Engagement Developer Guide.  SDK assemblies and tools will be distributed only via NuGet.
read more

Tools used for this post

• Visual Studio 2017 (15.7.5)
• Visual Studio Team Services (VSTS)
• Dynamics 365 (online)
• Microsoft Dynamics CRM SDK Templates extension
• PowerShell
• SolutionPackager tool
• Dynamics 365 Build Tools by Wael Hamze

Here is a little bit of information regarding the environment.  We are using Dynamics 365 (Online) v8.2 and VSTS for version control, build and deployment.  I am using Visual Studio 2017 with the Microsoft Dynamics CRM SDK Templates extension installed.

Microsoft Dynamics CRM Package Deployer Tool Project Template

I have also deployed the Dynamics 365 Build Tools into our VSTS Organization so the tasks are available for all Build and Release Definitions.

Organization Settings | Extensions

Our solution consists of a CRM Deployment Package project which is used as a container for the extracted files and folders of the solution.  In this case it’s named PkgFolder/ForQA.  It should be noted we are not using this project as it was originally intended (using the CRM Package Deployer) but you’ll see more of that as we get further along.

Solution Explorer – CRM Deployment Package Project

Use Source Control with (Dynamics 365) Solution Files

We added a Scripts folder to the project which contains some PowerShell scripts and folders for tooling from the Developer Guide (SDK).  The process followed by the developer is essentially these steps (pictured below), the two steps in the middle are handled by the ExportAndExtractSolution.ps1 script:

• Developers’ benefit using this process by making the solution deployment repeatable and predictable.
• Developers can associate their work items with their check-ins
• Very useful for tracking changes (traceability) and comparing solution files

ExportAndExtractSolution.ps1 – This PowerShell script connects to Dynamics where the developers are customizing their solution, downloads the zip file to the developers workspace and extracts the Unmanaged solution into the PkgFolder/ForQA folder.  The CoreTools folder contains the SolutionPackager tool from the Dynamics CoreTools NuGet package (pictured below)

Microsoft.CrmSdk.CoreTools NuGet Package

The developer opens a PowerShell command prompt and changes directories to the Scripts folder in the CRMPackageDeployment project where the ExportAndExtractSolution.ps1 script is located and then executes the script.  SolutionPackager is run as part of the script with the following options /action:Extract /zipFile:$crmSolutionFile /folder:$crmSolutionExtractPath /clobber /allowDelete:Yes /allowWrite:Yes /errorlevel:verbose 

ExportAndExtractSolution.ps1

This has pulled down the solution zip file named ForQA from the Dynamics instance and extracted it into the developers workspace.

The developer now has some manual steps to perform depending on the files/changes that were extracted from the solution:

1. Include any new file under the extracted folder PkgFolder\xxxx (extracted) into the project (so that they can be checked-in).
   NOTE: When doing the check-in, be sure to check the ‘Excluded Changes’ if additional files were detected and promote them to the
   ‘Included Changes’ as needed.
2. For any .xaml file (under PkgFolder\xxxx\Workflows or PkgFolder\xxxx\Entities\xxxx\Formulas), make sure that Build Action is ‘None’ (not ‘Page’ or ‘XamlAppDef’). If this step is skipped, you may get one of these compilation error(s):
   – Project file must include the .NET Framework assembly ‘WindowsBase, PresentationCore, PresentationFramework’ in the reference list.
   – Assembly ‘System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ can not be resolved.
3. Ensure that DLL files under PkgFolder\xxxx\PluginAssemblies are added to source control.
4. Undo all pending changes that do not specifically apply to your changes.
5. Associate the check-in with a work item(s), write a comment and check-in all required changes.

Here is an example of files that need to be added as part of the project, I have used the solution explorer toolbar button to Show All Files.  Right click on the files which are not part of the project file and select Include In Project.

Solution Explorer | Show All Files

Once included make sure for any .xaml files added to the project (pictured below) you change the Build Action from XamlAppDef to None.  If any new Entities were added/changed make sure you include those new folders under Entities folder.  If any files have been removed from your project (pictured below) after the SolutionPackager tool was run you will see an yellow exclamation symbol to the left of the filename, right click on those files and either delete or exlude them from project (they’ve been deleted).

It is important to make sure you haven’t missed any files to ensure they get added to version control otherwise you risk dependency errors importing your solution or missing objects in the target system.  We build this project on the server and create the Dynamics solution but the dependencies are not completely validated until the solution is imported into Dynamics Online.  I’m toying with the idea to perform a test import into Dynamics to pass/fail the build but at the moment I do not do this.

Team Explorer | Pending Changes

VSTS Build Definition

Once the developer checks-in the changes, we have a Build Definition in VSTS which is triggered to execute.  Here is that Build Definition

Dynamics 365 CI Build Definition

A few things I should point out.  The NuGet tasks are required to process the NuGet package references in the CRMDeploymentPackage project.  We use the Visual Studio Build task to build the CRMPackageDeployment solution, the MSCRM Pack Solution task creates an Unmanaged solution from the files in PkgFolder/ForQA within that project and we output the Zip file in the PkgFolder of the project.  The Copy task copies all files in **\bin\$(BuildConfiguration)\** to the $(Build.ArtifactStagingDirectory), we then Publish the Artifact.

In the MSCRM Pack Solution task we have selected the Update Version checkbox which requires us to specify the Build Number Format under Options in the Build Definition, make sure you don’t forget to include the *underscore* as it is expected.  Here is an example of my build number format $(BuildDefinitionName)_$(MajorVersion).$(MinorVersion).$(Year:yy)$(DayOfYear)$(Rev:.r) from the build definition above.

After the build executes we can take a look at the published artifacts to see the solution zip that was created.

Artifacts Explorer

You have the option in the MSCRM Pack Solution task to treat warnings as errors if you like by selecting the Treat Warnings as Errors checkbox under the Output Path if you wish to be more strict.

VSTS Release Definition

If your AAD Administrator has enabled 2FA on your organization accounts, make sure you generate an App Password for the account you are using in the CRM Connection String otherwise it will simply fail (so many wasted hours).  In the Release Definition we use the following MSCRM tasks:

• MSCRM Import Solution
• MSCRM Publish Customizations

Release Definition Tasks

This will import our solution file and then publish the customizations to our Dynamics Online sandbox instance.

Agent Phase

MIcrosoft has also provided some DevOps samples for Dynamics 365 CE with VSTS over on GitHub by Marc Schweigert a Principal Program Manager.  You’ll also find a sample of UI Automation Testing with Dynamics using EasyRepro.  It’s currently using PhantomJS but may work with Chrome in Headless mode so you can execute your UI tests during a VSTS release (I have not had a chance to verify).

Here’s a code snippet of a simple “headless” selenium test using the Chrome WebDriver under Windows.

ChromeOptions options = new ChromeOptions();
options.AddArguments(“–headless”, “–disable-gpu”, “–window-size=1200×900”);
driver = new ChromeDriver(options);
string keywords = “français”;
WebDriverWait wait = SearchGoogleWithText(driver, keywords);
Assert.IsTrue(wait.Until(x => x.Title.Contains(keywords)));