Flighting/Versioning client apps with Windows Azure Mobile Services

3
votes

Consider that you have a WAMS service (.net backend in my case) and client mobile apps out there in the wild, and you want to release v2, which contains breaking schema changes (splitting a single table into two tables for instance).

I understand staging on the server side, but this question is about client versioning. How does one handle the period during which your updated mobile app is gradually rolling out among the user community and you have a mix of old and new clients in the wild?

Approaches I have thought of:

  1. Deploy the v2 mobile app with a new URL pointing to a new service. PRO:simple client code CON: Expense of two WAMS instances and complexity of synchronization across two db instances (a single user might have different client versions on different devices and their cloud data in the different WAMS instances needs to stay in sync until they update everywhere).

  2. Add version awareness into the mobile app with two or more sets of data model classes - one set for the current version and one set for v.next. You roll out the version-aware client before upgrading the server. PRO: simpler and cheaper server-side management CON: larger and more complex client code and users that don't update are locked out after the server update. Also, gates the server rollout date upon the client app approval timeline in multiple app stores.

  3. Use a single database and single server instance, but support a hybridization of the old and new server versions through some clever use of DTO's that presents the old wire protocol on top of the new schema alongside the new objects. Presumably, I could add a version element to the routing paths on the server. PRO: simple client, no server-side cross-db sync CON: more complex server code; keeping offline sync working gets difficult if tables split or merge (possible solution: parallel tables kept in sync with code/scripting)

Option 3 is my current favorite, but is there a better/preferred way of flighting breaking changes in a WAMS deployment with a .net backend server and offline-sync-enabled, multi-platform client app?

1
mobileazure-mobile-services
After a fair bit of experimentation and thinking about various devops scenarios, option 3 really seems like the only practical option. The DTOs can provide a shim/facade for the actual db schema and you can control the set of versioned DTOs you expose based on the client versions you care to support in the wild at any given time. Offline syncd tables make this more complex but not impossible to support. - Martin Calsyn
This should have been the first thing to think of when developing the whole platform (speaking of azure). Everything is nice while reading about "ToDoList" and such, but the problem you described is the essence of all mobile development problems and I have not seen them trying to attack that problem. - ramden

1 Answers

0
votes

You could also consider using the Azure API Management service (http://azure.microsoft.com/en-us/services/api-management/) in order to handle the versioning. That would probably be most useful for option 1.

There really isn't a simple solution, and if #3 is the best for your scenario, I would recommend you go with that.