企業級DevOps實戰案例-移動APP持續交付實踐

本文由團隊內大瑤同窗撰寫。

 

 

引言

 

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

 

值得重視的是，DevOps並不是一個固定的模式或標準，事實上，業界對DevOps沒有統一的定義（並且DevOps的定義是隨着時間不斷演變的）。它是一種普適的軟件工程文化和實踐，但每一個企業的組織文化有差別，DevOps基礎也不盡相同，現有的一些成功方案每每並不徹底適合團隊的實際狀況，業界也不存在一個萬能的實例供咱們複製。所以，應當基於自身實際狀況，參考同類優秀案例和經驗，摸索出最適合本身的模式。一方面，咱們缺少專門的工具部門或團隊，短期內沒法創建起大型的一體化持續交付平臺；另外一方面，咱們又急需創建起持續交付流水線，以改進敏捷產品的開發測試流程。所以，咱們以開源持續集成工具爲核心，再適當開發輔助工具，構建了一個較爲實用的App產品持續交付流水線。

 

1、案例背景

 

隨着App的功能日益複雜，與第三方合做的模塊愈來愈多，開發、測試階段聯調的難度也隨之增長。同時，爲迅速響應市場需求變化，App的迭代愈來愈快，發佈週期愈來愈短。工期緊、任務多，這給開發、測試人員帶來了很大的壓力，例如，開發爲了按時完成代碼，擠壓了一些原本用於代碼評審、單元測試的時間，致使項目代碼的質量降低；隨之而來的是生產風險的提升，產品質量難以保障；開發須要花費額外的精力償還技術債（漏洞、不規範的代碼等），這又給新一輪迭代帶來風險——如此便陷入「疲於奔命」的惡性循環。

 

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

 

2、案例內容

 

（一）問題分析

 

與其餘產品不一樣，App的交付比較特殊。例如，H5產品須要將部署包放置到服務器上，並進行相應的配置，用戶就能夠經過訪問網址獲取服務；而安卓和IOS並非部署在企業本身的服務器上，而是須要在各自的應用市場「上架」，用戶才能從市場上獲取App，安裝到本身的手機上，完成交付過程。

 

對症方能下藥，咱們首先必須明確，是什麼影響了App的迭代效率？通過分析和總結，咱們發現，App的實施過程存在如下痛點：

 

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

 

形成這一點的緣由有不少，如需求規劃不合理、環境問題致使聯調失敗、代碼評審不到位、測試覆蓋不全面等。

 

二、版本分發效率低。

 

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

 

三、容易出現不一樣環境下版本不一致問題。

 

在測試階段，測試人員一般對測試環境下的版本進行測試，而產品發佈時，使用的是測試版本對應的生產版本，必須作到這個兩個版本除了環境相關的參數配置不一樣外，其餘代碼徹底一致。然而從測試經過到人工切換成生產環境參數並構建生產版本的這段時間，可能會存在開發人員改動代碼的風險，致使一個未經測試的App版本被髮布。所以，須要尋求同時構建多個不一樣環境參數的App的方案。

 

四、測試分析不到位，同類質量問題重複出現。

 

咱們的目的不只僅是修復問題，並且要保證往後再也不發生一樣的錯誤。事實上，一個產品的缺陷能夠給其餘產品帶來啓發，咱們須要吸收他人的經驗和教訓，增強不一樣產品之間的交流。

 

以上幾個問題，其實都是缺少規範的流程、人工介入過多等緣由形成的。當人工操做影響到工做效率時，應當考慮藉助工具來節省人力，提升效率。

 

（二）方法體系

 

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

 

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

 

● 分別對DevOps的各個步驟進行優化和改進，並組合成一條基於Jenkins自動化持續交付流水線，覆蓋從需求到交付的各個環節，從實施流程上規範App交付的各個環節，如優化需求拆分、強化代碼評審等步驟，提升代碼質量。

 

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

 

二、進行組織結構調整，開展開發測試融合實踐。

 

● 在開發測試融合思惟的導向下，開發與測試團隊被規劃到同一部門，這消除了部門壁壘，使得敏捷迭代中開發、測試成爲一個總體，強化了兩者的溝通和聯繫。

 

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

 

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

 

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

 

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

 

一、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持續交付工具進行統一管理。

 

二、流水線中的工具建設

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全流程質量控制機制。從這個角度講，測試經理要不斷提升自身能力，培養更全面的質量意識。

 

3、案例效果

 

通過上述一系列提高和改進工做，App產品的交付效率有了明顯改善，各敏捷小組的質量意識和CI意識也獲得了顯著提高，DevOps的氛圍已經造成。

 

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

 

二、迭代質量顯著提高。2018年之前，部門迭代成功率僅爲70%，2019年已提高至93%。迭代過程當中，持續交付流水線的構建成功率也保持在80%以上。

 

三、產品質量明顯提高。開發更加註重本身的代碼質量，並在QA的監督下關注自動化測試數據，從而使開發團隊的Bug數量明顯減小。自動化接口測試積累了大量案例，自動化單元測試覆蓋率從無到有，從有到高，目前部分產品覆蓋率已達90%以上。

 

 

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