做過APP產品的技術人員都知道，APP應用屬於一種C/S架構的，所以在做多版本兼容，升級等處理則比較麻煩，不像web應用那么容易。下面將帶大家分析幾種常見的情況和應對方式：
小改動或者新加功能的
這種情況，數據庫結構和API程序一般是可以兼容多版本的，所以不用強制升級，可以坐到多版本共存。
盡量采用數據庫層面新增字段和API的方式，應用程序層面就可以兼容了。當然，API層面也可以部署多個版本來同時提供，但這個不是必須的
但最重要的是數據庫層面的表結構那些能夠兼容到。
或者： 
總結：
數據庫層面，盡量采用新增字段，而不是修改字段的原則，避免影響以前的業務。
而服務端程序層面，API層盡量設計靈活，接入層可以支持“路由”最佳。主要有幾種思路，1. 在API方法中通過新增參數或者直接新增API方法（也可以理解為重載）。
較少的改動可以這樣去做處理，但是改動多了會比較麻煩，不利用擴展。
2. 代碼分不同分支版本，API部署不同子站點。通過api.xx.com/V1 和api.xx.com/V2方式訪問，或者通過apiV1.xxx.com，apiV2.xxx.com等方式區分訪問。當然，也可以在APP不同版本中請求時傳入標識，服務端通過Nginx或者APIGateWay等來實現服務路由。
這種直觀上更加清晰，工作量也會大一些，會增加一定的維護和管理成本。
后端的原子服務，也需要盡可能支持多版本。
如果是大改動，底層數據結構都不兼容，那只能提示強制升級了
如果是強制升級，就不會有多版本共存的問題了，
也不會有多套數據庫，也不會存在數據同步的問題。
只需要這樣操作：
在蘋果提交審核之前，我們事先准備好“新版本的數據結構和對象（view、proc、function等）腳本、遷移腳本或者程序、程序發布文件”等。
1. 部署1個具有新表結構和對象的測試數據庫（預發布環境）。
2. 部署1個新的API站點（不同域名，建議域名中使用版本號區分。或者采用不同子站點的方式），配置連接測試庫和測試的（API站點、DB、緩存、ES、Nosql …這些單獨有一套預發布環境）
3. 等蘋果審核通過之后，更新最新的程序，數據庫結構等到生產環境，並將API地址的域名的指向切換到生產環境中（網站、admin后台等等可以直接發布了），運營人員在蘋果商店點擊上架操作，服務端升級完成（APP端會有強制更新的提示）。當然，這個過程中可能會造成短暫的停機時間，所以一般是選擇在晚上操作。
4. 提前將安卓最新APK放到我們的下載站或鏡像站，在3步服務端程序等都發布完成后，在運營后台開啟安卓版本的強制升級提示（從我們的下載站或者鏡像站下載APK升級）。
這樣，舊版本的安卓用戶，會強制升級到新的版本，不會影響到使用。
與此同時，運營人員也需要在各大安卓市場去分發和上架最新的apk包，提供最新的其他渠道下載，避免用戶下載到舊程序，然后又提示強制升級影響體驗。
- 如果是大改動，數據庫結構和API程序都不兼容， 又不想去做強制升級，就會有多版本共存的問題
那就只能去部署兩套（或者更多個版本）數據庫，而且對於用戶產生內容和時效性要求較高的，需要雙向（甚至多向）去做同步。核心問題其實是數據庫有狀態，這種是很困難的。
這種很容易出問題，容易出現沖突和數據不一致。
而且數據結構不一樣的情況下，是很難去兼容的。
所以，對於改動較大的，產品新增了重量級新功能的，業務層面或者底層表結構上都不兼容的，建議是要做強制升級的。
或者：
2.如果是大改動，底層數據結構都不兼容，那只能提示強制升級了
如果是強制升級，就不會有多版本共存的問題了，
也不會有多套數據庫，也不會存在數據同步的問題。
只需要這樣操作：
在蘋果提交審核之前，我們事先准備好“新版本的數據結構和對象（view、proc、function等）腳本、遷移腳本或者程序、程序發布文件”等。
1. 部署1個具有新表結構和對象的測試數據庫（預發布環境）。
2. 部署1個新的API站點（不同域名，建議域名中使用版本號區分。或者采用不同子站點的方式。通過api.xx.com/V1 和api.xx.com/V2方式區分），配置連接測試庫和測試的（API站點、DB、緩存、ES、Nosql …這些單獨有一套預發布環境）
3. 等蘋果審核通過之后，更新最新的程序，數據庫結構等到生產環境，並將API地址的域名的指向切換到生產環境中（網站、admin后台等等可以直接發布了），運營人員在蘋果商店點擊上架操作，服務端升級完成（APP端會有強制更新的提示）。當然，這個過程中可能會造成短暫的停機時間，所以一般是選擇在晚上操作。
4. 提前將安卓最新APK放到我們的下載站或鏡像站，在3步服務端程序等都發布完成后，在運營后台開啟安卓版本的強制升級提示（從我們的下載站或者鏡像站下載APK升級）。
這樣，舊版本的安卓用戶，會強制升級到新的版本，不會影響到使用。
與此同時，運營人員也需要在各大安卓市場去分發和上架最新的apk包，提供最新的其他渠道下載，避免用戶下載到舊程序，然后又提示強制升級影響體驗。
3.如果是大改動，數據庫結構和API程序都不兼容，
又不想去做強制升級，就會有多版本共存的問題
那就只能去部署兩套（或者更多個版本）數據庫，而且對於用戶產生內容和時效性要求較高的，需要雙向（甚至多向）去做同步。核心問題其實是數據庫有狀態，這種是很困難的。
這種很容易出問題，容易出現沖突和數據不一致。
而且數據結構不一樣的情況下，是很難去兼容的。
所以，對於改動較大的，產品新增了重量級新功能的，業務層面或者底層表結構上都不兼容的，建議是要做強制升級的。