Deploy Dynamics CRM Solutions using VSTS and Octopus Deploy - Part 3 - Release and Deployment

In this third and final installment I cover the steps involved in setting up the minimum release and deployment steps required for a successful Dynamics CRM/365 deployment. The steps and actions performed in the previous posts acts as prerequisites for this one.

Related posts from the series:

The Packages

In the previous post, I setup the team build to automatically publish packages into the Octopus Deploy package repository.

We can verify that they have indeed been published by navigating to the Library > Packages tab for a list of available packages.

Available Packages

Defining the Environment

Environments are a logical grouping of targets / machines used by deployments. For the purpose of this post, I will create one environment - Testing and it would contain a single CRM deployment target - the CRM Server).

  1. Let's start off by clicking on the Environments from the main menu to navigate to the environment configuration page.
  2. Click on Add environment in the resulting page.
  3. Set Testing as the name of the environment .

    Existing Build Definition

  4. Click on Save to confirm selection.

Next, define the deployment target for this environment:

  1. Navigate to the Environments summary page and click the Add deployment target button.
  2. Select Cloud Region as the deployment target.

    Existing Build Definition

  3. Set Test CRM Server as the Display name.

  4. Select the previously created Testing as one of the Environments.
  5. Create a new role called crm instance.

    Existing Build Definition

  6. Click on Save button to confirm.

    Existing Build Definition

Variable Sets

I will be creating a variable set to host all settings required to connect to the CRM Server. It makes configuration easier and also provides us with the ability to reuse the same server in multiple projects.

  1. From the main menu navigate to Library > Variable Sets
  2. Click on Add variable set

    Existing Build Definition

  3. Define three new variables:

    • #{TestCRM-servername}: The CRM Server Url.
    • #{TestCRM-username}: The deployment username.
    • #{TestCRM-password}: The deployment password. On this one, set the variable type as Sensitive.

    Existing Build Definition

  4. Click the Save button.

Define the Project

Projects allow to define a proper release lifecyle by bringing together the different environments and deployment steps.

Let's define a new project:

  1. Navigate to Projects menu.
  2. Click on the Add project.
  3. Provide a name and description. Leave the other options to default.
  4. Click on Save to confirm selection.

    Existing Build Definition

Now associate our previously created variable set as part of our project:

  1. Navigate to the Variable > Library Variable Sets tab within the project.
  2. Click the Include variable sets from the Library button.
  3. Choose the previously created variable set.

    Existing Build Definition

  4. Click the Apply and then Save buttons to confirm selection.

    Existing Build Definition

Setup the Deployment Process

The deployment steps are pretty simple and consists of two PowerShell scripts; the first one is an inline script that sets up the prerequisites while the second one does the actual deployment.

Prerequisite script

  1. Navigate to the Process tab within the project.
  2. Click on Add your first step
  3. Select a Run a Script template.

    Existing Build Definition

  4. Update the following parameters while accepting the default selections for the others:

    • Step name: Setup Prerequisites
    • Run on : Deployment targets
    • Runs on targets in roles : crm instance
    • Script source : Source code
    • Script: Powershell
  5. Provide the following for the body of the script:

    Install-PackageProvider -Name NuGet -MinimumVersion -Force -Scope CurrentUser

    Existing Build Definition

  6. Click Save to apply changes.

Deployment Script

The steps are very similar to the previous one, but this time we want to execute a script that is already part of the package.

  1. Once again,click on Add step and select a Run a Script template:
  2. Update the following parameters while accepting the default selections for the others:

    • Step name: Deploy CRM Solution
    • Run on : Deployment targets
    • Runs on targets in roles : crm instance
    • Script source : Script file inside a package
  3. Keep the Package Feed on Octopus Server (built-in) as we've already published our package into OD.

  4. Set Package ID to gnxdemo.crm. This is the name that the build published.
  5. Set the Script file name value to:

  6. Set the Script parameters value to by integrating the variables that we created earlier:

    -serverUrl "#{TestCRM-servername}" -username "#{TestCRM-username}" -password "#{TestCRM-password}" -solutionName "gnxdemo.crm" -publishChanges -activatePlugins

    Existing Build Definition

  7. Click the Save button.

    Existing Build Definition

Release and Deployment

Now that we have everything setup let's create a new release and then deploy the same to the Testing environment.

  1. Navigate to the Project page.
  2. Click on the Create Release.
  3. Provide a version number for the new release. I gave it 0.0.1.
  4. Ensure that the Deploy CRM Solution step is referencing the latest version of the solution.
  5. Click on the Save button the confirm the release. The release page shows an overview of the release including the its lifecyle path and as well as the packages being deployed.
  6. Click on the Deploy to Testing in order to deploy the solution to the testing environment.
  7. Click the Deploy now button in the resulting page to kick off the deployment.

    Existing Build Definition

  8. The page would redirect to a summary page showing the progress of the deployment.

    Existing Build Definition

  9. Click on the Task Log to view a more verbose view of the solution being deployed.

    Existing Build Definition

Final Thoughts

While I think I have barely scratched the surface of the features provided by Octopus Deploy, the process of writing this series of posts made me appreciate the intuitive structure of key concepts as well as the myriad of options available to support even the most complex of release life cycles. This series also gave me the opportunity to validate the flexibility of the project structure generated using the generator-nullfactory-xrm - with its ability to work with different DevOps tools.


comments powered by Disqus