阿裡妹導讀：業務的快速發展，需要我們更快速地響應，和更高品質産品的傳遞。如何從原來大(xiao)疊(pu)代(bu)的開發模式切換為精益開發模式？以 2-1-1（2周需求傳遞周期，1周需求開發周期，1小時內建時長）為願景驅動改進，達到持續傳遞價值，響應業務要求成為我們的目标。今天，閑魚工程師琪钰為我們分享：閑魚是怎樣朝着這一目标前進的？切換為精益開發模式後，又面臨了哪些問題和挑戰？
名詞解釋：精益開發模式，團隊基于看闆組織協作，以持續地傳遞需求為目标，需求按優先級，逐漸進入開發、提測。由于在項目協作中，采用看闆泳道來管理需求，是以在閑魚，同學們習慣稱之為泳道模式。
1、我們面臨的要求和挑戰
- 業務對傳遞響應時間要求越來越快。閑魚業務正處于高速發展中，反摩爾定律告訴我們，傳遞越遲，商品價值打折得就越厲害。速度為王，為了滿足業務快速疊代和試錯對技術團隊能否快速傳遞需求提出了更大的挑戰。
- 團隊規模變大，項目溝通成本越來越高。随着閑魚業務和技術的快速發展，傳遞的環境也越來越複雜，協作的角色越來越多。整個研發過程包含需求管理、開發、測試、釋出、回歸等關鍵活動，涉及aone（研發協作平台，主要是需求、bug管理等）、代碼庫、打包平台、自動化測試平台等多個系統，溝通協同的成本越來越高。
- 多分支并行開發增加額外成本。項目開發切換為精益開發模式最核心的改變就是各需求是獨立的互不影響，可以分别獨立進行測試和內建，保持主幹的穩定，随時拉釋出分支進行灰階釋出。但多分支并行開發，也帶來了新的問題，原來打包配置、手動打包、安裝測試包等人工成本，都成倍的增加。
- 随時來的提測都能夠測。之前用戶端釋出版本時間固定，批量開發、批量提測，測試介入比較晚。項目開發切換為精益開發模式對技術品質團隊提出了更高的要求，面對多需求同時提測的情況，如何更快地響應測試。
是以，建構一個貫穿從需求到代碼開發，再到測試整個過程的流程，并将其工具化、自動化就顯得十分必要和緊迫，而持續內建就是這一流程的重要形式展現，建構一個高效的持續內建系統擺在我們面前。這将一定程度降低開發過程中的溝通成本，流程工具化，加速自動化。
現在針對服務端的內建釋出有很多可以參考的實踐，但對用戶端的內建釋出來說，我們依然面對如下難點。
2、用戶端持續內建的難點
- 如何将研發過程中各環節關聯起來，一個需求從建立到釋出的關鍵活動如下：建立需求->建立代碼分支->建立打包項目->送出代碼->打包->送出測試->修複->送出內建->釋出
如何做到需求和代碼分支關聯，確定代碼可追溯；
如何做到代碼分支和打包項目關聯，代碼變更可自動觸發打包；
如何做到代碼範圍和測試範圍關聯，確定測試回歸範圍。
- 多分支并行，如何有條不紊的進行內建。并行需求分支越多，意味着送出內建時，可能的沖突的機率就會越大。如何降低內建的沖突，以及內建後主幹的穩定性，確定內建品質；
- 如何做到一送出代碼就觸發測試，測試進一步左移；
- 如何降低自動化測試的成本，提高測試效率；
而要解決上面的這些難點，缺少一站式的工具平台支撐（集團内平台對服務端的釋出有很好的支援，但對于用戶端的內建釋出來說，涉及平台工具比較多）。
3、怎麼做用戶端持續內建
為了解決從需求建立到釋出整個項目研發過程中協同、建構、內建和測試等遇到的問題，提高團隊的持續傳遞能力。針對用戶端內建釋出，我們的整體方案的目标是首先是拉通整個需求傳遞流程中各個環節，簡化持續傳遞工作，提供及時的品質回報機制，讓開發同學關注在業務的開發；有效提高內建成功率及縮短內建釋出周期，讓版本能夠按時上線大家能夠按時下班；建設可視化、自動化、智能化的持續內建流水線，讓業務需求真正的可持續傳遞。
空談誤國，實幹興邦。在談論更多的改進之前，我們先把基礎本的流程通過工具先串起來，隻有先看到整體，然後再發現問題逐漸改進。
流程化
我們的核心流程是這樣的，一旦建立需求分支，傳遞通道就已建立，直到需求釋出。
- 首先開發按照規範建立需求分支後，自動将分支和需求進行綁定，同時建立打包項目後，自動将需求和打包位址進行綁定，這樣開發同學一旦送出代碼，就可以根據需求、代碼送出内容等，給出影響範圍，同時自動觸發打包，開發和測試同學不用再擔心最新的包中是否有剛送出的内容，每次變更都會觸發打包；
- 打包成功後，根據 merge request、push 定時等不同的觸發方式，及分支類型，自動觸發相應的測試件，進行一系列的自動化測試；
- 測試件執行完後，執行結果将被及時回報出來，確定每次代碼變更都是經過測試驗證的，測試進一步左移，并将問題在團隊項目協作看闆上将問題标示出來，幫助團隊在項目協作中能夠持續的發現問題進而提高內建品質，降低釋出風險，保證業務更快更順暢的傳遞。
當完成了第一步，将整個流程打通之後，我們發現，在整個流程中，依然有很多是依賴人工操作的地方，這是最容易出錯，并且極低地影響效率的地方，對我們來說，這是改進的機會，是以，第二步我們的重點就是做好無人化和自動化。
無人化
為了支撐持續內建流水線的運作，以無人化、自動化、可擴充為目标，及基于最小研發成本原則，我們做得事情主要分為精益開發流程協同支撐無人化及測試驗證自動化兩部分。
fish CI 主要是研發流程支撐，如需求綁定、監聽變更、觸發打包、觸發測試等，fish guard 主要測試件排程、執行，結果通知，及後續測試件接入擴充部分。目前已接入的測試件主要有 UI 周遊、UI 識别、monkey、單元測試等。後續計劃按照分層測試的原則，接入更多的測試件，如代碼靜态掃描、weex 自動化測試、服務端測試件等，增強測試件覆寫度，拓展自動化測試邊界。關于這一部分，我們将在後面的文章中做更深入的分享。
資料度量
管理學之父彼得德魯克說：“如果你不能度量它，你就無法改進它”，其實也是我們整個持續內建流水線的自檢，我們到底做得怎麼樣，持續傳遞的能力如何，我們定義了如下名額用于後續統計。
名額主要分為響應能力、效率、品質三個次元，通過響應能力的這些名額，可以反應出打包變快了，品質回報變快了，內建變快了，內建頻率變高了；有效率的名額，反應出流水線工作的有效性，成功率越高說明流水線越穩定；最後品質，主要從代碼品質和項目測試品質來度量，通過修改的檔案數，子產品分布可以反映出代碼的拆分、依賴等情況；通過項目測試中 bug 的分布和庫存，可以反映出項目品質情況，是否及時發現及時修複，是否達到釋出标準等。
4、效果
閑魚從3月中旬開始試運作精益開發模式（持續傳遞模式）到現在，閑魚所有的業務需求全部走精益開發模式，我們傳遞的速度，由一個月一個版本到兩周一個版本。這離不開我們在流水線各個環節中的改進，如打包變快了，需求分支建構次數越來越多，內建頻率越來越高，以及自動化測試驗證及時回報內建品質情況。此外，閑魚在精益開發模式下品質獲得了明顯提升，如下圖所示：
綠色分割線左半部分，是之前未切換到泳道模式前的一個版本，bug 趨勢看，前面編碼階段，測試基本未介入，大量的代碼批量內建後集中測試，在缺陷充分被移除後，才能傳遞，無法持續傳遞。綠色分割線右半部分，是某個業務線的缺陷趨勢圖，小批量的持續內建、及時測試和發現問題、及時修複，可以快速持續傳遞。
5、總結與規劃
簡單總結下，我們做的事情，第一步是拉通整個傳遞過程，有一個穩定的傳遞過程，第二步保證傳遞的效率，即響應變快了，內建變快了，品質回報變快了，第三步持續傳遞，關鍵詞是“持續地”，頻次上提出了更高的要求，內建的頻率變高了，以前一個月內建一次，現在每天都能內建，從一個月一次，到 nightly build，再到随時內建。即相比以前，讓開發同學“更”有信心內建一次變更并釋出。
是以，我們的終極目标就是7*24随時釋出，沒有釋出視窗限制，真正做到傳遞流水線自動化無人化和全自動化測試，降低持續建構成本，拓展自動化測試邊界。
原文釋出時間為： 2019-05-24
本文作者： 琪钰
本文來自雲栖社群合作夥伴“
阿裡技術”，了解相關資訊可以關注“
”。