在一個項目上線過程中，會涉及到整個項目團隊成員的參與，參與成員及職責分別如下：
1、開發環境由開發人員負責，同時包括了維護與代碼版本及版本管理
2、測試環境由測試人員負責，包括了測試時的項目部署、測試、上線申請
3、預發環境由運維（測試）負責
4、生產環境由運維負責
5、所有數據庫相關由DBA(數據庫管理員)或運維統一負責
已經完成開發的系統或應用正式部署到生產環境前， 要嚴格按照上線發布的流程進行，基本按照如下的順序開展。
一、開發提測
開發人員在功能開發完成后首先配置開發環境，將系統部署至開發環境，并在開發環境下完成單元測試、冒煙測試等，沒問題了就需要提交一份上線方案。
上線方案必須包含：
- 當前版本所影響的范圍
- 新增的功能/內容
- 前后端 版本號
- 前后端負責人
- 代碼地址
- 程序部署所需數據庫腳本文件
- 項目配置說明清單
- 計劃上線時間
- 上線失敗的回滾計劃等
將上線方案提交技術負責人及項目負責人進行審核，審核通過后郵件提測給測試人員。
二、系統測試環節
在執行之前測試人員是需要根據日常需求評審內容進行測試用例設計的。
- 測試人員接收到提測郵件通知后，開始著手進行測試工作。
- 首先將待測項目從代碼地址部署到測試環境，如果需要配置數據庫，由DBA或運維配合完成。
- 然后先進行冒煙測試（開發也會做一輪），冒煙測試不通過，以郵件方式打回， 請開發修復完成再次提測。
- 冒煙測試沒有問題，就正式進行測試執行，可以開展接口、功能測試、自動化測試等。
- 測試過程中發現缺陷，及時提交缺陷并跟蹤開發進行解決，待開發人員修復后進行復測并回歸測試。
- 最后，達到測試計劃中的準出標準時，總結與分析測試，并輸出測試報告。
三、預發環境測試環節
在測試環境中的接口、功能測試等都通過了，并測試結果報告發送相關責任人之后，就可以進入預發布環境的測試了。
1、預發布環境checklist
一般需要測試人員一份checklist，逐一確認每項需要提前準備的資源及環境是否OK，以保證上線前的最后一步的準確性，是很有必要的。
發布策略一般是從下游逐步向上部署，而回滾方案相反，一般是從上游往下回滾。
通用的checklist需要考慮以下幾方面：
1）依賴
存儲（數據庫、分布式緩存）、是否有數據庫變更需要代碼上線前先提交，并且驗證執行成功。
2）動態配置
需要確認代碼中的動態配置有無默認值，沒有默認值需要先在動態配置系統上添加相關的配置。
3）下游
確認下游jar包版本是否正確，線上最好使用release包、確認下游的業務方是否已經上線。
4）鑒權
驗證需要調用的服務都能通過鑒權，檢查所有參與上線的子系統都完成授權。
5）上游
- Nginx層，確認路由策略，在發布過程中會不會造成用戶不斷刷新頁面命中不同代碼邏輯，給用戶帶來用戶體驗上的問題和困擾。
- 上游業務方，確保和上游業務方溝通好，等當前服務全量發布后且觀察、驗證沒問題再通知上游發布。
6）業務內部
- 通過代碼review，QA測試等方式保證上線對現有業務邏輯沒有影響。
- 代碼review：重點查看代碼規范、業務邏輯的正確性、對相關功能的影響
2、預發布環境測試
- 預發環境中新功能為最新代碼，其他功能代碼和生產環境一致
- 預發環境和生產環境的訪問域名不同
- 預發布會訪問到在線真實數據，盡量不要產生臟數據，從而影響在線環境
- 用戶不能訪問到預發布環境
- 預發布環境應該盡量避免對線上環境的影響
預發環境測試通過, 則以郵件通知相關開發、產品、運維, 準備正式上線。
四、正式上線環節
1、上線流程
在項目具備發布條件下，正式上線前，開發人員召集所有相關人員(開發,測試、運維、產品)討論此次部署內容(重點介紹各方的具體內容與職責、 數據腳本執行、部署的順序、配置文件、 部署時間、回滾方案等)，最后形成會議紀要并發出郵件。
- 確認上線后，測試人員通過郵件發送上線申請，包括上線方案、數據庫腳本、配置文件、版本號等，并抄送相關責任人，如開發、運維及DBA等。
- DBA提前執行數據庫腳本，應用部署應通過自動化部署平臺進行部署，部署系統應在應用系統中記錄當前分支號，以便后續回滾使用。
- 在部署過程中出現問題，由對應負責人及時解決，如果問題不能在發布的計劃時間內予以解決，則執行回滾方案。
- 運維及DBA在操作完成時，均需要回復郵件，并說明操作結果。
- 發布完成后，運維人員郵件通知測試人員，業務及需求相關人員進行線上測試。
- 測試結果及問題、提交開發， 如果出現問題不能在計劃時間內解決， 執行回滾方案，并重新進行迭代。
2、金絲雀發布（灰度發布）
金絲雀發布的思想則是將少量的請求引流到新版本上，因此部署新版本服務只需極小數的機器。驗證新版本符合預期后，逐步調整流量權重比例，使得流量慢慢從老版本遷移至新版本，期間可以根據設置的流量比例，對新版本服務進行擴容，同時對老版本服務進行縮容，使得底層資源得到最大化利用。
3、發布結果
通過金絲雀發布，需要比較長的時間才能將新的版本全部替換到服務器上，但是風險更小、底層資源消耗更少。
發布完成之后，需要將發布結果通知到相關責任人：
- PM： 周知PM關注業務指標、客訴等
- 上游：如果上游依賴此發布，周知上游開始發布
- 下游：周知下周注意流量增量及耗時等情況
五、 運維監控
運維人員持續對線上業務進行有計劃的監控及日志采集, 及時發現問題處理及反饋問題。
常用的的監控報警包括：
- 新、舊版本的流量及百分比
- 對外提供的接口的性能指標、下游的性能指標（TP50、TP90、TP99、TP999）
- 異常指標及報警
- 業務指標
六、總結
在平時工作中，都是做好了萬全的準備之后，才會執行上線的，但是整個過程也很難保證100%成功，因此做好完善、規范的防范措施很重要：
- 不在高峰期上線，如必須上線，要發郵件申請，同時降低并發度
- 上線前周知
- 保證能回滾
- 發布過程采用分組發布（強制）
- 上線過程中觀察系統指標、業務指標、異常指標等；如有異常立即禁用已發布機器
- 上線后周知PM、上下游等
- 有異常第一時間回滾
ALLEN老師軟件測試小課堂：
https://zhuanlan.zhihu.com/p/550021486
版權聲明：本文內容由互聯網用戶自發貢獻，該文觀點僅代表作者本人。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。如發現本站有涉嫌抄襲侵權/違法違規的內容， 請發送郵件至 舉報，一經查實，本站將立刻刪除。