目前公司專案偏多，平均每週五天基本上有四天都會有專案上線，有時一天會上線至少二個版本，就在昨天剛上線了乙個專案，星期一才提測的乙個專案，星期二就安排上線了，所以悄悄地告訴小夥伴們，昨晚俺加班了(再悄悄地告訴大家其實這個昨晚已經過去很久了~微笑臉)，今天跟小夥伴們分享一下王豆豆公司的上線流程。
01
早會
每天早晨上班之後，都會開早會，早會主要是回朔昨天的內容、今天的計畫、需要解決的問題三個方面。
開發每個人講自己的情況後。
主持人：「測試呢？」
測試a：... ...
測試b：... ...
王豆豆：「xx專案，昨天已經將所有的測試點測試完全了，今天開發合到master上回歸測試完成之後就可以上線了。」
開發a：「我一會兒就合"
王豆豆："好的"
散會之後，一小時過去了.....
王豆豆問開發a："合完了沒「
開發a：」還沒有，還在做code review"
然後再一小時間過去了，**還是沒有從分支到master上。
上午下班前問：」什麼時候能合完嗎？"
開發a自信滿滿地說：」下午上班就能合完了「
02
回歸測試
一直到下午三點左右，**才合併到master上，果真是合併十分鐘，等待四小時，不過這樣也有好處，專案組內只有專案leader才有合併**的許可權，他在合併**之前會再做一次code review，這樣最大程度保證**的正確性，只此以後，王豆豆就變聰明了，提前讓開發合master。
回歸測試流程：
1.配置引數和環境
2.回歸主要的流程
3.將以前提的bug再次回歸
4.回歸主要的異常流程
王豆豆回歸測試時主要就是由這幾個方面組成的，如果有需要跟第三方系統聯測的情況，那麼**合前到master時，需要設計測試用例場景覆蓋需求與第三方系統測試人員聯測，三方聯測最是花費時間，所以測試過程中如果有這個需求一定要提前安排好時間，與聯測人員約好相應的時間，聯測在回歸測試階段也會進行，這時主要以正向流程為主，目的是檢查業務流程是否完整、介面是否聯通、資料是否正確等幾個方面。
用於回歸測試的伺服器：
王豆豆目前公司有十台測試伺服器，平時根據專案、業務需求和測試任務的不同，在不同的測試服務上拉分支進行測試，幾輪測試完全之後，確定要上線時再將分支合併到master上，然後其中固定的一台測試伺服器上進行回歸，這台伺服器只用於回歸master分支，這樣就保證了測試任務的獨立性，同時也能保證測試上線配置不會遺漏。
針對上述情況，王豆豆舉例說明：
假設我們有5臺測試伺服器，分別命名為test1、test2、test3、test4、test5。
剛好今天王豆豆就接到了乙個新的測試任務，接到任務之後，王豆豆就會詢問測試小夥伴們哪台伺服器是現在沒人用的？假設今天test3沒人用，那王豆豆就選擇test3作為本次測試任務的測試伺服器。
確定了測試伺服器，開發轉測之後，王豆豆就會在test3這台機器上部署**（我們是用jenkins自動部署，早已脫離了手工去部署**），配置資料，進行測試。
通過幾輪的測試，當專案滿足上線需求之後，會讓開發將**從分支合到master上進行回歸。
回歸測試時，就會將**部署到test1上，test1所對應的**版本一定是master，這時就會在master上進行回歸測試。
03
上線前準備
回歸測試完成之後，通過測試，表明專案已經具備上線的要求了，那這時就開始做上線前的準備，上線前準備一般會為三個步驟：
第一步：確定上線策略
a.上線順序
如果有多個系統上線，上線順序是怎麼樣的？經常我們會有三個系統一起上線，那麼a、b、c三個系統的依賴關係是怎麼樣的？比如b系統的上線功能依賴於a系統的 上線功能，那麼就先上a系統，再上b系統，專案中上線順序根據實際情況確定上線。
b.修復資料策略
如果功能上線之後出現bug，應該怎麼處理？一般我們會設乙個開關，當新功能一旦出現問題，將開關開啟，走原來的老流程。
如果上線之後出現bug，bug影響的資料應該怎麼修復？有時會單條單條的修改資料，但如果資料量太大，單條修復資料這個工作量就很大，那麼在有可能出現bug地方設定乙個點，有可能是task任務，重新跑原來的流程，也有可能是設定乙個狀態，一旦資料出現問題，無法正常進入下乙個流程，那麼設定狀態為error，當bug解決後，可以重試，修復錯誤資料。
c.舊資料分析
這個分析並不是每個專案都需要，僅限新功能上線後分影響老資料的那些專案。
舉乙個簡單的例子：
前陣子做了乙個流程改造的專案，以前流程是：
使用者資料----》先在a系統核驗通過----》入庫到a系統----》再同步到b系統進行業務操作----》最後再將資料同步到a系統
流程改動之後：
使用者資料----》先入庫到b系統，在b系統通過校驗後----》入庫到b系統---->再同步到a系統入庫----》b系統進行業務操作---》最後再將資料同步到a系統
針對這個流程改造專案上線之後，一定會有部分資料在上線之前是走的老流程，同時整個流程又沒走完，那麼在上線的時候就需要新流程去相容老流程遺留下的資料，我們當時是增加了乙個校驗，在老流程中資料是從a系統同步到b系統的，在新流程中資料是從b系統同步到a系統，那麼在b系統同步到a系統時增加乙個校驗去判斷a系統中是否有相應資料的存在，沒有才同步。
第二步：寫上線申請郵件
上線之前，專案測試負責人要寫上線申請郵件，郵件內容包括有：
1.資料配置
有沒有開關？有就需要配置。
資料庫有沒有修改？有新增表，需要事先增表，有修改表結構，需要改表結構。
有沒有外部介面？有就需要配置介面url，否則流程不能跑通，**也不能通。
等等，根據實際情況來寫。
2.上線注意點
可以寫本次專案上線後，會引起的風險，哪些地方可能容易出現問題？需不需要加上監控等？又或者上線之後，需要人為地去監控資料。
3.在郵件中寫清楚上線策略
（第一步中考慮到的上線策略）
第三步：配置線上環境資料
完全以上步驟之後，就可以擇良辰開始上線了，一般上線的許可權只有幾個人有，所以上線的人員是固定的，上**時需要先將線上環境的job停掉，我們也是用jenkins進行自動化部署，只是需要人為的打版號、標籤，部署版本，停djob任務，上線完全之後，啟動djob任務等。
04
上線之後
王豆豆總結了幾點：
1.線上環境資料的複雜度是測試環境不能比擬的。
2.業務操作的不可控性
3.實際場景的複雜性
基於以上三點，這也就是為什麼線上環境總是出現一些測試環境不能發現的bug，排除測試人員漏測的情況。
故，上線之後，測試人員需要做好以下二件事：
第一，灰度測試
專案上線之後，首先是測試人員開始做灰度測試。
灰度測試時，可以設定由業務開關或者白名單之類做控制，只要少量資料或新增在白名單上的資料可以走新業務流程。
灰度測試完全之後，也就是將所有業務流程走完，檢查各項資料的正確性、流程是否通、流程是否完整等等檢查點。
確定無問題時，再將開關開啟，再開放少量真實使用者資料。
第二，監控線上資料
灰度測試時就已經在監控線上資料和檢查線上資料，但因為灰度測試時資料量比較少，有時並不足以引發新問題，所以測試人員需要繼續觀察線上資料。
測試人員需要在專案上線之後的幾個小時內，重點監控線上資料的流向，一旦資料有異常，立即採取措施，回滾**又或者重新開啟開關等，盡量將線上bug引起的損失降到最低，接下來就開始修改bug和修復資料。
在這個時候，測試人員對資料的敏感性特別就要發揮出來，有時似錯非錯的資料正是bug的前兆，千萬不要掉意輕心。
整個專案上線前後的流程就大致如此，不管是上線前的準備還是上線之後資料的觀察都是一環扣一環，這些步驟有息息相關，前面的準備工作做得足，那麼後面監控資料就會相對輕鬆，因為不容易出現問題。
記專案上線流程
技術部門產品及研發部門參加需求評審會議，確定本次專案整體需求以及專案開發工期。注 上線時間安排 若本次無需運營人員參與配合情況下，建議將上線時間安排在下午4點 5點左右，若本次需要運營人員參與配合情況下，建議上線時間安排在下午3點左右。需求工期確定後研發內部進行需求分配及認領。按計畫推進專案程序，編...
關於專案上線流程一覽
網域名稱 新網 萬網 伺服器及網域名稱購買 略 1 任意命令列工具裡輸入ssh root 伺服器公網ip 2 輸入yes，然後輸入伺服器開機密碼。密碼處於安全考慮不會顯示 3 安裝git yum install git 4 安裝node高版本，安好之後就有node和npm curl sl sudo ...
app上線發布流程 APP上線發布流程
上線流程 上線流程的主要步驟 在上線之前對程式進行記憶體動態和靜態分析，注意啟 的螢幕適配，不然會自動拉公升螢幕，使得螢幕自動適配失效 要借助csr檔案生成cer證書檔案 csr的生成是通過鑰匙串生成的 下圖是以真機除錯的development證書截圖，上線發布是選擇add store and ho...