Microsoft Dynamics Technical Conference, 2016 / Day 1 Session 5

My report from the technical conference.


Our fifth (and last) session on opening day, Tuesday February 23, 2016 was another breakout session. I chose Microsoft Dynamics AX Application Lifecycle Management (ALM) with Joris de Gruyter, Senior Solution Architect.


Being Joris, this was another overfull session. 🙂 Also everyone is understanding how crucial ALM is to implementations going forward. Please find below my notes from the class. I hope that you will agree that it’s of interest, and look up the recording when it’s posted.



  • Source control: Setup, usage, advanced scenarios (branching shelvesets, Git)
  • Testing: X++ unit tests, task recorder, test data
  • Automated builds: Build VM, build definition, output



Source Control

  • Visual Studio Team Services (VSTS) and LCS
    • Initial setup
    • Deploy Dev and Build VMs separately, not at once – URL issues, can start and stop separately, naming
  • On the VM
    • Workspace mapping
    • Creating your first version controlled model



Demo: Setting up

  • If you deploy a local VM, it’s a development environment
  • Project settings is where everything is set up
  • Go to your profile > security to create personal access tokens
  • Build agent can be used (deployment settings)
  • VSO credentials are deprecated, if you used them in earlier versions or CTPs
  • Then map the workspace: Metadata and project documents. Don’t check in all the code, only check in what you need, otherwise the build takes hours.
  • Projects are not so important in AX ‘7’ just try to be consistent
  • Then start working. Add it to source control. But an edit will automatically check it out. Since we went to files, source control “just works.”
  • Create a new model. Add the descriptor file.


Source control

  • Branching / merging
    • Trunk/main and releases
  • Advantages and disadvantages of branching and merging
    • Needs strict policing and tracking through environments (versioning?)



Demo: releases branch


Source control

  • Shelvesets
    • Work as expected (don’t forget to delete when done)
    • Can work with build VM, we’ll get to that
  • Code reviews
    • Code reviews use shelvesets, which work
    • However, reviews use XML viewers to look at the work
  • Compare with previous version


Demo: Shelvesets


Do not share a (development) VM because you are editing files


Source control

  • Other VCS
    • Whatever Visual Studio supports (or add-ins) should work but are not supported
  • New VSTS Feature
    • One VSTS project with both TFVC and Git repositories
    • Not officially supported and manual labor




  • X++ Unit testing
    • SysTest framework
    • Advantages to using extensions, handlers, etc.
  • Task recording
    • Essentially “Coded UI tests” from task recorder output
    • Data points can be coded in
    • Validations
  • Integration inside Visual Studio



Demo: Testing

  • Validate a field ex: credit limit and number of days to pay
  • Put your tests in a separate package because there’s no need to deploy the testing to production
  • After building a test, stop and start Visual Studio
  • Task recording then look at the code it wrote


There’s documentation on how to get the task recorder to do load testing [I did a search of the wiki at but did not find it; it could be in LCS; I did not check there.]



  • Test data for unit tests
    • Independent of other tests
    • Setup and rollback
    • Isolate
  • Test data for coded UI
    • Planning is everything
    • Chaining is not recommended
    • Build vs Dev VM



Automated builds

  • Build VM from LCS
    • Agent pool
  • “Clean build” principle
    • Packages, DB, full clean option
  • VSTS build definition (vNext)
    • Add scripts, demand agent capabilities, support branching
    • proj



If you do it from Visual Studio, it includes everything from the dev box. This isn’t really desirable


Demo: Build setup

VS TS > Build > Build Main

Edit and see the steps

Repository > mapping note this, check it. By default it’s correct, but if you start branching it may not be.

Deltas can be an issue if you’re using shelvesets.

Interesting variables

Skip sync

Skip deploy reports

Triggers: Continuous integration, scheduled, gated check-in


General > demands

Update model version number with build number (Hey Steve! Should we send your code that does this?)

Gated check-in: only if it all succeeded [Sounds like a great idea to me…]



If you have dependencies on binaries, check the dll’s in to VSTS

Output: – deployable package, and a model (they are called runtime and source)


Happy DAXing!

About janeteblake

Dynamics AX developer
This entry was posted in ax 7, AX7, Dynamics AX. Bookmark the permalink.

Leave a Reply

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

You are commenting using your 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