我們正在路上—從持續整合到持續釋出

沉默術士發表於2017-07-03
　持續整合作為一種很好的軟體工程實踐被很多團隊所採用，和其他一些先進的實踐一樣，它最終的目的一定是服務於產品的。產品的價值最終體現在使用者體驗的提升，而這個的前提就是產品的每一次更新能夠及時地傳遞給使用者，對於運維團隊來說就是更快地在生產環境中部署最新的產品，對於研發團隊來說就是更頻繁地釋出可以工作的軟體。
　　暫且拋開業界非常流行的DevOps理念，單純地從研發團隊來看，如何快速的釋出對使用者有價值的軟體是重中之重。
　　那結合持續整合，我們又可以做些什麼呢？
　　先來看看我們持續整合的現狀
　　獨立的環境：持續整合往往有一套獨立的測試環境，而團隊還會在其他測試環境中進行測試，兩者似乎從來沒有交集
　　獨立的構建：持續整合往往就是對當前最新的程式碼做一些自動化的測試，而完全忽略了軟體版本的管理，甚至不能很好的保證各種測試是否是基於同一份程式碼
　　輔助手段：持續整合往往作為一種測試的輔助手段，更多的是用於快速發現程式碼提交階段的錯誤
　　以上這些在持續整合初期完全沒有問題，而且這種方式也的確帶來了不少的價值，能夠幫助團隊更透明地瞭解產品的質量，並且快速的定位和解決問題。只是，我們可以做的更多
　　再來展望下持續釋出的流程
　　整體的思路就是以持續整合流水線作為核心，把軟體釋出的各個環節透明地展示給團隊，並且通過流水線來管理版本的釋出流程
　　測試環境整合：打通持續整合環境/手工測試環境/線上模擬環境，保證一條流水線上使用同一份程式碼，同一份構建物
　　測試流程整合：一鍵式的環境部署和一鍵式的版本管理（打TAG，拉分支，構建物的儲存等），釋出前對產品質量有清晰的瞭解
　　重要和主要手段：以持續釋出流水線為基準，並積極擴充其他型別的測試
　　把持續整合融入到產品開發和釋出階段，而不是簡單地搭建一套“自動化執行任務”，並充分利用構建流水線實現流程和質量的雙重把控
　　最後來看下某個產品初步定義的持續釋出的流程
　　產品現狀
　　三套環境：持續整合環境（雲主機），手工測試環境（雲主機），線上模擬環境（物理機）
　　持續整合狀態
　　自動化的編譯，打包，部署，冒煙測試和快速效能測試已經實現自動化並實時通過程式碼提交觸發，全程20分鐘左右
　　單元測試和靜態程式碼檢查還在完善中，也實時通過程式碼提交觸發，不過沒有列入關鍵點，也就是成功與失敗並不直接影響構建流程
　　每日的功能測試（1000+個測試用例）在晚間執行，全程3個小時左右
　　新功能測試在手工測試環境下進行
　　上線前需要線上上模擬環境進行效能測試和穩定性測試
　持續釋出流水線
　　持續整合環境實時保證當前的提交沒有破壞基本功能
　　通過手工觸發（QA人員控制），一鍵部署產品到手工測試環境並能在流水線上展示手工測試結果（通過簡單的設定一個變數達到效果）；同時可以選擇觸發功能測試，達到同步的執行
　　如果QA人員認為當前測試版本可以達到內部發布要求，可以一鍵打TAG，並生成和儲存dist包
　　通過手工觸發（QA人員控制），一鍵部署dist包到模擬線上環境，而後自動化進行效能測試和穩定性測試
　　理想狀態這步應該是自動觸發，由於目前機器的不可獨佔性，暫時只能手工觸發
　　自動化的效能測試和穩定性測試還是實施中
　　最終版本的對外發布也是通過手工觸發（QA人員控制）
　　以上的流程是根據專案/產品的需求和現狀制定的，只是一些思路可以借鑑，具體的實施一定要結合實際情況，因地制宜的開展
　　Jenkins持續釋出流水線
　　幾個Jenkins持續釋出流水線配置小Tips
　　通過BuildNameSetterPlugin顯示當次流水線構建的版本（SVN revision或是Git revision）
　　通過ParameterizedTriggerPlugin自動觸發下游任務，並把構建版本資訊傳遞下去
　　通過CopyArtifactPlugin用於構建物的部署
　　通過BuildPipelinePlugin手工觸發某些任務，用於需要人工介入的階段
最新內容請見作者的GitHub頁：http://qaseven.github.io/


相關文章