Microsoft Dynamics Technical Conference, 2016 / Day 1 Session 3

Microsoft Dynamics Technical Conference, 2016 / Day 1 Session 3

My report from the technical conference.


Our third session on opening day, Tuesday February 23, 2016 was our first breakout session. I chose “Development Application Lifecycle Management (ALM): Setting up build and test automation” by Shailesh Nikam, Senior Program Manager.


Developer ALM – hope the photo is clear enough – is tied in with source control. There is a build VM. Task recording creates an XML file and can be used to generate a test. This enables us to do essentially continuous validation, or what we used to call regression testing.




The capabilities of build and test automation in AX7 are: developer topology deployment from LCS, build orchestration, and testability. There is a long list of sub-details, which you will see if you check out the system on CustomerSource or DLP, but I want to point out that using Visual Studio Team System, we can now have LCS discover and build AX models. Similar to everything else in the new AX, it is XML based. You can customize the MSBUILD tasks, so it’s got a default yet is as flexible as you need. Gloriously, we can auto-generate test code from task recordings.


Developer topology deployment – LCS: you choose DevTest option for cloud deployment, choose the dev and build VM configuration, can update custom settings for build agent and branches. Visual Studio Team System integrates and auto-configures the build VM.


Visual Studio Team System – build orchestration. One highlight here is that you have extensibility using PowerShell. Again, you can customize the build order, and select the modules and projects to build. This enables the creation of both a deployable and a source package and the upload of build artifacts to VSTS for release management.




Testability. We can use the SysTest framework to author unit and component tests, set up a custom data set for validation and automated tests, auto-generate test code from task recordings, and report on the execution via either the VSTS web interface or the Visual Studio IDE.


We then had a demo.

  1. Deploy developer and build VM from LCS. You select the environment topology: Azure or locally (a vhd). You go to project settings in Visual Studio Team Services and connect up the machine and VS). There should be a 1:1 mapping of the LCS project to a VSTS project. It takes about 4 hours to deploy.
  2. Create test code from task recorder. In Visual Studio you import the task recording. Look at the code and the test attribute: SysCodeGenAttribute(), SysTestMethodAttribute(). You can add build steps (PowerShell, sync, report deploy, generate packages, publish artifact packages, test setup, execute tests, test end, publish artifact, additional logs.
  3. Reporting on VSTS web interface and within desktop Visual Studio. It tells you how many tests passed and failed, and you can drill into the failures.




Moving ahead: we are looking at updating the wiki, having better cost effective options for cloud dev to build, dev/build/test as a service, and much, much more… Microsoft is soliciting feedback to see what features YOU would like to see in this.


All of the above is open source, to boot.


There were lots and lots of questions. I’ll recap just a few here. If you have a bad test, you must redo them all, unless you disable specific tests. You can turn best practice checks on or off. Testing can be run locally, too, so that you can check it BEFORE you build it. J Task recorder is not very resilient when you have field name changes. You need consistent test data between environments. Custom fields break test scripts. You don’t really want Microsoft’s test scripts because of quantity and data dependence. The build is quicker because it’s just a partial build (four hours is now sixteen minutes). Scalability is still an open question.


I hope this “just the facts, ma’am” note from the session does not mask how enthusiastic I am and we should all be for this automated testing. It’s a far, far cry from earlier versions, and finally legitimizes the bastard testing child. This should become de rigeur in every product and implementation!


I hope you have enjoyed this post. I am now heading home from the conference (bummer), but will of course continue to update on each session!


Happy DAXing!








About janeteblake

Dynamics AX developer
This entry was posted in ax 7, AX7, Dynamics AX and tagged , . 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