The problem lies in:
The app has been online for one months now, the number of users uh, uh, barely 2000 registered users. Then the 1.3 version of the app will be ready for development.
Then on-line, 1.1,1.2 should be able to keep. iOS and Android are the same.
One: First, the interface version
I think the solution is that each version of the separate deployment of V1,V2,V3 before the interface does not change. Deploy the new API directly. This is convenient to deploy, but there is a big hidden danger is that if you modify a logic before all the items have this logical version will need to be modified.
II: Changes in the database
Each version of the interface will be more or less database changes, additions and deletions and other things.
Update steps:
1. First determine the table differences between the latest version and the original version of the database structure.
2. Set all the new table structures to a reasonable default value, placing an insert with an error.
3. Downtime update (temporarily not considering the non-stop update), temporarily scheduled at 11 o'clock in the evening, first stop the service and then transfer the old database data to the new database.
4. Simple test to see if there are any errors.
The most important step is to compare the differences in the database table structure, in the approximate steps:
1. Export the table structure of two database tables
Mysqldump–uroot–p–d speedjump > Speedjump1.sql
Use SCP command to transfer to a server
Mysqldump–uroot–p–d speedjump > Speedjump2.sql
-d means that only the structure is exported and no data is exported.
2. Compare
Use the diff command to compare
Diff Speedjump1.sql Speedjump2.sql > diff.txt
3. Some information is useless must be self-increment ID value, preferably removed
sed
-i
‘s/AUTO_INCREMENT=[0-9]\{1,\}//‘
SPEEDJUMP1.sql
再来进行比较。
Multi-version coexistence in the app background