目前公司項目偏多，平均每周五天基本上有四天都會有項目上線，有時一天會上線至少二個版本，就在昨天剛上線了一個項目，星期一才提測的一個項目，星期二就安排上線了，所以悄悄地告訴小伙伴們，昨晚俺加班了(再悄悄地告訴大家其實這個昨晚已經過去很久了~微笑臉)，今天跟小伙伴們分享一下王豆豆公司的上線流程。
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
上線之后
對於測試人員來說，並不是你測試完全，項目上到線上(生產）環境上就OK了，就不關你的事了，而實則項目上線之后才是真正對測試人員的考驗，測試人員經常疑或為什么總有一些BUG是在線上環境中才會被發現？
王豆豆總結了幾點：
1.線上環境數據的復雜度是測試環境不能比擬的。
2.業務操作的不可控性
3.實際場景的復雜性
基於以上三點，這也就是為什么線上環境總是出現一些測試環境不能發現的BUG，排除測試人員漏測的情況。
故，上線之后，測試人員需要做好以下二件事：
第一，灰度測試
項目上線之后，首先是測試人員開始做灰度測試。
灰度測試時，可以設置由業務開關或者白名單之類做控制，只要少量數據或添加在白名單上的數據可以走新業務流程。
灰度測試完全之后，也就是將所有業務流程走完，檢查各項數據的正確性、流程是否通、流程是否完整等等檢查點。
確定無問題時，再將開關打開，再開放少量真實用戶數據。
第二，監控線上數據
灰度測試時就已經在監控線上數據和檢查線上數據，但因為灰度測試時數據量比較少，有時並不足以引發新問題，所以測試人員需要繼續觀察線上數據。
測試人員需要在項目上線之后的幾個小時內，重點監控線上數據的流向，一旦數據有異常，立即采取措施，回滾代碼又或者重新打開開關等，盡量將線上bug引起的損失降到最低，接下來就開始修改bug和修復數據。
在這個時候，測試人員對數據的敏感性特別就要發揮出來，有時似錯非錯的數據正是BUG的前兆，千萬不要掉意輕心。
整個項目上線前后的流程就大致如此，不管是上線前的准備還是上線之后數據的觀察都是一環扣一環，這些步驟有息息相關，前面的准備工作做得足，那么后面監控數據就會相對輕松，因為不容易出現問題。
歡迎大家分享和轉載王豆豆的文章，關注王豆豆的微信公眾號
資深Tester（zishentester），和王豆豆一起成長。