Setting up automated build is pretty simple using available tooling from Microsoft and the community. This blog wil describe how to setup basic build automation using VSTS. It will export your solution(s) and create a build artifact containing them. In future blogs I will describe to set it up for more advanced scenarios, but this is a great way to get started.

Preparing the tooling

To setup 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 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. In example ‘CRM Credentials – Development’.  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 build definition and are part of a connection string. For more information about this, read this article.

Creating the build definition

In VSTS go to build & release and select builds.

In the top right select New.

Now you select where to get the sources from. This will probably be the VSTS environment you use to setup this build, but it also supports external systems like Github. After that you should select the empty process.

Configuring the Build Definition

Now you have an empty build definition and it’s time to setup the automated build. You start by giving it a name of your liking.

Agent Queue

The next option is to select an agent queue. You can either use a hosted agent. This gives you 240 minutes for free (you can buy more). This works great if you are using Dynamics 365 and don’t have your own server. Otherwise you can install it on your own machine or create an azure VM that hosts this agent. An advantage of this route is that you are not limited to the 240 minutes. Also the 240 minute free hosted agent doesn’t have a very good or stable performance which makes your builds take relatively long.

If you have Dynamics CRM on premises you will need to setup your own agent. This agent will run under a domain user which connects to your CRM environment. If you click on Project Settings and then Agent Queues, you can download an agent. Clicking on that button will show a popup with instructions on how to set it up.

Variables

In the ‘Variables’ tab you can setup the variables which are connected to this definition. The first part are 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 setup 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 unpredicable 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.

Triggers

Next is to configure the triggers. This defines when a build will start. For this basic build I recommend a scheduled build which builds every night. This means every night your solutions will be exported. In the future you can enable contineous integration to build every time something has changed, but that is an advanced scenario outside of the scope of this blog.

Build Number & Linking Work Items

In the ‘Options’ tab, you must enter a format for the build number. This can be anything you like as long as it ends on x.x.x.x (in example 1.0.0.0). You can use the variable ‘$(rev:.r) to create an automatically incrementing number starting at 1. This number will reset if you change the format. In example if you start with 1.0.0$(rev:.r) and queue 5 builds, then the number will be 1.0.0.5. If you then change it to 1.0.1$(rev:.r) and queue a build, then the next number will be 1.0.1.1.

Next I recommend to enable ‘Automatically link new work in this build’. Whenever a build is completed. It automatically links all work items to the build. This way you can see what work items were done in that specific build.

Creating the build process

Now it’s time for the fun part. Creating the process itself. This blog will cover the very basics, which is an export a solution and creating an artifact that contains them. This artifact can then be used in release management to deploy to other environments. You can add tasks by pressing on the ‘+’ button.

The task to add is the ‘MSCRM Export Solution’ task. If you can’t find it, then you need to install the extension as described in the first part of the blog.

After you add and select it, you get a window on the right. Here you can enter the details for the task.

• In ‘CRM Connection String’ enter: ‘AuthType=$(AuthType);Username=$(Username);Password=$(Password);Url=$(Url)’
• In ‘Solution Name’ enter the unique name of the solution
• Select if you want to export managed and/or unmanaged
• Add a target version if needed
• Enable the ‘Update Version’ checkbox. This will update the version of the solution in CRM to the build number of the executing build.
• In ‘Output Path’ enter ‘$(build.artifactstagingdirectory)’. This path will be the path in the artifact.
• Under the ‘Additional Export Options’ you can select more export options if needed for your situation.

If you have multiple solutions you can create copies of this task and change the solution name. You can do that by right clicking the task and select ‘Clone Task’.

Now that you export the solutions, you need to publish the build artifact. You can do that by adding the ‘Publish Build Artifacts’ task.

In the edit box, Leave the path to publish to the default and change the name to a name to your liking. This will be the name of the artifact which you will see in release management. Finally you can set the location. By default it will upload it in VSTS, but you can choose to do it on a file share if you wish.

Now you are finished and you can queue your first build. After it is completed you can now use this artifact in release managment to deploy this to other environments.