本文由團隊內大瑤同學撰寫，

引言

移動App具有更新頻繁的特性，這一點，從各大App在應用市場的版本發布頻率可見一斑，高頻發布意味著迅速迭代和交付，這對需求、開發、測驗、運維的效率提出了更高的要求，那么，在快速變化的互聯網環境下，如何在保證質量的前提下，提高App的交付速度？這是業界共同面臨的問題，DevOps提供了解決該問題的答案，它倡導盡可能多地對軟體構建程序中的所有步驟進行自動化處理，也就是構建自動化流水線，以提高效率、縮短開發周期，在當今的IT領域，DevOps倡導的持續交付理念已經被普遍接受，實施DevOps實踐已經成為軟體組織管理的趨勢，近幾年，隨著敏捷軟體模式的深化，我們也一直在嘗試敏捷、持續集成等實踐，以積極的態度擁抱DevOps，

值得重視的是，DevOps并非一個固定的模式或標準，事實上，業界對DevOps沒有統一的定義（而且DevOps的定義是隨著時間不斷演變的），它是一種普適的軟體工程文化和實踐，但每個企業的組織文化有差異，DevOps基礎也不盡相同，現有的一些成功方案往往并不完全適合團隊的實際情況，業界也不存在一個萬能的實體供我們復制，因此，應當基于自身實際情況，參考同類優秀案例和經驗，摸索出最適合自己的模式，一方面，我們缺乏專門的工具部門或團隊，短時間內無法建立起大型的一體化持續交付平臺；另一方面，我們又急需建立起持續交付流水線，以改進敏捷產品的開發測驗流程，因此，我們以開源持續集成工具為核心，再適當開發輔助工具，構建了一個較為實用的App產品持續交付流水線，

一、案例背景

隨著App的功能日益復雜，與第三方合作的模塊越來越多，開發、測驗階段聯調的難度也隨之增加，同時，為迅速回應市場需求變化，App的迭代越來越快，發布周期越來越短，工期緊、任務多，這給開發、測驗人員帶來了很大的壓力，例如，開發為了按時完成代碼，擠壓了一些本來用于代碼評審、單元測驗的時間，導致專案代碼的質量下降；隨之而來的是生產風險的提高，產品質量難以保障；開發需要花費額外的精力償還技術債（漏洞、不規范的代碼等），這又給新一輪迭代帶來風險——如此便陷入“疲于奔命”的惡性回圈，

為解決上述問題，在參考DevOps等主流解決方案基礎上，我們也吸收DevOps和敏捷理念，開展App產品持續交付流水線實踐，從工藝改進、組織文化等方面，改進App產品的持續交付實施程序，最終構建起一條完備的流水線，

二、案例內容

（一）問題分析

與其他產品不同，App的交付比較特殊，例如，H5產品需要將部署包放置到服務器上，并進行相應的配置，用戶就可以通過訪問網址獲取服務；而安卓和IOS并不是部署在企業自己的服務器上，而是需要在各自的應用市場“上架”，用戶才能從市場上獲取App，安裝到自己的手機上，完成交付程序，

對癥方能下藥，我們首先必須明確，是什么影響了App的迭代效率？經過分析和總結，我們發現，App的實施程序存在以下痛點：

1、開發任務繁重，代碼質量不高，

造成這一點的原因有很多，如需求規劃不合理、環境問題導致聯調失敗、代碼評審不到位、測驗覆寫不全面等，

2、版本分發效率低，

由于App產品的特殊性，用戶必須在手機上安裝新版本才能獲取其服務，在開發人員頻繁打出新版本的場景下，測驗者需要及時獲得最新的App版本，然而現實情況通常是開發在自己的電腦上構建（俗稱“打包”），再把構建出的App安裝包發給測驗人員——這樣人工的構建分發效率低，也難以保證構建出的安裝包是“合格”（即通過了單元測驗、代碼掃描等必要的檢查環節）的，

3、容易出現不同環境下版本不一致問題，

在測驗階段，測驗人員通常對測驗環境下的版本進行測驗，而產品發布時，使用的是測驗版本對應的生產版本，必須做到這個兩個版本除了環境相關的引數配置不同外，其他代碼完全一致，然而從測驗通過到人工切換成生產環境引數并構建生產版本的這段時間，可能會存在開發人員改動代碼的風險，導致一個未經測驗的App版本被發布，因此，需要尋求同時構建多個不同環境引數的App的方案，

4、測驗分析不到位，同類質量問題重復出現，

我們的目的不僅僅是修復問題，而且要保證日后不再發生同樣的錯誤，事實上，一個產品的缺陷可以給其他產品帶來啟發，我們需要吸取他人的經驗和教訓，加強不同產品之間的交流，

以上幾個問題，其實都是缺乏規范的流程、人工介入過多等原因造成的，當人工操作影響到作業效率時，應當考慮借助工具來節省人力，提高效率，

（二）方法體系

從工藝改進和組織文化兩個方面入手，逐步構建起持續交付的實施流程和與之匹配的組織結構，

1、從工藝改進的角度，構建App持續交付流水線，

● 分別對DevOps的各個步驟進行優化和改進，并組合成一潭訓于Jenkins自動化持續交付流水線，覆寫從需求到交付的各個環節，從實施流程上規范App交付的各個環節，如優化需求拆分、強化代碼評審等步驟，提高代碼質量，

● 自主開發小型工具，如App持續交付工具、擋板系統等，完善上述流水線，以提高開發、測驗效率，

2、進行組織結構調整，開展開發測驗融合實踐，

● 在開發測驗融合思維的導向下，開發與測驗團隊被規劃到同一部門，這消除了部門壁壘，使得敏捷迭代中開發、測驗成為一個整體，強化了二者的溝通和聯系，

● 強化質量監督環節，測驗團隊發揮QA作用，測驗團隊不再僅僅負責傳統的測驗作業，而是統籌測驗實施、質量管理、工藝改進三大板塊，在這種模式下，測驗團隊不僅僅負責傳統的測驗實施任務，還要深入敏捷團隊，擔任QA角色，監督自動化測驗、持續集成等環節，從更高層次上把控產品質量，

● 開展DevOps相關的交流活動，如開放日、系列培訓等，在部門內部、部門之間進行推廣和交流，互相借鑒經驗，培養員工的持續交付理念和能力，

（三）構建持續交付流水線

在各類資源有限的情況下，我們必然要借助現有工具來支持持續交付實施程序，作為最受歡迎的CI工具之一，Jenkins成為我們的首選平臺，它以插件的形式支持各種功能（官方提供了豐富的插件庫，開發者也可以根據官方API開發定制化插件），此外，Jira、Sonarqube等受業界認可的工具成為流水線的組成部分，

1、App持續交付流水線

正所謂“工欲善其事，必先利其器”，自動化流水線的搭建必然需要借助工具，業界對于持續交付流水線工具的選擇，可以大概分為兩類：一是使用通用的CI、CD工具，二是使用一體化DevOps平臺，前者靈活通用、不需要太多成本，但缺少業務元素；后者提供一站式解決方案，但通用性不強，

既然短時間內不具備采購或自主開發一體化DevOps平臺的條件，我們選擇前者來實作交付流水線，如圖1所示，將各個環節如同串珠子一樣串聯起來，組合成完整的流水線，

圖1 App交付流水線

1）需求/知識：需求決定了任務量，進而決定了開發、測驗的作業量，也直接影響代碼的質量，因此，要從流水線源頭進行改進，避免因需求規劃不合理影響開發效率，

● 過去：存在需求堆積、粒度過粗、變化頻繁，把開發“逼瘋”的情況；過分依賴人工看板，不容易統計迭代燃盡圖、故事活躍度等資料， 

● 現在：合理規劃需求、減少任務粒度，減輕迭代作業量，為實作小步交付做準備；使用Jira電子看板，方便存檔用戶故事、問題等，更好地把控敏捷健康狀況，

2）源代碼：使用SVN或Git托管代碼，代碼庫也有鄙視鏈，在大多程式員看來，似乎Git才是更“高級”的工具，其實，無論是SVN還是Git，都具備相當完備的功能，選擇哪一種工具并不重要，關鍵的是如何規范使用，

● 過去：由于并行任務多，分支策略混亂，代碼整合起來很復雜，耗費人力， 

● 現在：逐步轉換成串行任務，采取主干開發策略，減少產品并行開發的情況；強化代碼提交紀律，如要求開發必須經過本地構建成功、單元測驗通過、規范檢查通過后方可提交，且注意及時拉取和提交代碼，加強對關鍵邏輯代碼的管控和審查，改進代碼評審方式，

● 過去：人工走查的方式，經常一拖再拖，積壓了大量代碼，導致走查時耗費大量時間，效果也難以保證， 

● 現在：利用相關工具（如Gerrit）實施代碼評審環節，取代原始的人工走查，這樣既可以及時發現問題，又能減少開發人員的作業量，

● 過去：CI紀律形同虛設，常有構建失敗無人處理的情況， 

● 現在：強化CI紀律，每個敏捷組配置紅綠儀表盤，實時查看動向，若有構建失敗，立即進行修復，修復不成功全組不下班，

3）代碼拉取：即Jenkins從代碼庫拉取代碼、觸發后續流水線/Job構建，這通常是Jenkins Job執行的第一步，

4）自動化測驗：主要分為自動化單元測驗、自動化介面測驗、自動化UI測驗三部分，其中自動化單元測驗作為Job的一個環節，隨著Job構建而執行；而其他兩類自動化測驗則借助專門的自動化工具（RobotFramework、Appium）實施，在Jenkins上進行相應配置，可定時觸發和構建自動化測驗Job，

5）靜態代碼掃描：對于代碼的質量，不能僅僅局限于那些“可視的”bug，代碼中往往存在大量潛在的問題，如健壯性問題、浮點數比較大小等，不容易被發現，但就像定時炸彈一樣，是產品質量的隱患，因此，我們借助靜態代碼掃描工具進行代碼掃描，例如，Sonarqube工具為各開發語言提供了靜態代碼掃描支持，用戶也可以自定義自己的規則，對于掃描出的各類問題，要求開發盡快解決，此外，Sonarqube還可以讀取自動化單元測驗報告，并將單元測驗結果展示在其儀表盤上，方便相關人員隨時了解代碼質量，

6）安全掃描：增加安全掃描環節，提高代碼安全性，以Checkmarx安全掃描工具為例，在流水線中引入Checkmarx插件，觸發安全掃描環節，同時，對于掃描報告中出現的問題，要求開發予以解決，將問題及時歸零，

7）App加固：對App進行加固處理，防止被反編譯，

● 過去：使用客戶端進行加固， 

● 現在：為了將加固環節自動化、納入持續交付程序，使用shell腳本呼叫加固命令，取代手動加固，

8）構建：前面的環節都是為了這一步做準備，對App產品而言，最終構建的結構是生成安裝包（ipa或apk），App開發涉及開發、測驗、灰度、生產環境，如何保證其處理環境引數外，其他代碼完全一致，是值得我們關注的問題，對此，我們借助Jenkins的Pipeline流水線，提出并行構建機制，

● 過去：開發一般在開發、測驗環境下撰寫代碼，通過測驗后，手動修改代碼里的環境配置，然后構建出對應的生產版本，用于后續投產，若這個程序中有人修改了功能性代碼，則構建出的生產包包含未經過測驗的代碼，直接投產的風險可想而知， 

● 現在：專案代碼設定多環境（開發、生產、測驗等環境）配置，執行構建命令時可指定環境，從而構建出對應環境的App版本；使用Pipeline并行腳本，同時構建出多個環境引數的版本，這幾個版本除了環境配置不同，其他完全一致，在選取生產版本時，強制選擇其中的生產版本，該生產版本和測驗版本同時被構建出，不存在被修改代碼的可能，可以保證App功能測驗版本和生產版本一致性，

9）制品：制品即安裝包，也就是構建出的版本，將被推送至App持續交付工具進行統一管理，

2、流水線中的工具建設

Jenkins不是萬能的，它只提供了一個純粹的流水線引擎，不包含業務屬性，也就是說，Jenkins上的流水線無法關聯軟體管理周期中的需求、專案、任務、產品等元素，它們只能是一個無層次的平行Job的集合，因此，上述環節并不能滿足App建設的實際需要，為此我們自主研發了幾個工具：App持續交付工具、QA儀表盤、多協議擋板系統、錯題本，以進一步提高交付效率，

● App持續交付工具：App產品版本管理的平臺，提供開發、測驗、交付功能，

1）可對接Jenkins平臺，獲取Jenkins制品，并按照其對應的環境引數，分階段統一管理，解決Jenkins Job無序、缺乏制品管理的問題；

2）App可通過掃描二維碼進行下載安裝，取代原有的手工分發模式，極大地提高測驗效率，

3）提供灰度發布功能，用于App的灰度測驗，

● 多協議擋板系統：提供模擬介面，用于環境不聯通導致真實介面無法呼叫的場景，開發人員不再手動撰寫假資料，而是像呼叫真實介面一樣呼叫擋板模擬出的介面，解決環境不通引發的進度阻塞問題，

1）實際開發階段、測驗前期中，往往會遇到介面不通的問題，影響開發進度，使用該擋板可以Mock介面，

2）現有介面不具備復雜資料、特殊場景等，對測驗例外情況造成困難，此時可以使用擋板模擬特殊資料，進行相應測驗，

● QA儀表盤：必要的質量監督環節可以提高開發、測驗的QA意識，QA儀表盤是對流水線質量資料進行收集和統一展示的平臺，盡管我們可以從SVN、Jenkins、Sonar上看到相應的資料，但它們基于分散的Job，無產品關聯資訊，且缺少統計類資料，為了更好地發揮質量監督作用，我們開發了QA儀表盤，將各個環節質量資料進行收集、加工、展示，

1）以產品為基本維度組織資料，并進行團隊、部門等不同層級的統計和展示，

2）提供郵件訂閱等個性化功能，方便用戶定期監督產品質量資料，

● 錯題本：顧名思義，這是一個記錄質量問題的平臺，各個階段注入的問題（需求、開發、測驗分析、測驗實施、運營等）都可以納入這個平臺，并進行詳細跟蹤記錄，測驗經理也會定期從錯題本匯出問題，組織質量問題分析會，通過及時記錄問題、分析問題，可以為以后的測驗分析積累經驗，避免同類質量問題重復出現，減少日后“踩坑”的幾率，

（四）開發測驗融合組織形式 

開發測驗融合與敏捷實施是相輔相成的，從組織結構上看，將開發、測驗團隊融于同一部門，其中測驗團隊承擔部門的測驗實施、質量管控、工藝改進（工具建設）作業；產品以敏捷組為單元開展任務實施，敏捷組里包含PO、開發、測驗，逐步建立起一個全功能敏捷虛擬團隊，通過這樣的組織調整，加強測驗與開發的聯系，也增強敏捷團隊的集體意識，有利于培養DevOps文化氛圍，

伴隨著上述組織調整，測驗團隊的職能也發生了改變，過去，測驗團隊的主要任務是實施測驗任務，測驗經理們重點關注的是案例執行情況、測驗流程等；而隨著開發測驗融合的推進，我們賦予了測驗經理更多的話語權：測驗經理承擔產品QA角色，從產品需求到投產階段結束，關注整個工程活動周期的質量問題，如用戶故事質量、單元測驗情況、缺陷分析等，建立QA全流程質量控制機制，從這個角度講，測驗經理要不斷提高自身能力，培養更全面的質量意識，

三、案例效果

經過上述一系列提升和改進作業，App產品的交付效率有了明顯改善，各敏捷小組的質量意識和CI意識也得到了顯著提升，DevOps的氛圍已經形成，

1、App產品的迭代速率明顯提高，得益于App持續交付流水線的有效實施，任務下達至完成時間明顯縮短，App持續交付工具、擋板等工具得到了有效推廣，工具賦能對于開發、測驗效率提升發揮了巨大作用，

2、迭代質量顯著提升，2018年以前，部門迭代成功率僅為70%，2019年已提升至93%，迭代程序中，持續交付流水線的構建成功率也保持在80%以上，

3、產品質量明顯提升，開發更加注重自己的代碼質量，并在QA的監督下關注自動化測驗資料，從而使開發團隊的Bug數量明顯減少，自動化介面測驗積累了大量案例，自動化單元測驗覆寫率從無到有，從有到高，目前部分產品覆寫率已達90%以上，

本文介紹的實踐案例仍處于初級階段，App持續交付流水線還存在很大的提升空間，未來，計劃進一步優化持續交付流水線，擴展工具功能，深化DevOps實踐，

標籤：其他

上一篇：【翻譯】如何撰寫 Git 提交訊息

下一篇：敏捷開發xp與scrum區別