Frequently Asked Questions: Development and Continuous Delivery Guidelines

Customization

Do I customize (overlayer) or use extensions?

Dynamics AX enables application customization using a new framework: Extensions. Developers can create extension models that compile into separate assemblies and distributable packages. Within an extension model, developers can create new elements, extend elements that belong to other models and customize business logic using event handlers and plugins. Extensions enable faster builds, more efficient application lifecycle management and movement of code, better performance at design time, and minimal cost for application upgrades.

You can still create customizations by using overlayering of metadata and code, which is a framework similar to what was available in Dynamics AX 2012. When you overlayer code, you can freely modify X++ code and metadata, but you will be compiling into the same package (same assembly) of the code you are customizing.

Here are some guidelines:

1. Use extensions as your default mode of development and fall back to overlayering only as a last resort.
2. When you need to overlayer code, do not include functional or business logic in the overlayered code. Instead, define and call a delegate method, then implement the logic in your extension model using an event handler. Here is a detailed example in the context of code migration: Delegates.
3. Report commonly used over-layering patterns to Microsoft and request extension support.

For more information, refer to: Customizing with Extensions and Overlayering, Models, and the Development Tools section.

How do I prevent my models from being customized by customers or other partners?

You can block customizations of your model as described in How to disable model customization and deprecate functionality, or you can distribute Deployable packages to your customers instead of distributing model files. See How do I distribute my application to customers below.

Continuous Delivery

Do I need build environments?

Yes, take advantage of the build and test automation tools provided in the build environments. You can deploy build environments from you LCS project. Creating daily builds and daily regression tests are key tools to enable the continuous delivery and maintain the quality of your application. Refer to this topic for more details.

What strategy do I use for test automation?

Concentrate on Unit tests (use the SysTest framework) that are data independent or create their own data. Use a smaller number of functional scenario tests (based on Task Recorder) that rely on test data to execute. Scenario tests are more expensive to maintain. Unit tests can then be executed on any dev environment easily and quickly. Review this Test Automation Pyramid blog article. You can also refer to Automated testing guidance for AX7.

Some highlights to keep in mind:

• Write tests that run independently and not assume any kind of ordering.
• Task recorder tests should be limited to functional scenarios tests.
• Write scenario tests once scenarios are complete and after completing unit tests.
• Create test helper classes whenever possible so others on your team can leverage that as well.
• SysTest framework supports role-based testing, leverage this feature.

How can I be more agile in my development?

Deliver incremental features every sprint (2 weeks, preferred) or cycle (1 month). Maintain shippable quality of your application at the end of each sprint. Use VSTS for work item tracking and always prioritize bugs over new features. A large bug backlog will quickly become a burden on your efficient delivery of new features and on the quality of your application.

How do I manage test data?

Create and manage your test database as follows:

• Start on a clean environment.
• Create all base data as required. Base data will serve as the starting point for all the tests.
• Take a backup (.bak) of your AxDB database.
• Share this backup with developers.

On a build environment, copy this backup over to the I:DynamicsBackupDatabases (on some environment it may be a different drive than i:). This database will be restored at the beginning of every build. This step is executed as part of the first step of the build definition called Prepare for build.

How do I distribute my application to customers?

There are two artifacts you can use to distribute your application to your customers or partners: model files or deployable packages.

Model files are design time artifacts and they contain source code. Use model files if your customer is integrating your application with other third party models or when you want to allow customization of your models. See this topic for more details. Model files are the more common methods for ISVs to distribute solutions.

On the other hand, deployable packages are final applications. If you use deployable packages, your customer can only use or extend your application. They will not see or have access to your source code. To create a deployable package use the Visual Studio tools (Dynamics AX >  Deploy > Create Deployment package) or use a build environment. Build environments generate a deployable package with every successful build.

Development topologies

Should I develop on premises or in the cloud?

Dynamics AX provides 2 modes of development: Cloud VMs and on-premises VMs available via a downloadable VHD.

Use a combination of on premise VMs and cloud VMs for development:

• On premise dev VMs are cost effective if you already have the hardware, IT infrastructure, and windows server licenses to support it.
• Use cloud VMs to scale out when projects require additional resources for a limited period of time. It is more cost effective than planning for worst-case capacity on premise.
• Connect all VMs (on premise and cloud VMs) to VSTS for version control.

Use cloud VMs for build, functional testing and demos. If you are running on your own Microsoft Azure subscription, turn them off when not in use.

Should I use a customer’s dev environment?

If you are a partner, use your own VMs for development of your own intellectual property (IP), this is  code and configuration data packages that are reusable across different customer implementations. For customer specific implementations, you can use the customer’s dev VM. All customer subscriptions come with at least one development VM. Customers can pay for add-on dev VMs or run local dev VMs.

What are the benefits of MSDN subscriptions with respect to  development?

This is a summary of a Visual Studio (VS) with MSDN subscriptions benefits:

• It includes a Microsoft Azure subscription with a $50 monthly credit for VS Professional with MSDN and $150 for VS Enterprise with MSDN.
• Subscriptions come with lower dev/test rate, you will pay the Linux rates instead of the Windows rates.
• For more details, visit https://azure.microsoft.com/en-us/pricing/member-offers/msdn-benefits-details/

As a Microsoft partner, acquire Microsoft core competencies to earn free VS Enterprise with MSDN subscriptions. For example, an application development competency for a gold partner will earn 25 free MSDN Enterprise licenses in addition to the 10 licenses that come with the core benefits. For more details, visit https://partner.microsoft.com/en-us/membership

These benefits make cloud development very economical, here is an example:

• D12v2 VM list price = $470/month (4 core, 28 Gigs)
• D12v2 VM price if running on MSDN Azure subscription or any other dev/test subscription = $276/month
• Turn off 12 hours per day: 276/2 => $138/month
• Monthly credit (VS Professional with MSDN) => 138 – 50 = $88/month
• Monthly credit (VS Enterprise with MSDN) => 138 – 150 = Free

Here is a second example:

• D13v2 machine list price = $843/month (8 core, 56 Gigs)
• D13v2 machine price if running on MSDN Azure subscription = $551/month
• Turn off 12 hours per day: 551/2 = $275.5/month
• Monthly credit (VS Professional with MSDN): 275.5 – 50 = $225.5/month
• Monthly credit (VS Enterprise with MSDN) => 275.5 – 150 = $125.5/month

Add an average of $15 monthly for storage (non premium) per VM.

Can more than one developer develop concurrently on the same VM?

This is not supported. However, you can provision more than one developer account on the same VM, they just cannot develop concurrently. Details are in this article.

Customer implementation LCS projects

How many Dynamics AX sandbox environments do I need within an LCS customer implementation project?

A customer subscription comes with three environments by default: A dev or build environment, a tier-2 sandbox environment, and a production environment. You can use the tier-2 sandbox environment as both a configuration environment and a UAT environment before (or after) the application goes live in production.

After configuring the sandbox with the code and data you need to go live (aka your gold configuration), you can run your validation on the same environment. When your validation passes, you can restore your sandbox database to the point in time of its gold configuration. You can then deploy your code to production and copy the sandbox database to your production environment.

If you prefer to have 2 separate sandbox environments, one for pre-prod validation and the other to serve as your gold configuration, you can purchase an additional tier-2 sandbox.

The following are servicing requests and tools that LCS supports, this may help you decide whether 1 tier-2 sandbox is sufficient for your implementation:

1. Restore a sandbox database to a point in time.
2. Copy a sandbox database to a production environment (only allowed before the application is live in production).
3. Apply configuration data packages on a sandbox environment.
4. Apply configuration data packages on a production environment.
5. Refresh a sandbox database from production (Copy the production environment’s database to a tier-2 sandbox environment). This is typical after the application is live if you want to debug an issue or validate upcoming updates.