CI/CD & Test Automation for Dynamics 365 in Azure DevOps/VSTS – Part 2- Build Definition
In the previous post, I showed you how you can export and extract the solution from Dynamics 365 CE instance and commit to VSTS.
In this blog post, I will tell you how to create the VSTS build definition.
Dynamics CRM CICD process
The below diagram illustrates the basic flow of the Dynamics 365 CE Workflow process.
In this part, we are going to see how to create a build definition in VSTS.
Install Dynamics 365 Build Tools by Wael Hamze in VSTS
To set up your tooling there is only one thing to do. You need to install an extension from the Visual Studio Marketplace within VSTS. Go to this link to add this extension to your VSTS account. You need to be an administrator to do this.
Setting up the variables for the connection to CRM
You can create variable groups in VSTS. This is useful for variables who are related. You will use this to create a group for credentials for your development environment. Later if you implement the automated deployment, you can store the credentials to other environments there too.
In VSTS go to “Build and Release” 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. For our demo purpose, I am giving the example as a Development environment. Next, add the below variables
Connection string – AuthType=$(AuthType);Username=$(Username);Password=$(Password);Url=$(Url)
URL- Enter your instance URL.
Username – Enter the username of your instance
Password – Enter the password of your instance
Authtype – Office365
Below is the sample connection string details for your reference
AuthType=Office365;Username=jsmith@contoso.onmicrosoft.com; Password=passcode;Url=https://contoso.crm.dynamics.com
Reference Link https://docs.microsoft.com/en-us/previous-versions/dynamicscrm-2016/developers-guide/mt608573(v=crm.8)?redirectedfrom=MSDN
VSTS Build Definition
Once the developer checks-in the changes into BuildAutomation.Solutions project we have a Build Definition in VSTS which will trigger automatically and perform the following steps:
In Build Pipeline, we will be packing the CRM solution and store the solution file in Artifacts. You can create a build definition directly from Visual Studio Online(VSTS/Azure-DevOps) or from within Visual Studio. Firstly, I will show you how to create a build definition from within Visual Studio, navigate to the Builds tab in the Team Explorer:
Once there, you can click New Build Definition to be taken directly to Visual Studio Online. This is where you would start if you had decided to create the build definition directly from Visual Studio Online instead of starting in Visual Studio.
On the dialog box that pops up in the browser, we’ll select Visual Studio as our build template, but you can see there are other templates for use, such as Xamarin for Android or iOS and the Universal Windows Platform. The default settings for your build definition should be correct for the most part, but you’ll need to check the Continuous Integration checkbox. Here’s what they look like for this example:
Because this is a simple example and we don’t need the additional flexibility the Default queue provides, we can leave the default Hosted option selected in the Default agent queue field. For more information on the restrictions on the Hosted pool.
You can see the checkbox for CI at the bottom of the dialog. This is enabled so that Visual Studio Online will execute the defined build definition for each check-in. The build definition will define whether or not this build code is published to an environment. Since we want to continually build and deploy to our web environment, we’ll check this box.
We can create the build definition from Azure Dev Ops too by following the below steps.
Navigate to Pipelines -> Builds -> Click New Pipeline
Click the Visual Designer, which will allow you to perform using GUI.
Select the Team Project, Repository, Branch and click on the continue button. For Demo purpose, I have given the name of the build definition as D365 CI
In the next step, Select an empty job as shown below:
After selecting an empty job, you can see the empty Agent Job and Select the Agent Pool as Hosted
Once the above step is done, we need to associate the variable group which we have created in the previous step to the build definition variables. In the “Variables” tab, you can set up the variables which are connected to this definition. The first part is the process variables. These are variables specific and available only to this build definition. Just leave the default variables like they are.
The other part is that you can link variable groups. Earlier in the blog, you set up your credentials as a variable group. Here you click link variable group and select your variable group to link it to this build definition. After linking you can use these variables like they are process variables.
If you ever add your own variables, make sure that a variable in the process variable and a variable in the linked group(s) don’t have the same name. This can lead to unpredictable results.
System.Debug process variable
A good fact to know is the use of the ‘system.debug’ variable. If you set this to true, then verbose logging will be enabled on all build tasks. If you are stuck on some error in the process, this may help to get more information. It will create a massive amount of logging.
Next step is we need to configure the VSTS build definition as shown in the below diagram.
UseNuGet4.4.1 & Nuget restore – The NuGet tasks are required to process the NuGet package references in the
Build Solution – Then we use the Visual Studio Build task to build the complete solution
Copy files – The Copy task copies all files in **\bin\$(BuildConfiguration)\** to the $(Build.ArtifactStagingDirectory).
MSCRM Tool Installer – We are using the MSCRM tool installer. It will install the necessary files (Installs the Dynamics 365 tools required by all the tasks).
MSCRM Set Solution Version – Then we are setting the solution version in the source environment using MSCRM set solution version component.
Note: We need to provide the connection string in the below format to establish the connection with Dynamics 365 CE instance which we have created initially.
MSCRM Pack Solution task creates an Unmanaged and managed solution from the files in Solution/.. within that project and we output the Zip file in the respective folder of the project. The Copy task copies all files in **\bin\$(BuildConfiguration)\** to the $(Build.ArtifactStagingDirectory), we then Publish the Artifact.
In the MSCRM Set Version task, we must specify the Build Number Format under Options in the Build Definition. Here is an example of my build number $(Build.BuildNumber).
In my next blog, we will see how to create the VSTS Release definition(It will pick the CRM solution from artifacts and deploy it in the Dynamics 365 CE target instance).
If you are interested in this topic and would like to do some further self-study I encourage you to check out my blog on this.
