Request for Zero-Downtime Migration Options (Avoiding "App is disabled") for LiveUpdate

moondory77

Hello BrainCloud Team. @Paul-Winterhalder

I am submitting this inquiry again as it seems some context might have been missed when I left it as a comment in another question thread.

This is an extension of the following inquiry:
https://forums.getbraincloud.com/topic/369/inquiry-regarding-temporary-app-is-disabled-error-during-builder-api-deployment

As a quick reminder, our service operates across dev, staging, and production environments using three separate BrainCloud apps. We maintain a zero-downtime deployment scenario by deploying the contents tested in dev/staging to production via the builder deploy API.

However, as mentioned in our previous inquiry, the "App is disabled" state occurs temporarily during this process, causing all BrainCloud APIs to fail. Since our service relies heavily on BrainCloud for much of our backend infrastructure, this causes a significant degradation in our user experience.

The issue is that while we understand this state might occur during heavy updates like cloudcode deployments, it also happens when we only migrate specific specs like customEntity. This creates a problem even when we are just trying to apply minor specs to the production app space.
(Since you mentioned in the following inquiry that there are no plans to provide a bulk update API for customEntity, we currently have no alternative: https://forums.getbraincloud.com/topic/372/subject-inquiry-regarding-selective-customentity-migration-via-builder-api/2)

Therefore, we would like to request the following:

Please provide a minimum-unit migration option that does not trigger the "App is disabled" state. (We strongly hope customEntity can be included in this option, and it would be even better if productPricing and itemCatalog could also be included.)
If (1) is not possible, please provide a means to bulk update/migrate customEntity at the very least, without triggering the "App is disabled" state.

We have been able to provide a truly excellent service to our users thanks to the BrainCloud infrastructure. We sincerely hope you can support us in this matter so that we can continue to deliver a seamless and positive experience to our users.

moondory77

Dear @Paul-Winterhalder
I am leaving another message because it has been over two weeks without a response to our previous inquiry.

I am reaching out again as the response through the forum has been significantly delayed. Since we are currently operating a live service using your platform, we are in desperate need of support regarding the matters we previously mentioned.

Could you please provide us with some guidance or any workarounds we can apply on our end to resolve this issue?

Paul Winterhalder

Hi @moondory77 ,

We hear you - and are looking to see what options we can provide.

The thing to understand is that there are a lot of dependencies between metadata in the brainCloud system - and our deployment mechanisms work hard to ensure the integrity of the data that gets pushed. Even more importantly - it works to prevent user data from being corrupted by a mis-match of data during deployments - which is why apps are very temporarily disabled during a deployment.

These deployments normally take well under a minute and aren't much more troublesome than a common wifi interruption for clients [depends upon the client implementation though]... (note - the deployment may seem like it takes longer on the web - as there is a lot of data dependency checking to do - but all of that is done BEFORE we disable the app... which happens just for the actually data migration activity itself).

If you contact us via the support chat with your appId and the time you last did a deployment - we can take a look to see if your deployment times are above normal.

Also - we are working to provide a separate custom entity deployment mechanism - similar to what has been done for item management.

Paul.