109
GOPS全球運維大會深圳峰會第二天會議分享
GOPS全球運維大會深圳峰會於4月21日舉行，本文是峰會的第二天會議紀要分享，本文主要包括微服務的架構介紹及QA形式的深度交流問題記錄。
一、《基於DevOps的微服務生態係統與工程實踐》分享者華為的王磊，《微服務架構與實踐》的作者，《DevOpsHandbook》中文譯者之一。重點講解了什麼是微服務，微服務的三個原則（以縮短交付周期為核心、基於DevOps、演進式架構），以及微服務的生態係統和工程化實踐，偏理論性東西較多。下圖為微服務的生態係統：
二、《持續集成交付部署》的深度交流場，主要以QA的形式座談，問答嘉賓是百度的黎嘉豪和普元的劉相，大家對這個深度交流的反饋都比較好，嘉賓的能力也都較強，記錄了幾個問題。
Q：持續集成時怎樣減小代碼衝突，是否有更好的合並分支的實踐？（背景一個分支一個feature，幾個人開發）
A：分支合並衝突主要原因是分支差異大，迭代周期長，合並時衝突就會比較大。騰訊的經驗：騰訊要求一個項目分支7天內要合並到主幹，主幹的代碼每天都要rebase到分支。在架構方麵QQ已經成為一個孵化器，QQ周邊的所有應用底層架構都用一套，所以底層架構的衝突幾乎沒有。
開發分支一般分兩種方式：1）主幹開發，分支發布，一個迭代周期內（2周一個迭代）都在主幹上開發，發布時拉分支發布，好處是每天都會構建一個可被PM或老板看的版本，QA也隻關注主幹的測試即可。如果期間發現bug，因為是在迭代期內，所以在此主幹上修改，如果是已發布的版本的bug，基於Release的分支再拉分支修改，修改後要rebase到主幹。壞處是前期代碼提交時衝突會比較多，適合於小型開發團隊，嘉賓黎嘉豪強烈推薦此種方式。
2）分支開發，主幹發布，這種常見的衝突是功能衝突，分支1和分支2合並主幹後，功能上有衝突，因為各分支不知道互相在做什麼事，QA針對於分支的測試可能合並到主幹後測試結果與分支的測試結果不一樣。
Q：如果公司要踐行DevOps，一般都有哪些角色的人？
A：流程人員(一般由敏捷教練擔任)、RD、QA、DevOps工程師(負責把交付周期的各個平台和工具串起來)、Gate-keeper(把關人，如產品經理)、OP(準備上線的平台，及平台的配置等信息，並且把信息透漏給RD)。
Q：測試的前期環境及數據準備太麻煩，怎麼解？
A：普元的經驗分享：業務測試按三角型的層次可以分為：最下層單元測試UT、中間層集成測試IT，最上層場景化集成測試SIT。首先單元測試是必須要有的，08年到10年實行測試人員與開發人員輪崗，通過培訓、輪崗、逃汰三種機製給測試人員賦能可以寫代碼，具備自動化測試的能力，這樣搭建開發測試環境及數據準備就不是難事。其次是集成測試，集成測試也是必須的，一般指功能性的集成測試。關於場景的集成測試不能保證都覆蓋掉，經驗是通過日誌分析用戶最常用的場景，先把top的場景集成測試做起來。整體測試代碼與業務代碼的的比例是9：1。分開API測試與UI測試，上麵所講到的都是API測試，UI測試使用Selenium做到了部分自動化。關於UI的自動化測試提到一點比較可取：將測試成功的頁麵做個snapshot做圖片存儲，以後每次跑這個頁麵的測試後的圖片與存儲正確的圖片做diff，如果與預期不符（如彈出錯誤框）就可以很快的反饋結果。
Q：內部產品版本更新後如何通知幾千個用戶？雖然有幫助文檔但用戶都不看，怎麼破？
A：引導頁、人工智能、爬蟲等技術加入到產品支持平台。另外每次版本更新的新功能要寫一個比較“逗逼”的文章，或有喜感的PPT，這樣宣講完印象會比較深，其次產品經理要見人就說新功能是什麼，不斷的“安利”。
Q：Jenkins的Job怎麼配置，有什麼最佳實踐？為什麼一個測試的job就要有10多個?
A：JOB創建的準則：RD在提交代碼後在20分鍾之內對提交的代碼有簡單的報告顯示。單從測試角度說就有UT測試、功能測試、性能測試、壓力測試等等，每個測試用1-2個job實現。整個JOB鏈路可以分為 單元測試、codeReview、API兼容性測試、代碼規範檢查、安全測試(如數據庫連接是否關閉)、分布式編譯、發布到質品庫、打鏡像、發布到沙盒、預發。對於最後集成將以前的push模式改為pull的模式，各個微服務保證自己的流水線構建產出物的穩定（自證清白），集成時采用pull的模式拉取各個微服務的穩定版本集成。因為是各個微服務並行編譯，所以會縮短集成時間。
Q：DevOps可視化都做些什麼？
A：DevOps最後的精華就是度量、就是可視化。舉幾個例子：
- IT團隊的能力：一個周期內能產生多少個Feature，有多少個產品在做，都在什麼階段、有多少個版本。
- 從工程效率角度出報表，哪個環節影響效率。
- 內部過程數據文檔都有記錄，不擔心關鍵崗位人員的離職。
最後更新：2017-04-22 23:30:49