HACKER Q&A
📣 devxpy

How to sync server and app deploys?


Hello,

I maintain an app that runs on iOS/Android and communicates to a WebSocket server.

---

I am using build servers, for both the server and the apps.

The server deploys are instant (after docker build) because I own and control my VPS.

On the other hand, App store/Play store deploys can sometimes cost days, if not hours.

---

So how do I make sure that the new server code doesn't get deployed before the App is available to the public? (Especially when I have made a backward-incompatible change to the API)

I do have a mechanism in-place that neatly "depreates" build numbers past a certain point, and forces users to upgrade, but that doesn't help with the time of uncertainty where a new version is deployed on the server, but the apps aren't published yet.

Having router in front of the server(s), that routes to a server instance supporting a particular app version could work, but would become dangerously unmaintainable because then I would have to maintain multiple copies of my DB whenever I do a database schema change.

---

This is meant to be a general question, but FWIW, I use [caprover][1] on the server and [codemagic][2] for building the apps.

  [1]: https://caprover.com/
  [2]: https://codemagic.io/
---

P.S. I've asked this question on Reddit and StackOverflow, but due to no response, I'm forced to come to the conclusion that this is just an absurdly hard problem. Someone, please convince me otherwise!


  👤 daxfohl Accepted Answer ✓
You have to version your apis or make everything backwards compatible. For data migrations if there's some big breaking change the you typically need some out of band sync process. There's no magic bullet once something is out in the wild. When you introduce a breaking change you have to either a, accept it will break people and that's their problem, b, figure out a way not to make it breaking, c, support old and new for a while, or d, drop the feature. It's just a cost that you have to factor in while planning, and frequently one of the more significant ones. We've chosen d many times.