Chapter 8. DevOps

In this chapter, we will cover the following recipes:

• Exporting Dynamics 365 solutions using PowerShell
• Deploying solutions using PowerShell
• Building a solution hierarchy
• Patching a solution
• Staging a solution
• Using SolutionPackager to save solutions in source control
• Packaging your solution with configuration data using PackageDeployer
• Triggering builds on solution version increments
• Integrating your deployment cycles with Octopus Deploy

Introduction

DevOps has been a buzz word for quite a few years now. Many platforms have embraced the discipline and integrated it within their development life cycle. Over the years, Dynamics CRM/365 followed the trend and kept the platform modern and up to date. The introductions of solutions in CRM 2011, the introduction of the SolutionPackager and PackageDeployer, and the Microsoft.Xrm.Data.PowerShell extensions are all examples of baby steps to support the DevOps story. Some of these tools were spawned out of the necessity to support new features (for example, AppSource) with Microsoft repurposing some of its own tools for generic reuse by the public.

The recipes in this chapter will cover a few DevOps fundamentals, such as solution exports and imports, bundling configuration data with solutions, source control integration, and deployment orchestration. Stitched together, you will end up with a strong DevOps story to tell.

The following diagram depicts a development life cycle with the...

Exporting Dynamics 365 solutions using PowerShell

Ever wondered whether you can write a script to automatically export a solution from one instance of Dynamics 365 and import it into another instance? The answer is yes; all you need is Microsoft.Xrm.Data.PowerShell.

The Microsoft.Xrm.Data.PowerShell extensions are created and maintained by the Microsoft staff. The two main contributors are Kenichiro Nakamura from Microsoft Japan and Sean McNellis from Microsoft corporate US. The extensions are wrappers around the Dynamics 365 SDK capabilities to enhance the platform's PowerShell scripting capabilities.

In this recipe, we will learn how to script a solution export from Dynamics 365 into the filesystem. This recipe is the foundation for later automation, discussed in this chapter to integrate with source control, to import solutions, and more.

Getting ready

As described in the introduction, the Microsoft.Xrm.Data.PowerShell extensions are required to run the script, which require PowerShell x64...

Deploying solutions using PowerShell

Similar to the export capabilities, the Microsoft.Xrm.Data.PowerShell commands also offer solution import capabilities using Import-CrmSolution.

This recipe will cover the PowerShell commands to import a solution into Dynamics 365.

Getting ready

Similar to the previous recipe, you will need to install the Microsoft.Xrm.Data.PowerShell module. Check the previous recipe for details on how to install and the prerequisites.

From a Dynamics 365 perspective, you will need the System Customizer or System Administrator role to import solutions into your instance.

Obviously, we'll need a solution to import. In this instance, we'll use a managed version of the solution exported in the previous recipe.

How to do it...

1. Run the Connect-CrmOnlineDiscovery -InteractiveMode command and follow the prompt to connect.
2. Run the following command:

Import-CrmSolution -SolutionFilePath Packt_managed_0_0_0_1.zip -PublishChanges

How it works...

As in the previous recipe, in step 1, we connected...

Building a solution hierarchy

The introduction of solutions in Dynamics CRM 2011 significantly simplified promoting your configuration and customization from one SDLC environment to another.

Solutions can be used to create hierarchies of dependent solutions, each containing a subset of your components. Separating solutions simplifies deployments by turning large-scale deployments into a collection of smaller deployments.

In Chapter 2, Client-Side Extensions, we created a JavaScript concurrency library that we bundled within the Packt solution. We then hooked the library with the OnLoad event on the contact form. Recognizing that the concurrency library can be leveraged and reused in other entities, or even other implementations, it is wise to separate it into its own solution. The Packt Common solution created in this recipe will house any reusable common libraries or customization to easily transport them between implementations without worrying about any components that are dependent on...

Patching a solution

Up until Dynamics CRM 2015, releasing a solution was a big task. Before solutions (CRM 4.0 era and before), System Customizers had to pick and choose what to promote to the next environments. Most included all customizations to avoid leaving anything behind. Solutions were introduced in CRM 2011 and have been improved over the years. Most notably, with CRM 2016, the concept of patching was introduced. Instead of releasing your entire solution, which might introduce a risk to your deployment, you can now narrow a release to the minimum required. Your patch, for example, might include an updated view, additional fields, or an updated form.

In this recipe, we will patch our Packt base solution and include an updated field along with an updated form.

Getting ready

In order to patch a solution, you will need the base Packt solution (or equivalent) already set up in your environment. The Packt solution has been used throughout the book; however, you can simply create a new solution...

Staging a solution

The capability to stage managed solutions was introduced in Dynamics CRM 2016. One of the problems addressed by staging is deleting components bundled in a managed solution.

In the past, to delete managed solution components, you had to introduce a holding solution (holding solutions are intermediary solutions that look like the final solution (with the deleted components) but they keep the schema (and the data) intact). The original solution was then deleted, and then the updated managed solution was reimported, followed by the holding solution removal.

The steps were cumbersome but unavoidable. The introduction of staging allows you to resolve the same problem addressed by two steps: stage and upgrade.

This recipe focuses on the steps required to stage a solution followed by its upgrade.

Getting ready

First, you must have an existing managed solution installed on your instance.

Note

Staging solutions only works on managed solutions.

When you try to import a newer version, the...

Using SolutionPackager to save solutions in source control

In this recipe, we will focus on storing a fragmented Dynamics 365 solution in the source control. More specifically, we will be using SolutionPackager to extract a Dynamics 365 solution into a folder that is Git initialized. We will then export an updated solution that had some components removed and demonstrate how the items will be removed from source control.

SolutionPackager is a utility introduced with Dynamics CRM 2013. It allows you to explode a Dynamics CRM\365 solution into small fragments. SolutionPackager also allows you to implode the extracted files back into a zipped solution file.

We primarily chose Git as it is becoming the mainstream distributed version control system, as well as for its ease of use. Git will recognize filesystem changes without the need to check-out files. We will use a local repository without connecting or pushing to a remote repository.

Getting ready

Given that we will be using Git, you will need...

Packaging your solution with configuration data using PackageDeployer

The PackageDeployer executable was introduced with the Dynamics CRM 2013 SDK.

PackageDeployer allows us to import one or more solutions to Dynamics 365 and can bundle configuration data, as well as custom code execution, all in one augmented package.

The easiest way to create a new package is to use the integrated Visual Studio Dynamics 365 Package solution template (demonstrated in this recipe). At the core of the process is an XML file that contains all the deployment directives.

Note

The PackageDeployer solution has some significance in the Dynamics 365 ecosystem. In Chapter 9, Dynamics 365 Extensions, we will cover Dynamics 365 AppSource applications. Behind the scenes, all AppSource deployments actually use the PackageDeployer code base to get deployed into your Dynamics 365 instance.

We will cover how to install a solution along with some reference data using PackageDeployer in this recipe.

Getting ready

To get going, you...

Triggering builds on solution version increments

In this recipe, we will implement a polling application that monitors a solution for version updates. When a version is updated, the script will automatically download the updated solution.

There are at least a couple of ways in which we can monitor the solution version update: either using the C# SDK libraries or using PowerShell. In either case, we can poll Dynamics 365 and monitor a particular solution to check whether it has been updated. Unfortunately, Dynamics 365 solutions do not support plugins or workflows which rules out an event-driven design.

This recipe will focus on the PowerShell option and will use Windows scheduling services to trigger the script on a predefined interval.

Getting ready

In order to monitor a solution, we will need a Dynamics 365 development environment containing a solution that we can update. In this recipe, we will use the Packt solution created in earlier chapters.

This recipe will focus on the PowerShell option...

Integrating your deployment cycles with Octopus Deploy

When releasing a large enterprise application deployment, orchestration and automation are very important. Given that modern deployment tools accept PowerShell scripting and Dynamics 365's ability to be deployed using PowerShell scripts, the platform becomes a good candidate for deployment automation.

In this recipe, we will leverage what we've learned in previous recipes on PowerShell deployments and integrate the capabilities with a deployment tool. More specifically, we will be using Octopus Deploy to promote a solution to an instance of Dynamics 365.

Getting ready

To get started, you need to set up Octopus Deploy and address some of the Dynamics 365 prerequisites.

Octopus Deploy

Given that this recipe relies on Octopus Deploy, we will need an accessible instance with enough privileges to create and configure a deployment project. For details on how to install Octopus Deploy, follow the steps in https://octopus.com/docs/installation. The...