發版流程及對外版本規範
這部分為三個方面：
一、版本編譯、驗證、釋出
二、BUG追蹤
三、不定期的版本釋出
四、人員職責
一、版本編譯、驗證、釋出
說明：
對外app的釋出，只能通過jenkins自動編譯平臺進行release。
目的：
1. 保證對我統一出口，杜絕混亂髮包現象
2. 確保出線問題後，版本可以迅速定位，幫助復現。
3. 減少研發人員參與運維工作，避免忙中出錯，流出本不應存在的包
人員：
1. 測試相關人員 2.研發相關人員
流程：
1. app對應產品負責人，給出本次升級的提示文案。供產品升級時使用。
2. 研發人員必須在GIT上進行一條日誌更新，明確版本釋出的內容以及一條更新記錄
3. 由相關人員更新發布最新版本
4. 測試工程師，對釋出的版本進行全面測試。跑用例。跑全部可能執行到的流程。同時要進行不同版本的升級更新。並驗證。
5. 經測試工程師確認後，對於需要release給使用者的版本，研發人員使用得到的升級文案，同步更新到後端版本資料。將本次升級，釋出到google play上。
6. 對本次升級，用文件記錄並儲存 在 app升級記錄說明。
備註.每次的發版內部版本應先於公開release的版本。公開release的版本理論上應有至少半個月的緩衝。對每次公開的版本經過彷彿測試後，方可發出給使用者。二、BUG追蹤
Java層，C層，記憶體洩露。
針對這三種類型的BUG，採用如下的3種對應方法。
1 ) JAVA層，採用騰訊公開bug管理工具(支援國外)：bugly
2 ) C層，採用騰訊公開bug管理工具(支援國外)：bugly
3 ) 記憶體洩漏，採用leakcanary進行二次開發後，對接禪道的bug管理系統，可自動將bug提交到禪道。(這需要額外製定開發計劃)
BUG日誌檢視。
時間：每日上午10點，檢視日誌。
人員：測試相關工程師，將新產生的異常 手動 提交到禪道上。並附 Bugly的相關錯誤id。該類禪道BUG 與Bugly上對應bug的生命週期保持一致，即禪道上的bug關閉，則bugly相關的bug也應關閉
備註. 針對記憶體洩漏，無需關心，需要對重複的異常進行bug的過濾，剔除重複bug。
三、不定期的版本釋出
說明：
為應對突發情況進行的臨時版本更新，為應對突發狀況而產生
特點：
急，問題重，必須及時修復
規則如下：
1. 每週四定為 固定的版本釋出日；如遇突發嚴重bug，版本釋出為即時更新。(不嚴重bug，不在此範圍內)
2. 理論上說，內部版本必先於公開release版本幾次迭代。經過充分測試後，才能上線。這才能充分確保業務流程的順利開展。
3. 公司可能會有多種 渠道包。(這隻做超前技術考慮，具體要看業務發展而定)
四、人員職責
1. 版本編譯：研發相關人員、運維相關人員，測試相關人員(原則上，不應有測試介入)
2. 版本測試工作：測試相關人員
3. 版本釋出：研發相關人員、運維相關人員，測試相關人員(原則上，不應有測試介入)
4. 產品更新升級資訊：產品相關人員應 給出此次升級的升級提示文案