交付效率提升40%，珍爱网基于微服务的DevOps落地指南
2015-2016年，珍愛線下門店已新增覆蓋城市9個，與此同時，CRM系統大小故障卻發生了數十起... ...
珍愛網是以“網絡征選+人工紅娘”模式提供婚配服務的婚戀相親平臺。CRM系統承載了整個珍愛網會員的全生命周期管理，涵蓋資源挖掘、用戶觸達渠道以及服務跟進體系。
CRM系統對珍愛5400名紅娘來說，是承載她們全部工作的核心平臺；對公司業務來說，承載著引流、轉化、支付、客戶服務等全部環節。最最重要的是，公司收入的80%都是依托CRM系統完成的。
然而在珍愛網成立10年之際，運行10年之久的CRM系統已不足以支撐業務的快速發展了。
Part.1?我們為什么要做DevOps
經過分析，我們發現CRM系統目前面臨著以下問題：
技術上——
傳統的系統架構，不再適應敏捷開發，模塊耦合，數據庫存在單點故障；
容錯性差，冗余代碼多，修復bug和實現新功能變得困難和耗時。
產品上——
產品功能不夠場景化、電子化、智能化；
無法快速響應業務變化，迭代周期長。
我們可是背負著“成就天下姻緣”使命呢，系統重構，研發流程改進，迫在眉睫。
2017年1月25日，捷豹項目組成立，只為給業務打造一個“簡單·好用”專注于婚戀相親的綜合服務平臺。
捷豹CRM系統（PC端、Pad端、小程序端）的版本發布周期為一周一個常規迭代，緊急版本按天發布。
捷豹CRM系統整體設計思路如下圖，我們希望能夠實現系統的服務解耦、動靜分離以及高可用。
然而大家都知道，微服務架構中每個服務都具有業務屬性，并且能獨立地被開發、測試、構建、部署。換句話說，每個服務都是一個可交付的“系統”。
那么問題來了，如何讓需求以小批量形式在團隊的各個角色間順暢流動，并以較短的周期完成小粒度的持續發布呢？
答案當然是 TAPD DevOps流水線，簡直是神助攻！
Part.2?整體效果
TAPD DevOps流水線支持集成主流的研發工具，覆蓋產品研發全生命周期，提供可視化交付流水線，可以將DevOps各個環節進行統一展示和管理，真正實現一站式持續交付。
自2017年10月起，我們就應用TAPD的DevOps流水線，開展了一系列持續交付和持續改進實踐。
持續交付部分
CI和CD實現過程使用Gitlab、Jenkins、Sonar、Jacoco、Nexus、EasyOps、Docker、Kubernetes等工具，分別在代碼管理、集成編譯、包管理、自動化測試、發布階段集成到TAPD流水線統一展示和管理。
持續改進部分
在TAPD流水線實踐DevOps的過程中，我們也打通了各環節的研發數據。
通過TAPD迭代詳情中的Dashboard，可以統計并展示當前迭代的研發效能數據，包括：需求完成情況、缺陷新增和解決情況、代碼提交與關聯趨勢、每日構建統計、構建產物版本情況、自動化測試、部署發布等全過程數據，研發效能度量更直觀、更深入，讓改進方向更明確，也讓效能提升更明顯。
改進效果
基于以上持續交付和持續改進實踐，我們的研發效能也有了質的提升。
我們從業務響應周期、持續交付能力、開發質量、交付質量四個方面來衡量研發效能，下圖展示了各個維度的改進效果。
Part.3?我們的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了。
3?集成編譯環節
需求分支經過靜態掃描和自測通過后就要提交到集成環境啦。
在這個環節，除了常規編譯步驟，我們還增加了開發的單元測試和Jacoco覆蓋率檢測。在集成環境我們也增加了Sonar進行最后一次掃描確認。
單元測試框架為JUnit，與TAPD進行關聯，構建后在“自動化測試”板塊可以看到本次構建的單元測試用例總數和通過率（單元測試通過率是我們對研發質量度量的一個很重要的指標），單元測試不通過的case和Sonar掃描的bug處理方式一致，由API腳本統一錄入TAPD缺陷進行跟蹤。
單元測試的覆蓋率情況，方便開發同學分析單元測試用例對測試對象的分支覆蓋情況。
編譯后就是Sonar進行最后一道集成環境的全量代碼掃描工作了。
4 包管理環節
我們在包管理環節的實踐主要分為對 “jar包”和“Docker鏡像”的管理。
構建生成的jar包，推送到Maven倉庫（用于其他項目的依賴引用）。將Nexus集成到TAPD，通過“構建產物”可以看到軟件包的詳細信息。
同時，流水線可以清晰看到構建步驟的耗時分布，也幫助我們有針對性地去優化構建效率。
然后進行Docker鏡像打包，推送到Docker倉庫，生成配置，并推送到配置倉庫。
順便說說為什么要用Docker吧！
項目初期只有一個dev環境，隨著版本構建的頻繁，穩定的測試環境對測試同學來說尤為關鍵，但是部署一套40余工程的環境對運維同學來說工作量也非常之大，于是我們引入了容器技術。在環境搭建、應用遷移方面都有很好的收獲。
同時，基于珍愛的業務背景，特別是對于特殊節日搞活動時候，容器化能快速對服務進行橫向擴容；減少對環境的依賴，部署快、擴容快。同時容器運行時會對服務運行環境進行隔離，也有效提升了安全性和服務運行的穩定性。
5 自動化測試環節
自動化測試分為接口測試和UI自動化測試兩個部分。
接口測試主要通過開源工具實現，但涉及到跨系統維護，以及測試結果不能很好地跟蹤，因此在TAPD上嘗試用Python Unit Test做些核心場景的接口測試，以便于將這部分測試納入到整個研發流水線當中，構建成功后自動觸發場景接口測試，失敗的用例也能直接在TAPD跟蹤。
UI自動化，則是我們自己研發的平臺，通過關鍵字驅動實現，并增加了代碼覆蓋率檢測，以幫助測試人員分析哪些分支情況是沒覆蓋到的。
測試結果轉為XML格式后也可以統一集成到TAPD管理，可以清晰直觀地展示自動化測試結果。
目前我們的自動化用例覆蓋業務流程達239個，case成功率94%，運行時長15min，代碼覆蓋率21%。
6 部署發布環節
我們整個發布流程簡單分為以下幾個步驟，部署發布環節主要用主流部署工具完成。
Part.4?研發效能度量
每月通過TAPD產生的過程數據進行研發過程效率和質量分析。同時我們也設立了相關獎項激勵大家正向PK，提升效率的同時更加重視研發質量。
研發效率分析
得益于TAPD的強大API，我們可以拿到需求交付過程數據。
通過深入分析，我們可以知道效率較低的環節到底是什么原因導致，以制定更有效的提升效率的方案，可以是流程自動化，也可以是制定規范。
研發質量分析
而研發質量分析方面，我們希望能在團隊內部形成重視研發質量的共識和文化。
我們會統計出研發同學本月上線的任務數、代碼行、花費、生產bug，來計算出有效花費，遵循“好、多、快”原則，評選出優秀的個人和團隊進行表彰鼓勵。
噢，TAPD的API好好用，以上提到的腳本均由測試同學通過API實現，你會發現高效的質量度量是一件特別有意思的事情，質量度量后的效能提升更是一件特別有成就感的事情！
珍愛網捷豹CRM項目，應用TAPD DevOps可視化流水線，集成業界主流研發工具，實現一站式持續交付管理，讓整個研發過程清晰、直觀、透明。
在這一過程中，我們基于TAPD提供的API接口，進行了二次開發，實現了多個環節的自動化閉環。
此外，我們通過API以及TAPD Dashboard，獲取持續交付過程數據，從而進行研發效率和質量的分析以及持續改進。
基于以上實踐，我們從業務響應周期、持續交付能力、開發質量、交付質量4個方面衡量的研發效能，都有了顯著的提升。
我們將持續在此基礎之上不斷完善和優化，挖掘TAPD DevOps流水線的更多場景，全方位提升研發效能。
好咯， 今天的分享先到這里啦，我要去開早會了！
歡迎在評論中與我們多多交流哦~
點擊“閱讀原文”?
與珍愛網一起提高研發協作效率
總結
以上是生活随笔為你收集整理的交付效率提升40%，珍爱网基于微服务的DevOps落地指南的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 算法工程师眼中的AI岗位
- 下一篇： 前沿观察 | SageDB：一个自学成才