[轉]如何實現「持續集成」？閒魚把研發效率翻了個翻

原文地址：http://www.jintiankansha.me/t/AYnwjUhkWj

 

阿里妹導讀：業務的快速發展，須要咱們更快速地響應，和更高質量產品的交付。如何從原來大(xiao)迭(pu)代(bu)的開發模式切換爲精益開發模式？以 2-1-1（2周需求交付週期，1周需求開發週期，1小時集成時長）爲願景驅動改進，達到持續交付價值，響應業務要求成爲咱們的目標。今天，閒魚工程師琪鈺爲咱們分享：閒魚是怎樣朝着這一目標前進的？切換爲精益開發模式後，又面臨了哪些問題和挑戰？

 

名詞解釋：精益開發模式，團隊基於看板組織協做，以持續地交付需求爲目標，需求按優先級，逐步進入開發、提測。因爲在項目協做中，採用看板泳道來管理需求，所以在閒魚，同窗們習慣稱之爲泳道模式。

 

一、咱們面臨的要求和挑戰

 

• 業務對交付響應時間要求愈來愈快。閒魚業務正處於高速發展中，反摩爾定律告訴咱們，交付越遲，商品價值打折得就越厲害。速度爲王，爲了知足業務快速迭代和試錯對技術團隊可否快速交付需求提出了更大的挑戰。

• 團隊規模變大，項目溝通成本愈來愈高。隨着閒魚業務和技術的快速發展，交付的環境也愈來愈複雜，協做的角色愈來愈多。整個研發過程包含需求管理、開發、測試、發佈、迴歸等關鍵活動，涉及aone（研發協做平臺，主要是需求、bug管理等）、代碼庫、打包平臺、自動化測試平臺等多個系統，溝通協同的成本愈來愈高。

• 多分支並行開發增長額外成本。項目開發切換爲精益開發模式最核心的改變就是各需求是獨立的互不影響，能夠分別獨立進行測試和集成，保持主幹的穩定，隨時拉發佈分支進行灰度發佈。但多分支並行開發，也帶來了新的問題，原來打包配置、手動打包、安裝測試包等人工成本，都成倍的增長。

• 隨時來的提測都可以測。以前客戶端發佈版本時間固定，批量開發、批量提測，測試介入比較晚。項目開發切換爲精益開發模式對技術質量團隊提出了更高的要求，面對多需求同時提測的狀況，如何更快地響應測試。

 

因此，構建一個貫穿從需求到代碼開發，再到測試整個過程的流程，並將其工具化、自動化就顯得十分必要和緊迫，而持續集成就是這一流程的重要形式體現，構建一個高效的持續集成系統擺在咱們面前。這將必定程度下降開發過程當中的溝通成本，流程工具化，加速自動化。

 

如今針對服務端的集成發佈有不少能夠參考的實踐，但對客戶端的集成發佈來講，咱們依然面對以下難點。

 

二、客戶端持續集成的難點

 

• 如何將研發過程當中各環節關聯起來，一個需求從建立到發佈的關鍵活動以下：建立需求->建立代碼分支->建立打包項目->提交代碼->打包->提交測試->修復->提交集成->發佈

• 如何作到需求和代碼分支關聯，確保代碼可追溯；

• 如何作到代碼分支和打包項目關聯，代碼變動可自動觸發打包；

• 如何作到代碼範圍和測試範圍關聯，確保測試迴歸範圍。

 

• 多分支並行，如何有條不紊的進行集成。並行需求分支越多，意味着提交集成時，可能的衝突的機率就會越大。如何下降集成的衝突，以及集成後主乾的穩定性，確保集成質量；

• 如何作到一提交代碼就觸發測試，測試進一步左移；

• 如何下降自動化測試的成本，提升測試效率；

• 而要解決上面的這些難點，缺乏一站式的工具平臺支撐（集團內平臺對服務端的發佈有很好的支持，但對於客戶端的集成發佈來講，涉及平臺工具比較多）。

 

三、怎麼作客戶端持續集成

 

爲了解決從需求建立到發佈整個項目研發過程當中協同、構建、集成和測試等遇到的問題，提升團隊的持續交付能力。針對客戶端集成發佈，咱們的總體方案的目標是首先是拉通整個需求交付流程中各個環節，簡化持續交付工做，提供及時的質量反饋機制，讓開發同窗關注在業務的開發；有效提升集成成功率及縮短集成發佈週期，讓版本可以按時上線你們可以按時下班；建設可視化、自動化、智能化的持續集成流水線，讓業務需求真正的可持續交付。

 

空談誤國，實幹興邦。在談論更多的改進以前，咱們先把基礎本的流程經過工具先串起來，只有先看到總體，而後再發現問題逐步改進。

 

流程化

 

 

咱們的核心流程是這樣的，一旦建立需求分支，交付通道就已創建，直到需求發佈。

 

• 首先開發按照規範建立需求分支後，自動將分支和需求進行綁定，同時建立打包項目後，自動將需求和打包地址進行綁定，這樣開發同窗一旦提交代碼，就能夠根據需求、代碼提交內容等，給出影響範圍，同時自動觸發打包，開發和測試同窗不用再擔憂最新的包中是否有剛提交的內容，每次變動都會觸發打包；

• 打包成功後，根據 merge request、push 定時等不一樣的觸發方式，及分支類型，自動觸發相應的測試件，進行一系列的自動化測試；

• 測試件執行完後，執行結果將被及時反饋出來，確保每次代碼變動都是通過測試驗證的，測試進一步左移，並將問題在團隊項目協做看板上將問題標示出來，幫助團隊在項目協做中可以持續的發現問題從而提升集成質量，下降發佈風險，保證業務更快更順暢的交付。

 

當完成了第一步，將整個流程打通以後，咱們發現，在整個流程中，依然有不少是依賴人工操做的地方，這是最容易出錯，而且極低地影響效率的地方，對咱們來講，這是改進的機會，因此，第二步咱們的重點就是作好無人化和自動化。

 

無人化

 

爲了支撐持續集成流水線的運行，以無人化、自動化、可擴展爲目標，及基於最小研發成本原則，咱們作得事情主要分爲精益開發流程協同支撐無人化及測試驗證自動化兩部分。

 

 

fish CI 主要是研發流程支撐，如需求綁定、監聽變動、觸發打包、觸發測試等，fish guard 主要測試件調度、執行，結果通知，及後續測試件接入擴展部分。目前已接入的測試件主要有 UI 遍歷、UI 識別、monkey、單元測試等。後續計劃按照分層測試的原則，接入更多的測試件，如代碼靜態掃描、weex 自動化測試、服務端測試件等，加強測試件覆蓋度，拓展自動化測試邊界。關於這一部分，咱們將在後面的文章中作更深刻的分享。

 

數據度量

 

管理學之父彼得德魯克說：「若是你不能度量它，你就沒法改進它」，其實也是咱們整個持續集成流水線的自檢，咱們到底作得怎麼樣，持續交付的能力如何，咱們定義了以下指標用於後續統計。

 

 

指標主要分爲響應能力、效率、質量三個維度，經過響應能力的這些指標，能夠反應出打包變快了，質量反饋變快了，集成變快了，集成頻率變高了；有效率的指標，反應出流水線工做的有效性，成功率越高說明流水線越穩定；最後質量，主要從代碼質量和項目測試質量來度量，經過修改的文件數，模塊分佈能夠反映出代碼的拆分、依賴等狀況；經過項目測試中 bug 的分佈和庫存，能夠反映出項目質量狀況，是否及時發現及時修復，是否達到發佈標準等。

 

四、效果

 

閒魚從3月中旬開始試運行精益開發模式（持續交付模式）到如今，閒魚全部的業務需求所有走精益開發模式，咱們交付的速度，由一個月一個版本到兩週一個版本。這離不開咱們在流水線各個環節中的改進，如打包變快了，需求分支構建次數愈來愈多，集成頻率愈來愈高，以及自動化測試驗證及時反饋集成質量狀況。此外，閒魚在精益開發模式下質量得到了明顯提高，以下圖所示：

 

 

綠色分割線左半部分，是以前未切換到泳道模式前的一個版本，bug 趨勢看，前面編碼階段，測試基本未介入，大量的代碼批量集成後集中測試，在缺陷充分被移除後，才能交付，沒法持續交付。綠色分割線右半部分，是某個業務線的缺陷趨勢圖，小批量的持續集成、及時測試和發現問題、及時修復，能夠快速持續交付。

 

五、總結與規劃

 

簡單總結下，咱們作的事情，第一步是拉通整個交付過程，有一個穩定的交付過程，第二步保證交付的效率，即響應變快了，集成變快了，質量反饋變快了，第三步持續交付，關鍵詞是「持續地」，頻次上提出了更高的要求，集成的頻率變高了，之前一個月集成一次，如今天天都能集成，從一個月一次，到 nightly build，再到隨時集成。即相比之前，讓開發同窗「更」有信心集成一次變動併發布。

 

所以，咱們的終極目標就是7*24隨時發佈，沒有發佈窗口限制，真正作到交付流水線自動化無人化和全自動化測試，下降持續構建成本，拓展自動化測試邊界。