Recommended approach to promote mobile app to production

Hello everyone,
I am pretty close to going in production with a mobile application that uses Realm.

While testing different scenarios however I found a problem, I did not really think of before.
I created my own CI/CD that does the following:

  • Build Android application
  • Build iOS application
  • Deploy both applications to the store
  • Promote Realm vom Dev to Prod

Now however arises the following problem:
The moment I promote Realm from Dev to Prod, the applications in the stores are not yet live (this can take up to a few days). And even if they are, I can not ensure that the users will even update the application on time. That means, that my Realm is always “ahead” of my application. So if I - for example - rename a field in Realm, the application of all users will break in the second, I promote my schema from Dev to Prod.
All the migration logic that I could put into my application to compensate this will thus have no effect, as they dont have the application yet.

I am kind of lost now, how the procedure should look like. I thought of following scenario and wanted to ask for feedback first:

  • Build iOS + Android application
  • Deploy them to the store with a fixed release date (e.g. 5 days in the future) in the future
  • Create a CRON job that runs in 5 days and promotes Realm Dev to Prod
  • Block the users in the application until they update (problem)
  • Don’t touch Dev for 5 days (problem)

I hope I made my problem clear and there are already some best practices.

Hello @Thomas_Anderl : Previously when I have encountered similar situation, we always mark urgent release for iOS and keep the Android App ready in pipeline and once both are ready we force update all the previous build user. (Didn’t impact us, we had 400K DAU)

And not sure if you meant dev branch by “Don’t douch Dev for 5 days”, we normally create a release candidate once code is ready for production from Dev branch, which unblocks future release work.

Hey, thank you for the insight.

I had a typo. I meant “touch”. As I am low scale, I only have 2 environments for now: Dev and Prod.

So apparently your approach is similar to the one I suggested? You just didnt control it with the timeline (e.g. 5 days), but did it manually after?

Yes, you are correct.

Hi, just chiming in with this checklist we have for applications going into production with sync: https://www.mongodb.com/docs/atlas/app-services/sync/go-to-production/production-checklist/

As for breaking schema changes, the best advice I can offer is to not do them. If at all possible it is best to just perform additive schema changes in production.

We are trying to think about how to make this a better experience for users though, so I am curious if you can go into more detail about what kinds of changes you expect to make in production and why?

Hey, only doing additive changes is already a good suggestion.

I plan on adding additional features (e.g. profile verification). Most of them could be added by making the fields optional and nothing should break.

However when a field of a future feature becomes mandatory, it will get tricky.

So far I usually change datatypes often. As there is no enum support, for example, I sometimes switch between saving keys of enums as strings vs integers.
Another thing I might change in the future is references. As it is not possible to query links with sync directly, there is a chance that I need to change links to ObjectIds to be able to query them.
To load all messages for a chat, for example, I need to store the Chat in the Message as ObjectId to sync them. If I ever decide to add different queries for performance reasons, I will need to make breaking changes to the schems.