In my previous blog I wrote about how to setup build automation. This blog will continue on that by setting up a release pipeline in Azure DevOps. I will assume you got a test and a production environment. The package from the build automation blog will be deployed on these environment. It will be setup in a very basic way. After that I will elaborate on different other options you can use in Azure DevOps to include in your pipeline.

Setting up the variables for the connection to CRM

In the previous blog we setup a variable group for our connection to the development environment. Now we will do the same for every other environment, in this case test and production.

First go to ‘Pipelines’ and select ‘Library’. Here you can create variable groups.

Next click on ‘+ Variable Group’. This will take you to a form where you can create a variable group.

Now you give your variable group a name. In example ‘CRM Credentials – Test’.  Next add the variables like the screenshot below. Just enter the details to your own CRM environment. For the password field, click the lock icon to make it a hidden field. After saving this password can’t be read by anybody. These variables will later be used in the release pipeline and are part of a connection string. For more information about this, read this article. Save this group and then do the same for the production environment.

Creating the pipeline

To create a new pipeline, you go to Pipelines and then releases. After that you click on new and then new release pipeline.

You will get asked to select a template. Those templates are really useful for setting up deployments for azure. For Dynamics CRM deployments there is no template, so you select an empty job.

Next you will get asked to select a stage name and stage owner. A stage is an environment, so in our case we name it ‘Test’. The owner can be left at default (your account). After you did that you can press the ‘X’ on the top right of the stage tab to close it.

Now you will see the pipeline view. This is an overview of the whole release process.

At ‘1’ you have the name of the pipeline. Click on it and give it a name of your choice. Under that there is the navigation bar with different tabs.

At ‘2’ there is a list of all artifacts. An artifact is usually the output of a build, but it also has other options like an Azure Container Repository. If you click on ‘Add an artifact’ you can see all options available. In the blog we will only use the default, which is a build output.

At ‘3’ there is an overview of all stages. Later we will add tasks to the test stage and also create a new stage for the production environment.

Adding the artifact

To add an artifact. Click on the ‘Add an artifact’ button. Now select all the correct details. For Project select your current team project. For source select the build pipeline you made based on the previous blog. Set default version to ‘Specify at the time of release creation’. Finally choose a good name as source alias, I usually leave it as it is generated. Click ‘Add’ to finish.

Adding the correct tasks

To add tasks click on ‘Tasks’ in the navigation bar or on the blue link in a specifc stage.  You will now be in the task editor. Here you can add tasks similar to the build task editor.

To add a Task click on the + icon next to ‘Agent Job’. You will get a list of tasks. Search for ‘MSCRM Import Solution’ and add the task. Now click on the task and add the details like below:

Display Name: Any name of your preference
CRM Connection String: AuthType=$(AuthType);Username=$(Username);Password=$(Password);Url=$(Url)
Solution File: Use the 3 dots to select the correct solution (it will show the artifacts of the last successfull build, so make sure your solution is there).
Checkboxes: According to your needs

After doing that save the release. Now you have setup the import of the solution that was built in the build pipeline. This is the most basic version of a deployment.

Setting up the environments

Now that we have setup the test environment, we need to setup the same for the production environment. Click on ‘Pipeline’ on the navigation bar to go back to the overview. The production environment is the same as the test environment, just different variables (remember we added those in the library). An easy way to create that environment is to clone the test environment. To do that, hover over the test environment and click the icon with the 2 papers.

It will create a ‘Copy of Test’ stage and you see it connected to the test stage.  Click on it, change the name to ‘Production’ and close the tab by pressing the ‘X’ button. Now you have the production stage too. The fact that the 2 environments are connected, means that the production deployment will automatically start when the Test stage is successfully deployed. If you click the lightning icon on the stage (see screenshot). You can see the configuration there.

Connecting variables

The last thing we need to do is to connect the variables we created in the start to the stages. You do that by clicking ‘Variables’ in the navigation bar and then ‘Variable Groups’.

After that click on ‘Link variable group’. Select the test credentials, select stages and select the test stage. Press Link to connect the variable group with the stage. Now do the same but with the production stage.

Now you have a fully functioning release pipeline. Below you can read up on other options Azure DevOps has to customize your release pipeline.

Advanced options

Triggers

Triggers defines when a stage will be deployed. You can open it by clicking the lightning icon next to a stage.

There are 3 options you can select:

• After Release

This means the stage will be deployed right after the release is created. This is used to automatically start the first stage in the pipeline after a release is created. In build pipelines you can set to automatically create a release when the build is completed. If your pipeline has these option enabled, then a successfull build will automatically deploy to the first stage.

• After Stage

This means your stage will deploy whenever 1 or more stages successfully deployed. If you select multiple stages, then every stage needs to complete successfull in order to start this stage. Optionally you can select the checkbox to also deploy if the previous stages are ‘partially succeeded’ instead of just ‘succeeded’

• Manual Only

This means the deployment of the stage has to be manually started.

Approvals

In addition to triggers, you can set approvals. You can configure them by clicking the person icon next to a stage. There are 2 types.

• Pre-deployment approvals (left icon)

Somebody needs to approve that an stage will be deployed. This approval will trigger when the deployment of a stage is about to start. Either via an automatic trigger or a manual start. Approving the deployment results in the start of the deployment of that stage. Rejecting sets the status of the stage to ‘not deployed’

• Post-deployment approvals (right icon)

Somebody needs to approve that the deployment of a stage is successful. This approval will trigger after the last deployment task is successfully completed. Approving this results in a succeeded deployment and rejecting it in a failed deployment.

For both options you can select the approvers and a timeout before it automatically rejects. Also you can set that if an user manually starts a deployment of a stage, that user will not be able to approve the stage. Finally you can select that approval is skipped when the previous stage was approved by somebody who is an approver of this stage.

Scheduling

Sometimes you may want to start releases on a specific day/time. For that you can set a schedule. There are 2 options for scheduling resulting in very different behaviour.

• Release Trigger Scheduling

You can set this schedule by clicking the scheduling button below the artifacts. A new release will be created at the specifc times that are configured. To also deploy to the first stage, make sure that at least one stage has the trigger ‘After Release’, otherwise it will create a new release but it won’t deploy anything. Also keep in mind a new release will be created, even if there is no new artifact available.

• Stage Schedules

You can set this schedule by selecting the pre-deployment conditions and enabling the ‘Schedule’ option. Here you can define 1 schedule of when to deploy this stage.

Deployment Queue Settings

In the pre-deployment settings you also have deployment queue settings. If you are going to enable schedules, then also take a look at these settings. Here you configure how the release pipelines behave in case there a multiple. You can deploy them in parallel, sequential or cancel all but the latest. You have to set this per stage.

Gates

Gates a quality assessments that are run on stages. This is a relatively complex topic. It allows you to collect signal from external systems and based on that approve/reject stages. It’s best to read the documentation here.

Deployment Groups

With deployment groups you can give machines certain roles and deploy on them based on their roles. This is usually not used in CRM deployments, but it could be useful in specific complex on-premise deployment scenarios. Read more about it here.