AX Build Environment - Nuts and Bolts

  • Article

What happens during the build environment provisioning from Dynamics Lifecycle Services?

There are two main operations performed by Dynamics AX deployment service while provisioning your build environment.

  1. Automated configuration of a build agent to process continuous integration activities like compilation of X++ / C# code, DB sync, automated test execution and packaging.
  2. Automated creation of a build definition with tasks based on next generation, extensible build system of VSTS to orchestrate continuous integration activities.

Configuration of build agent on your Visual Studio Team Services Agent Pool

To build your code or deploy your software you need a build agent that can build X++/C# code and deploy your solution. Visual Studio Team Services provides a scalable agent pool and queuing architecture to handle multiple build requests. As part of provisioning the continuous integration environment, a custom build agent for AX is added to an agent pool in your team services account. For quick steps and configuration requirements on getting started with VSTS for AX applications check this article.

These are the series of steps executed to get your agent configured:

  1. Deployment portal in LCS picks up the configuration information you provided in the project settings and any customization information you provided in the advanced settings option of LCS.
  2. The only required configuration information used is the personal access token used in the LCS project in case you are not customizing the name of the agent and have not created any custom agent pool. In this case, a default agent pool named “Default” that automatically gets created while signing up for team services is used to add your custom build agent.
  3. In the advanced settings of LCS, there are options to pass in your own agent pool name. For power users of VSTS, these named custom agent pools allow one way to achieve isolation across different versions of AX platform. Note that this is an optional parameter that you pass from LCS and these named pools have to be created manually in VSTS before you schedule deployment.
  4. Agent is added to your default or named pool to process build tasks.

Automated creation of Build Definition

The next generation VSTS builds are web- and script-based, and highly customizable. The new system embraces the diverse set of domain-specific languages (DSLs) that developers used to build the code on their dev machines.

As part of the build environment provisioning through LCS, a build orchestration template is created which know how to compile your AX app, self-test the build if you have automated tests and package your AX app for deployment on sandbox environment.

[caption id="attachment_55" align="alignnone" width="537"]Default Developer ALM build definition Default Developer ALM build definition[/caption]

Quick explanation of the steps in Build Definition

  • Prepare for build - On the first build it creates the environment variables and also creates a backup of packages (generally under I:\DynamicsBackup\Packages) and also a backup of the database (generally under I:\DynamicsBack\Database). On every subsequent build, the script restores the packages (& the database if the database name is provided in the variables). This ensures you can build different projects on the same machine without corrupting your packages.
  • MSBuild (Build the solution) - This step uses the AXModulesBuild.proj file to build your solution. It runs XPPC, PGC, XPPBP, LABELC and REPORTC to compile and build your solution.
  • MSBuild (Database Sync) - This step is used to run the SyncEngine that syncs your metadata with SQL
  • Deploy Reports - Deploys the reports. It’s a two-step process of first Removing all reports from the server and then redeploying all of them again.
  • Generate Packages - This step generates both runtime and source packages which can be used to deploy your solution on other environments.
  • Publish Packages - This step uploads the generated packages back up to VSTS and is available with your build.
  • Test Setup - Execute Tests - Test End -- This 3 steps work together to successfully run all your tests. If you want to skip test execution, then you need to remove or disable all of these 3 steps. Once the tests are executed a test report is uploaded with the build.
  • Publish Artifacts (Additional Logs) - This step is always executed so that we can upload all the logs created because of the solution build back up the VSTS for future debugging.

While these steps are automatically created during the build environment provisioning, you have the ability to extend the build definition by adding your steps. For more information check https://msdn.microsoft.com/en-us/library/vs/alm/build/steps/index