开发闲谈——app上线后，软件如何开发更新？

1. 开发闲谈

最近的一个项目即将上线，内心有些期待，当然，也有些担心。这段时间，就是反复测试，然后反复修改bug。作为一个前端+后端+app端+测试端的四端的全端工程师，享受着这样的来回切换，爬摸滚打的感觉，等习惯了来回切换后，就好了。总体感觉是快速拿起，快速放下，再快速拿起。在拿起与放下之间，也就是全栈开发人员的工作。下面进入闲谈正题。

2. 版本控制

上面说到的期待，就是期望上线后，有人使用这个app，作为主要开发人员之一，内心是挺期待的。说担心，是上线后，会面临一系列的问题。一旦上线，那么，上线的版本就会锁定，即用git添加一个tag版本号。
后续的开发，提交代码的时候，得按照如下图所示的分支开发。

即在bob（用户名）分支上开发，提交代码，提交后，一个完整的功能后，再推送到dev。而dev的起点，是项目开始，或者是某一个上线发布的版本。比如，版本1.0。
下面以本人supger为例，来说明开发一个新功能，需要经过的版本控制步骤。
（1）开始开发前，新建一个分支supger，并置为当前分支。在该分支下开发，开发完一个模块后，提交并推送当前分支，若干次推送后，完成了一个功能，此时，可以切换到dev分支，并合并supger分支。此时，如果dev分支没有其他人提交代码的话，那么，dev分支内容应该同supger分支相同。如果有他人提交代码，如果需更新supger分支，只需要切换到supger分支，再合并dev至supger分支即可。
（2）当然，通常的情况下，dev分支合并后，可以删除supger分支，并新建supger1分支，并把dev分支推送至supger1分支。或者不删supger分支，直接把dev分支推送至supger分支。
（3）待dev分支的几个功能开发完成后，需要更新到一个新的版本，比如1.1版中的时候，此时，就切换到master分支，并把dev合并至master分支上。
按照以上流程如此往复。

3. 更新时机

假设一个app，最开始有1000个用户，那么，如果更新时机选择不好，会影响用户的使用体验。当然，app的更新涉及到前后端的更新。对于app端的更新，确实需要更新的情况下，可以在app上，添加一个通知类的消息，通知什么时候更新。app更新的时候，可以采取强制更新的方式。在某一个页面后，就自动下载更新。而对于后端的更新，最好是在晚上或是凌晨，没有用户使用的时候更新。但更新之前，必须要进行代码的排查以及模拟测试，尽可能避免因为更新，导致系统不可用的情况。

4. 后续维护及bug收集

通过排查日志，以及用户提交的反馈，提高用户的使用体验。等等。。。