聊聊Google DSM產品的發佈

只有產品順利的發佈給用戶使用並得到良好反饋，整個團隊的價值纔有所體現。

引言

不知不覺，從13年接手Google Doubleclick Sales Manager到今年7月，4年經歷了3個milestone, beta, GA最終和ad exchange集成，一路走來，冷暖自知。
開始前作個調查，你們的項目發佈週期是如何的，能夠在回覆裏打數字：

1. 無固定發佈週期
2. 每週發佈
3. 每兩週發佈
4. 每個月發佈
5. 更長的發佈週期

DSM如何作發佈

DSM項目的發佈狀況，分爲兩大塊：
常規的每週發佈和新功能發佈

常規的每週發佈

• 上線的標準很簡單，就是沒有P0/P1的bug

• 發佈流程見下圖

 

 

 

• 從TAP(Test Automation Platform)中自動獲取最近三小時跑綠的Changelist(CL),而後build新的版本
• 發佈到QA環境
• QA環境的自動化測試和手工測試
• 若是發現P0/P1的bug，提交給開發修復，從新打補丁發佈到QA
• QA環境驗證bug後並sign off後發佈到Canary環境
• Canary環境停留3到6個小時，檢查監控系統eye3

• eye3系統沒有錯誤報告，最終上線

  • 下圖是Rapid(Release Automation Platform in DevInfra)系統中一個完整的發佈過程
     
  • Rapid系統自動建立一個候選包
     
  • 同時運行webdriver自動化測試(TAP上通常執行UT和ServiceTest, UI test耗時單獨跑)
     
  • 將候選包發佈到QA環境，自動建立當周的release bug和hotlist, 上到QA環境後運行screen diff
     
  • QA測試完成Sign off後陸續發佈到Canary和Prod環境

新功能發佈

• 每一個新功能都有單獨的功能開關

   

   

• 每一個新功能都創建一個新功能類別的bug，讓全部參與人有一個統一的溝通渠道，保證信息是同步的

   

   

• 新功能上線申請表，有若干檢查項

   
  
  
   
  
  
   
  
  
   

   

• 若是新功能上線發現重大問題，能夠快速的關閉

碰到的問題與解決

• TAP可能不能獲取到最近三小時綠色CL，怎麼辦？

  • 創建一個build cop的三人小組，每週五和每週一關注TAP greenness
     
  • 若是超過10個小時TAP仍是紅色，須要緊急處理，保證每週發佈有可靠的基準CL
     

• 迴歸測試中有可能P2的bug實際是P1的

  • 測試完成後，發現的bug通過TLs(Tech Leader)再次審覈來決定P2的bug是否須要Cherrypick
  • 迴歸測試結束後須要有個sign off的過程

• 如何知道新功能能夠測試了？

  • 從Feature bug中拿到開發最後一個CL，在cl-status(一個輔助工具)裏查詢
     
  • 輔助的Chrome插件工具
     

• 怎樣方便的獲取錯誤日誌信息，有助於開發快速定位修復發現的bug

  • 輔助的Chrome插件工具
     

• 上線後發現問題如何處理？

  • Eye3監控機制
  • Oncall機制
  • 回滾機制
  • Cherrypick機制
  • 剖屍機制

達成

• 肯定了上面的流程，QA團隊一週的時間分配天然也就有了

   

   

• 統計每週發佈狀況瞭解產品是否穩定

   

   

• 順利運行後大大縮減迴歸時間，同時CP(Cherrypick)的數量減小

• 有更多的時間投入到新功能測試以及自動化測試

後記

• 後續的改進：

  • API加速發佈： 將API和FE進行剝離，API經過高覆蓋率的自動化測試，從一週一發到一週四發
  • 兼容性測試： API和FE剝離後，API會有三個版本比FE新，引入兼容性測試，保證FE穩定
  • 上線時間定在每週四： 這樣有問題週五處理，不用週末加班

• 關於每週發佈
  幾年的每週發佈作下來，發現每週發佈對團隊的壓力很大，基本天天有明確的任務，雖然迴歸時間從2天減到1天，可是每週超過3個新功能沒有任何喘息時間，不利於團隊成員反思。我的體會最理想的狀況仍是兩週一次發佈。

結尾

從事測試12載，一直比較喜歡參與面向客戶的產品，無論這幾年測試行業的稱謂從測試到測試開發到工具開發，仍是以爲本身就是測試工程師。近幾年發現，僅僅作測試執行，學習測試技術運用，遠遠沒有推進整個團隊的測試質量提高更有成就感。