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.
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.
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 trust 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.
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.