本文由團隊內大瑤同學撰寫。
引言
移動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實踐。