基於微服務的DevOps落地指南 交付效率提高40%

基於微服務的DevOps落地指南

交付效率提高40%

2015-2016年，珍愛線下門店已新增覆蓋城市9個，與此同時，CRM系統大小故障卻發生了數十起... ...

珍愛網是以「網絡徵選+人工紅娘」模式提供婚配服務的婚戀相親平臺。CRM系統承載了整個珍愛網會員的全生命週期管理，涵蓋資源挖掘、用戶觸達渠道以及服務跟進體系。

CRM系統對珍愛5400名紅娘來講，是承載她們所有工做的核心平臺；對公司業務來講，承載着引流、轉化、支付、客戶服務等所有環節。最最重要的是，公司收入的80%都是依託CRM系統完成的。

然而在珍愛網成立10年之際，運行10年之久的CRM系統已不足以支撐業務的快速發展了。

 

咱們爲何要作DevOps

通過分析，咱們發現CRM系統目前面臨着如下問題：

技術上——

• 傳統的系統架構，再也不適應敏捷開發，模塊耦合，數據庫存在單點故障；

• 容錯性差，冗餘代碼多，修復bug和實現新功能變得困難和耗時。

產品上——

• 產品功能不夠場景化、電子化、智能化；

• 沒法快速響應業務變化，迭代週期長。

咱們但是揹負着「成就天下姻緣」使命呢，系統重構，研發流程改進，迫在眉睫。

2017年1月25日，捷豹項目組成立，只爲給業務打造一個「簡單·好用」專一於婚戀相親的綜合服務平臺。

捷豹CRM系統（PC端、Pad端、小程序端）的版本發佈週期爲一週一個常規迭代，緊急版本按天發佈。

捷豹CRM系統總體設計思路以下圖，咱們但願可以實現系統的服務解耦、動靜分離以及高可用。

然而你們都知道，微服務架構中每一個服務都具備業務屬性，而且能獨立地被開發、測試、構建、部署。換句話說，每一個服務都是一個可交付的「系統」。

那麼問題來了，如何讓需求以小批量形式在團隊的各個角色間順暢流動，並以較短的週期完成小粒度的持續發佈呢？

答案固然是 TAPD DevOps流水線，簡直是神助攻！

 

 

 

總體效果

TAPD DevOps流水線支持集成主流的研發工具，覆蓋產品研發全生命週期，提供可視化交付流水線，能夠將DevOps各個環節進行統一展現和管理，真正實現一站式持續交付。

 

 

自2017年10月起，咱們就應用TAPD的DevOps流水線，開展了一系列持續交付和持續改進實踐。

CI和CD實現過程使用Gitlab、Jenkins、Sonar、Jacoco、Nexus、EasyOps、Docker、Kubernetes等工具，分別在代碼管理、集成編譯、包管理、自動化測試、發佈階段集成到TAPD流水線統一展現和管理。

 

在TAPD流水線實踐DevOps的過程當中，咱們也打通了各環節的研發數據。

經過TAPD迭代詳情中的Dashboard，能夠統計並展現當前迭代的研發效能數據，包括：需求完成狀況、缺陷新增和解決狀況、代碼提交與關聯趨勢、每日構建統計、構建產物版本狀況、自動化測試、部署發佈等全過程數據，研發效能度量更直觀、更深刻，讓改進方向更明確，也讓效能提高更明顯。

 

基於以上持續交付和持續改進實踐，咱們的研發效能也有了質的提高。

咱們從業務響應週期、持續交付能力、開發質量、交付質量四個方面來衡量研發效能，下圖展現了各個維度的改進效果。

 

咱們的DevOps是如何落地的

那麼咱們具體怎樣利用TAPD DevOps流水線，一步步實現持續交付，最終提高研發效能的呢？

下面我將分享咱們在各個環節的作法。

1 代碼管理環節

1.1 創建TAPD分支管理規範

改造前：

開發編碼過程當中最崩潰的應該是：「我剛寫好的代碼又被誰覆蓋了！」

並行開發過程當中，最痛苦的莫過於開發的需求太多， 記不清哪一個需求在哪一個分支上，或者多個需求在一個分支上開發，撤代碼撤到望眼欲穿……

改造後：

經過走訪調研，最終咱們肯定遵循「一個需求一個開發分支」的原則，方便管理且可追溯，並行開發，互不干擾。

 

 

在Jenkins上建立Job，經過TAPD和Git的API，將TAPD需求ID與Git分支關聯，建立的分支名爲 「工程名-建立日期-TAPD需求ID」，開發小哥哥去Gitlab上拉建立好的需求分支即可努力搬磚了。

待需求上線後轉關閉狀態的21天，自動將該分支刪除，整個分支管理過程實現自動化。

效果：

截至目前， 經過該Job建立分支次數達到1564次，建立成功的分支數遠大於1564*3 個，而合併衝突數小於5次。

1.2 TAPD源碼關聯

改造前：

 在測試過程當中， 最繁雜的應該是代碼合併環節了，一個需求涉及到多個工程的代碼變動，天天各個開發針對不一樣的需求，提測到測試同窗進行代碼合併。

開發/測試的比例爲4:1，需求涉及的先後端工程40餘個，面對一個需求到底要合併哪些工程，測試同窗天天要在風中凌亂好幾次……

改造後：

與研發效能度量深度結合，良好編碼習慣，從源碼關聯開始。

經過源碼關聯功能，咱們實現瞭如下閉環：

全部研發任務都必須錄入TAPD，而且只能經過需求ID來建立Git分支 → Commit信息必須關聯源碼提交 → 度量數據只獲取關聯源碼的代碼行 → 根據這部分數據進行研發效率和質量的度量。

測試同窗只用關注該需求的Gitlab提交記錄便可知道本次變動涉及的工程有哪些，不用和開發一個個確認，減小溝通成本。

因爲提交比較頻繁，咱們寫了一個爬蟲腳本，將抓到的版本庫去重，獲得該需求要合併的工程。而後咱們將待合併工程，生成TAPD的合併任務分發給指定同窗，將整個過程自動化管理。

 

效果：

綜上，經過「源碼管理」和「TAPD分支規範」，有效規避了代碼管理過程當中，衝突多、管理亂、不可追溯的問題，同時也實現按需求粒度、靈活發佈的效果。

自2018年10月以來，經過這套代碼合併任務自動分發方案，咱們成功迭代上線了18個常規版本和10個緊急版本，整個過程簡單清晰，單任務合併整合環節，從原來的40分鐘，減小到5分鐘。

 

2 代碼質量分析

 

改造前：

Sonar其實很早就開始在項目過程當中使用了，可是效果並不太好。

不管對於開發仍是測試同窗，都須要多維護一個系統，而且改動頻繁，當某一個服務經手的開發過多時，Sonar掃描出問題後沒法快速分配責任開發。

另外Sonar配置到集成環境構建時觸發，讓bug從發現環節開始滯後，修復過程也對版本穩定性帶來風險。

改造後：

在2018年末，咱們發現TAPD流水線集成Sonar，還能夠一鍵建立缺陷到TAPD。

因而，咱們將Sonar掃描前置到開發每一次提交到Git倉庫便觸發構建，讓Sonar缺陷在開發自測環節變暴露出來，同時，每一次構建能清晰的展現本次代碼變動人，開發能夠安心地收下這一頁的bug啦。

 固然，有的開發小哥哥可能沒有及時修復，不要緊， 測試小姐姐將未及時關閉的Sonar缺陷經過「批量導入缺陷功能」天天自動化（經過TAPD的API實現）建立到你的缺陷清單裏，開發小哥哥不再會錯過那些被遺忘的bug啦。

 噢，貼心的TAPD還在缺陷詳情裏把bug的文件名和代碼行都給展現了呢，開發小哥哥和測試小姐姐終於能夠不跨系統維護Sonar了。

 

 

 

需求分支通過靜態掃描和自測經過後就要提交到集成環境啦。

在這個環節，除了常規編譯步驟，咱們還增長了開發的單元測試和Jacoco覆蓋率檢測。在集成環境咱們也增長了Sonar進行最後一次掃描確認。

單元測試框架爲JUnit，與TAPD進行關聯，構建後在「自動化測試」板塊能夠看到本次構建的單元測試用例總數和經過率（單元測試經過率是咱們對研發質量度量的一個很重要的指標），單元測試不經過的case和Sonar掃描的bug處理方式一致，由API腳本統一錄入TAPD缺陷進行跟蹤。

 

 

單元測試的覆蓋率狀況，方便開發同窗分析單元測試用例對測試對象的分支覆蓋狀況。

 

 

 

編譯後就是Sonar進行最後一道集成環境的全量代碼掃描工做了。

 

 

 

咱們在包管理環節的實踐主要分爲對 「jar包」和「Docker鏡像」的管理。

構建生成的jar包，推送到Maven倉庫（用於其餘項目的依賴引用）。將Nexus集成到TAPD，經過「構建產物」能夠看到軟件包的詳細信息。

 

 

同時，流水線能夠清晰看到構建步驟的耗時分佈，也幫助咱們有針對性地去優化構建效率。

 

 而後進行Docker鏡像打包，推送到Docker倉庫，生成配置，並推送到配置倉庫。

順便說說爲何要用Docker吧！

項目初期只有一個dev環境，隨着版本構建的頻繁，穩定的測試環境對測試同窗來講尤其關鍵，可是部署一套40餘工程的環境對運維同窗來講工做量也很是之大，因而咱們引入了容器技術。在環境搭建、應用遷移方面都有很好的收穫。

同時，基於珍愛的業務背景，特別是對於特殊節日搞活動時候，容器化能快速對服務進行橫向擴容；減小對環境的依賴，部署快、擴容快。同時容器運行時會對服務運行環境進行隔離，也有效提高了安全性和服務運行的穩定性。

 

 

 自動化測試分爲接口測試和UI自動化測試兩個部分。

接口測試主要經過開源工具實現，但涉及到跨系統維護，以及測試結果不能很好地跟蹤，所以在TAPD上嘗試用Python Unit Test作些核心場景的接口測試，以便於將這部分測試歸入到整個研發流水線當中，構建成功後自動觸發場景接口測試，失敗的用例也能直接在TAPD跟蹤。

 

 

 

UI自動化，則是咱們本身研發的平臺，經過關鍵字驅動實現，並增長了代碼覆蓋率檢測，以幫助測試人員分析哪些分支狀況是沒覆蓋到的。

 

 

 

測試結果轉爲XML格式後也能夠統一集成到TAPD管理，能夠清晰直觀地展現自動化測試結果。

 

 

 

目前咱們的自動化用例覆蓋業務流程達239個，case成功率94%，運行時長15min，代碼覆蓋率21%。

 

 

 

咱們整個發佈流程簡單分爲如下幾個步驟，部署發佈環節主要用主流部署工具完成。

 

 

 

 

研發效能度量

每個月經過TAPD產生的過程數據進行研發過程效率和質量分析。同時咱們也設立了相關獎項激勵你們正向PK，提高效率的同時更加劇視研發質量。

 研發效率分析

 得益於TAPD的強大API，咱們能夠拿到需求交付過程數據。

 

 

經過深刻分析，咱們能夠知道效率較低的環節究竟是什麼緣由致使，以制定更有效的提高效率的方案，能夠是流程自動化，也能夠是制定規範。

 

研發質量分析

 

而研發質量分析方面，咱們但願能在團隊內部造成重視研發質量的共識和文化。

咱們會統計出研發同窗本月上線的任務數、代碼行、花費、生產bug，來計算出有效花費，遵循「好、多、快」原則，評選出優秀的我的和團隊進行表彰鼓勵。

 

 

 

噢，TAPD的API好好用，以上提到的腳本均由測試同窗經過API實現，你會發現高效的質量度量是一件特別有意思的事情，質量度量後的效能提高更是一件特別有成就感的事情！

 

 

 

 

 

總結

 

珍愛網捷豹CRM項目，應用TAPD DevOps可視化流水線，集成業界主流研發工具，實現一站式持續交付管理，讓整個研發過程清晰、直觀、透明。

在這一過程當中，咱們基於TAPD提供的API接口，進行了二次開發，實現了多個環節的自動化閉環。

此外，咱們經過API以及TAPD Dashboard，獲取持續交付過程數據，從而進行研發效率和質量的分析以及持續改進。

基於以上實踐，咱們從業務響應週期、持續交付能力、開發質量、交付質量4個方面衡量的研發效能，都有了顯著的提高。

咱們將持續在此基礎之上不斷完善和優化，挖掘TAPD DevOps流水線的更多場景，全方位提高研發效能。