DevOps for Microsoft Dynamics AX2012

Managing version control and the build/release pipelines for AX2012 projects can be a challenge.  This article will provide some pragmatic guidance on where to start and how far to go.

Continuous integration, delivery and deployment

Let’s start by revisiting the common definitions of “continuous” and deciding what we can pragmatically achieve with Dynamics AX2012.

Continuous Integration (CI)

With Continuous Integration, developers submit their changes for validation early and often. These changes are automatically validated through build and test automation, and if successful are committed to the source code repository.

To achieve this, we need:

  • fast build times;
  • high quality, repeatable tests that provide a high coverage of source code;
  • fast test execution;

Unfortunately, the main compilation time for AX2012 alone can take in excess of 40 minutes using axbuild and this doesn’t take into account the time required to restore database backups, fetch and import source code, compile IL and recycle services etc..

Whilst gated check-ins are possible with enough build servers (possibly one per developer) its likely that slow check-in times will promote stale check-in practices amongst developers.

The AX2012 code base does not always lend itself to unit testing, for example where customisations are made within 2000 line long methods.

The pragmatic approach to CI is to develop new features and service packs in a higher layer (protecting the lower layer until the feature is complete) and to automate daily builds with static code (best practice) analysis and automation of unit tests where possible.

Continuous Delivery

Continuous delivery is an absolute requirement of DevOps practices, and only when this is in place are we able to deliver value to our customers whenever that are ready for it. We need to be able to release our changes to customers quickly (e.g. daily, weekly, fortnightly).

The pragmatic approach to Continuous Delivery is to automate the deployment of the latest green build to a QA environment and to run an automated integration test suite before the environment is opened up to further manual validation prior to the build being tagged as a release candidate for further validation by the customer.

Continuous Deployment

With continuous deployment, we automatically deploy changes to the customer’s production environment once all automated tests are passed successfully.

The end to end deployment of model updates can take several hours and often requires data updates and manual verification by the customer (this is partly as a result of the perceived quality of the Dynamics AX 2012 platform).

Whilst technically possible, it is extremely unlikely that an AX2012 customer would be willing to adopt Continuous Deployment and the recommended approach is to adopt the pragmatic Continuous Integration and Continuous Delivery summarised above.

Feature toggling

Feature toggles (tags or flags) can help a team to deliver new functionality to users rapidly but safely, by temporarily disabling the feature until it is ready for production use.

Configuration keys control the features and functionality that are available in AX2012. When a configuration key is disabled, the feature is removed from the user interface.

In some simple scenarios it might be possible to use configuration keys to disable partially complete work, however experience suggests that this won’t be feasible or maintainable for an AX2012 development that customises numerous standard objects.

An alternative approach is to develop the new feature in a working model (potentially in a higher layer to avoid collisions) and to deploy that working model as and where required. The working model is later merged into the stable release once it is complete.

This requires the adoption of a branching strategy.

Branching strategy

In this section, we presume that development is mastered in the ISV layer, however the same approach would also work for high layers (e.g. VAR or CUS).

This following diagram illustrates an extension of the branching strategies defined for Team Foundation Version Control (TFVC) that implement feature, servicing and release isolation to support pragmatic Continuous Integration and Delivery:

The primary objective of this strategy is to maintain and protect the stable main branch.

We achieve this by ensuring that all commits (C) to the main branch are from imports (I) of complete work from higher layers that have already been forward integrated (FI) and tested (through automation and manually) against the main branch.

No merging (M) is ever performed during reverse integration (RI) because the code from the higher layer is imported (I) directly as a replacement. This is safe as all layer conflict merging (M) was already performed during forward integration (FI).

Prior to release (R) of either the main or service pack, a maintenance branch (B) is taken in case any emergency hotfix requires a rebuild of the released version.

Version control

To support the above branching strategy, folders and branches are organised in TFVC between projects (customer implementations) and layers (deliverables to the customer – e.g. the core product, a new feature, product hotfix or service pack).

Within each layer (e.g. ISV) we can hold a number of branches including

  • the stable main branch
  • a number of maintenance branches for each release of the main branch.

Similar folders will exist for each of the other layers in our solution (e.g. ISP, VAR etc..)

Each branch holds all of the artefacts that are required to produce the deliverable in that branch (but nothing more!), including:

  • All supporting Configuration including certificates, licence files and data packages
  • Other dependant Models from 3rd party suppliers or from our own lower layers (e.g. the ISV models required to build the ISP layer).
  • The Source for the layer
  • Automated Tests
  • Other Projects that we need to version alongside the AX2012 deliverables (e.g. integration, external applications)

Strong governance is required to prevent version control from deteriorating into an unstructured file system, and it’s important to understand and apply security appropriately.

The build pipeline

The build pipeline can be orchestrated with PowerShell and typically includes the following steps:

Get things ready

  1. Stop AOS
  2. Restore databases (to the required SYS/SYP CU application level) with basic system configuration.
  3. Clear cached files
  4. Start AOS

Import and compile

  1. Import required models
  2. Synchronize database
  3. Set model version
  4. Create model
  5. Combine XPOs from TFVC
  6. Import combined XPOs
  7. Parallel compile
  8. Restart AOS

Perform other compilations

  1. Compile full IL
  2. Restart AOS
  3. Compile and import other Visual Studio projects
  4. Load licence files
  5. Import labels
  6. Restart AOS

Validate the build

  1. Compile and run automated unit tests
  2. Check best practices

Package the build

  1. Export models
  2. Copy output models to other branches
  3. Build F1 help
  4. Build EP help
  5. Create the deployment package

The release pipeline

The release pipeline to a QA environment is very similar to the build pipeline:

Get things ready

  1. Stop AOS
  2. Restore databases (to the required SYS/SYP CU application level) with basic system configuration
  3. Start AOS

Import and compile

  1. Import all models
  2. Synchronize database
  3. Parallel compile
  4. Restart AOS
  5. Compile full IL
  6. Restart AOS
  7. Load licence files
  8. Import labels
  9. Import Data packages using Test Data Transfer Tool
  10. Restart AOS

Deploy to related components

  1. Deploy SSRS Reports
  2. Deploy SSAS Cubes
  3. Deploy Enterprise Portal

Validate the deployment

  1. Run automated integration tests

Managing Environments

Create a self-contained baseline VM image (or provision one in Azure) and re-clone this as and when required.

Provisioning a complete stand-alone environment from scratch (installing SQL Server, SharePoint, AOS etc. using desired state configuration or similar) each time you need one will take several hours and is not recommended unless you have nothing else to do…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a website or blog at WordPress.com

Up ↑

%d bloggers like this: