阿里妹導讀：業務的快速發展，需要我們更快速地響應，和更高質量產品的交付。如何從原來大(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隨時發布，沒有發布窗口限制，真正做到交付流水線自動化無人化和全自動化測試，降低持續構建成本，拓展自動化測試邊界。

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的如何实现“持续集成”？闲鱼把研发效率翻了个翻的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。