How to automate your release to D365O One-box environments?

I wrote about VSTS release management and potential use in Dynamics 365 for Operations (D365O) projects in my previous post.

Today I’m glad to share the results of taking the first step. During last week I was so excited when finally deployed releases into one-box environments successfully.

It took few days and dozen trials to get it right, but it was elegant, simple and easy! My top 3 aspects of good automation.

In my next post, I want to go further and try to integrate release management with LCS for Tier 2 and above environments (UAT etc…)

Architecture and scenario

Imagine you have few pre-prod environments, with a weekly release cycle. Coding is done in DEV, connected to VSTS. Build is done by VSTS and a Build server.

The weekly release is automatically deployed to QA and Data migration environment without any manual approvals.

My branching strategy is simple: Main branch for daily code check-ins + Release branch for weekly release merges.

High-level steps

Assuming you’ve provisioned a DEV and Build, connected to VSTS along with applying the required branching strategy, the next steps are:

• Deploy agents into each target environment
• Design your release definition

Challenges

It took me 13 quick iterations to get it right. Issues ranged from something silly like syntax errors – highlighting my rusty PowerShell skills – to more interesting AXUpdateInstaller related ones. Disallowing spaces or special characters in package folder for example.

Step-by-step guide

I received a great feedback from a friend asking for sharing detailed how-to steps along with the high level concepts, so thought to share that with you this time.

Agent download and prep

1. Download the Agent files to the target environment, by going to your VSTS Project > Admin (gear icon) > Agent queues > Download agent
   

   
2. Create a new queue/pool for that environment in preparation for its agent configuration.
   

   
3. Create a personal access token as well, by going to User (Your initials at the top right corner) > Security > Personal access tokens > Add > Create token
   

   

   
4. Copy the token value as you will need it shortly

Agent installation & configuration

1. Extract the downloaded agent files into a folder. For example use C:\DynamicsSDK
2. Run the config file as administrator to start the configuration process
3. Enter your VSTS server url. For example use: http://your-vsts-account.visualstudio.com
4. Leave authentication type as default by pressing enter
5. Enter your personal access token from previous steps
6. Enter the agent pool from previous steps
7. Enter the agent name or leave it blank for default
8. Leave work folder as default
9. Finally, enter Y to run the agent as a service

Once’s it’s all configured, you should find a new services in the target server along with the agent lighting up in VSTS

Release definition

This isn’t the neatest way to design this, as I would prefer to use a common version controlled PowerShell file instead of inline script, but this is quick and dirty so you get the idea.

1. Create a new release definition by going to Build & Release > Releases > Create release definition > Empty template
   

   
2. Select the relevant build definition. In my case I have Main build for main branch, and Release build for release branch. I picked Release.
3. Start by renaming your first environment and pointing the agent to the right queue
   

   
4. Extracting the deployable package is the first task needed. Add a task by going to Add tasks > Utility > Extract files
   

   
5. Point the extraction to appropriate folder which will be used for the next step. Avoid folders with spaces
6. Running AXUpdateInstaller is the second and last step. Add a PowerShell task for this
   

   
7. Select Inline script, and put the required code to generate, import and execute your runbook [Link]
8. Make sure to pick the right folder from step no. 5 under Advanced > Working folder
9. Once you’re happy with one environment and tested it successfully you can clone it along with all steps and make it your 2nd environment.

There are more advanced features such as environment templates and task groups which can be used to simplify your design and increase productivity.

Here is what the end result should look like along with a successful release deployment.

Also you can download my sample release definition for reference.

That’s it for now. You’re welcome to leave a comment for any feedback below.

• 04 April