Build overview

  • 15 minutes

A build is the process of taking the source code and then producing build artifacts that a system can run, such as binary files. In Dynamics AX 2012, builds are different than builds in finance and operations apps.

For example, automated builds are mandatory to help you:

  • Ensure that the code compiles without errors.
  • Perform automated testing after successful builds.
  • Run a SysTest based test as part of the build.
  • Build a deployable package to move the code when the build succeeds.
  • Set up notifications for build success or failure.

To deploy your code and customizations to a runtime environment (demo, sandbox, or production), you need to create deployable packages of your solution or implementation. Deployable packages can be created by using Visual Studio development tools or by using the build automation process that is available on build environments. These deployable packages are referred to as Application Deployable Packages or AOT Deployable Packages.

For more information, see Create deployable packages of models.

Build triggers

To perform automated builds, you can use several types of triggers:

  • Scheduled builds – You can schedule builds to run on specific days at specific times.
  • Continuous integration – Allows you to start a build as a check-in is performed.
  • Gated check-in – You can start a build when a check-in is attempted, and only allow the check-in to commit if the build runs without error (this trigger can be useful together with automated testing during build).
  • Manual – You can manually trigger a build directly from within Azure DevOps.

Before running any type of build, you need to set up Azure DevOps and make sure that your project is set up and linked to your Lifecycle Services project. When these steps are complete, you will need to deploy a build virtual machine from within Lifecycle Services or use a Microsoft-hosted agent.

For more information, see Build automation that uses Microsoft-hosted agents and Azure Pipelines.

Note

Your build virtual machine should not have data in it because this virtual machine shouldn't be used for any other purpose.

You will then create build definitions and triggers, and then you can maintain your build definitions.

By using automated builds, you will no longer have manual efforts to export your models, model store, or XPOs. This approach is consistent across all environments and allows you to have a dedicated environment for build purposes.

Deployment

When your code is built, you will be ready to deploy. The deployable package does not contain source code, it contains binaries that are needed for a runtime environment. To find your build, you can use Microsoft Azure Pipelines and find the build package in the Build artifacts. After you have downloaded the deployable package, you can either manually deploy by uploading the package to Lifecycle Services and then applying it to an environment, or you can use automated deployment (which is for non-production environments only).

For more information, see Dynamics 365 finance and operations tools.

Watch the following video for a demonstration of a binary deployment to an environment in Lifecycle Services.