Microsoft recently published information about maintaining apps and per-tenant extensions (PTEs) for Business Central. This rule can be simply summarized as “keep your apps compatible with Business Central or we are forced to remove your app”. This sounds a little bit harsh, but it makes sense if you think about it. Customers choose Business Central for several reasons, and one of those reasons is that Microsoft promises an always up-to-date business solution. If Microsoft can’t keep that promise because apps become incompatible, then that’s a bad thing.
Deprecated features
Now, one could say that future releases always should be backward compatible so that older apps still do work. And to a certain extent that is right. It doesn’t work if Business Central updates come with a lot of breaking changes causing apps to fail easily. On the contrary, to improve the application and platform, it’s sometimes necessary to introduce new technologies and code changes that are not backward compatible. But to give partners time to prepare, Microsoft will announce deprecated features at least a year ahead. This list is a high-level list of features that you certainly should keep on eye on. It also contains a section about obselete objects. Objects and code that is part of a feature that will be deprecated in the future will be marked as obsolete one year before the really disappear.
Breaking changes
Another topic in this list is called Breaking Changes. This is for changes that are a result of a redesign of code, resulting in moved, removed or replaced objects, fields or functions. Be aware that the topic of breaking changes does not come with the promise of announcing them one year ahead. Or at least I don’t see it. They can occur for other reasons than deprecated features. For example, when code is redesigned to mitigate performance issues. To help partners with those breaking changes and how to solve them, Microsoft published a document on GitHub with more information. That document also confirms that breaking changes might happen and sometimes can’t be avoided. In short, the code of deprecated features will be marked as obsolete a year ahead, but breaking changes in code still may occur earlier. It may even happen that partners detect a breaking change before Microsoft does.
What can we learn from this? That we should not rely on the list of deprecated features and obsolete functions. Then it might happen that Microsoft suddenly informs you that your app or PTE is not compatible with the next version. When that happens you have still time to solve the issue, but you want to catch them as early as possible.
Detect breaking changes
What can you do to detect breaking changes as soon as they appear? In my opinion, there is only one good answer: implement a proper CI/CD process. You may already have a CI/CD process to support ongoing development that focuses on the current version of Business Central. But you should extend that with automatic builds, including automated tests, against the next minor and next major builds. Only in that way you will be able to detect breaking changes as soon as they appear. A build could break on compilation against the next major, and you want to know that. Or maybe the automated tests report errors for a next release, that’s also something you want to know.
For this to happen, you need to have access to the preview releases. A major release is made available about one month before the release date. But Microsoft also publishes insider builds for the next minor and next major release. With those builds, you can keep up earlier and I definitely recommend to get access to those insider builds. Credentials for the insider builds are provided through Microsoft Collaborate. This is part of the Microsoft “Ready to Go” program. Follow this link to find detailed information on how to register on Collaborate.
When you got access, it’s a matter of setting up a build process that includes the next releases. If you already have a build process for the current release, then it should be easy to add that. If you don’t have any automated builds yet, then I definitely recommend setting that up. There is plenty of information available, but a good start would be the blog of Freddy Kristiansen. Or follow an online course about DevOps from Waldo.
There is another aspect that people sometimes tend to not see as breaking changes. It is the changes in CU where MS introduce events in the beginning of functions *and* the use the following coding pattern
Before:
begin
OnBeforeUpdateVATAmounts(Rec);
// Code goes on that I depend on to happen
OnAfterUpdateVATAmounts(Rec); // I listen to this
After:
begin
IsHandled := false;
OnBeforeUpdateVATAmounts(Rec,IsHandled);
if IsHandled then
exit;
// Code goes on that I depend on to happen
OnAfterUpdateVATAmounts(Rec); // I listen to this
Oops, my code does not execute… Breaking change? I do think so… And this happens all the time in CU’s
So in reality, another part of BC could then flag IsHandled and my code does not run, or another add-on for that matter
This is a good reason to see every CU as containing possible breaking changes.
Good point! And this can only be caught by having test cases, because the code will compile nicely.
So true. The only problem with automated tests is that they test a flow, a function and what-not where you have known states and a known outcome. The change I listed can most likely only be seen by comparing cumulative updates by looking at the source. The test will be a success until someone listens to the first event in the function and set IsHandled to true. So, in my world: “May the Source be with you!”. MS is actually introducing “optional function cancellation feature” here.
Of course… even your test will just successfully complete because you don’t have an app installed that listens to the first event. That reminds me of a trick that I discussed lately with a partner about catching event subscribers with the handled pattern that can potentially break your app. Maybe that’s something to write another blog post about.
Tricks are nice and always worthy a deeper insight 🙂
Pingback: You wonder how? The answer is “DevOps”! - Dynamics 365 Business Central Community
Pingback: You wonder how? The answer is “DevOps”! - Microsoft Dynamics NAV Community
Pingback: You wonder how? The answer is “DevOps”! - Waldo's Blog - Dynamics 365 Business Central/NAV User Group - Dynamics User Group