22
According to this github issue ( https://github.com/Microsoft/AL/issues/4221 ) running extension upgrades in the BC SaaS is not yet supported.
It was suggested that the only way to currently test extension upgrades (i.e. schemaUpdateMode=synchronize) need to be tested locally via BC docker containers.
This isn't a satisfactory solution for tenant-specific extensions. Here's the rub:
* A BC SaaS sandbox can have data replicated from a production environment but there is no way to test extension version upgrades in that SaaS tenant sandbox.
* A local docker container has support for extension upgrades, but will not have production data.
For standalone generic extensions targeted for distribution on AppSource, the docker approach is reasonable. However, for tenant specific extensions (i.e. an .app with AL objects in the 50000..99999 range), it is very important to to test that .app upgrade in a dry run against production data.
Spinning up a local docker image, loading the old version of the .app, and then feeding the docker BC database with with production data via rapidstart configurations + excel, installing/upgrading the .app from 1.0.0.0 to 2.0.0.0 is all extremely time consuming.
It's a step in the right direction that the Business Central Admin Center can now create a tenant sandbox with production data, but if that sandbox does not support .app upgrades so developers can test those upgrades, then it's usefulness is limited.
I strongly believe one of the two feature enhancement options need to happen.
option 1) enhance the tenant SaaS sandbox functionality so it CAN support .app version schema synchronization upgrades.
OR...
option 2) add a new feature to the Business Central Admin Center to allow an admin to create a docker sandbox image (optionally with production data). The docker image would reside in a private docker registry on azure visible only to users with admin access to that tenant. Developers with admin permissions to the tenant could then create a local docker container based on that tenant image.
It was suggested that the only way to currently test extension upgrades (i.e. schemaUpdateMode=synchronize) need to be tested locally via BC docker containers.
This isn't a satisfactory solution for tenant-specific extensions. Here's the rub:
* A BC SaaS sandbox can have data replicated from a production environment but there is no way to test extension version upgrades in that SaaS tenant sandbox.
* A local docker container has support for extension upgrades, but will not have production data.
For standalone generic extensions targeted for distribution on AppSource, the docker approach is reasonable. However, for tenant specific extensions (i.e. an .app with AL objects in the 50000..99999 range), it is very important to to test that .app upgrade in a dry run against production data.
Spinning up a local docker image, loading the old version of the .app, and then feeding the docker BC database with with production data via rapidstart configurations + excel, installing/upgrading the .app from 1.0.0.0 to 2.0.0.0 is all extremely time consuming.
It's a step in the right direction that the Business Central Admin Center can now create a tenant sandbox with production data, but if that sandbox does not support .app upgrades so developers can test those upgrades, then it's usefulness is limited.
I strongly believe one of the two feature enhancement options need to happen.
option 1) enhance the tenant SaaS sandbox functionality so it CAN support .app version schema synchronization upgrades.
OR...
option 2) add a new feature to the Business Central Admin Center to allow an admin to create a docker sandbox image (optionally with production data). The docker image would reside in a private docker registry on azure visible only to users with admin access to that tenant. Developers with admin permissions to the tenant could then create a local docker container based on that tenant image.
STATUS DETAILS
Completed
Business Central Team (administrator)