Breaking news from around the world
Get the Bing + MSN extension
Check out the latest Business Central updates!Learn about the key capabilities and features of Dynamics 365 Business Central and experience some of the new features.
Download overview guide | Watch Business Central video
2019 release wave 2 Discover the latest updates and new features to Dynamics 365 planned through March 2020
Release overview guides and videos Release Plan | View virtual launch event
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Talent TechTalks | Upcoming TechTalks
I published a few blogs on different topics around the development and publishing of apps. So, if you have been developing an app and have it published, you are done, right? Far from it – there is a lot to do after the app is published. And I don’t want to talk about the marketing, sales, or monetization of the app – those are topics for different days. What I do want to talk about, however, is the maintenance of an app.
Microsoft releases a new update to Business Central once a month. In the spring and fall, a new major update is released. So, you will have to make sure that your app still works and that your app also can make use of all the new features (from an application and technology standpoint) of the new releases.
Just as an example: I have several apps released and was one of the first ones in the channel releasing those apps. I was excited and wanted to focus on new features and enriching the app. Well, this was great – until I get an email from Microsoft saying that they have made changes to the platform that will brake my app(s) in the next update. This was at a time when the release was still a 6 week process and the new release cutoff was only a few days out. So, I had to scramble to get everything fixed and submitted again for the new app, so that it would still be able to make the next release.
The last major change in the platform was the retirement of codeunit 1 – our beloved ApplicationManagement. You can read a bit more about this here. And this was done recently and broke a lot of apps. A lot of people were frustrated about this and had to scramble (and some found out that the apps then actually were not broken, it was a false positive from Microsoft).
Don’t get me wrong, the changes that Microsoft makes are typically advancing the product in the right direction, but sometimes you can also see different ways of implementing a particular change. Now think of it – it will be at some point that we have thousands of apps and a breaking change (such as the one referenced above) could impact several hundred companies. This would mean that everyone has to make changes to their apps and Microsoft will have their hands full with the validation of those apps.
Good news is that Microsoft is trying to not implement any more changes that will break existing apps – or rather phase those changes in over several releases so that we have more time to adapt to those changes. But how do you know that there are changes coming that break your app?
One of the requirements of a new app submission now is that you have to have your test automation developed that covers more or less your entire app’s functionality. The automated tests should now only be unit tests, so they should not only test individual functions, but rather complete processes. If you have, for instance, some changes or additions to the sales order entry process, your test automation should be creating new sales orders, processing those orders using the additional functionality of your app, and then post the orders through to make sure that everything still works.
Once you have your test automation, you can then use this to run automated tests. You can run those against the different builds, ideally using the daily builds described in Freddy’s blog here under “Maintaining app”. So, basically, you would create a new docker image on a daily basis using the latest docker image “bcinsider.azurecr.io/bcsandbox:[country]”. You get access to this once you have deployed an app. You should create the docker image with the test toolkit. After the docker container is created, you then publish and install your app, publish and install your test automation app, and then you have to run the test automation. You can do that manually through the web client (http://[navserver]/NAV/WebClient/?page=130401) or you can script this in a little PowerShell script.
If you use Azure DevOps (formerly known as VSTS formerly known as TFS), you can even go further and automate the download of your latest main app release and import this into the docker container and run this on the tests.
I will go into more detail and show some examples on how to set this up or how to use the scripts in another blog, since my flight is boarding soon.
Business Applications communities